Sunday, 30 August 2020

Workshop And Presentation Slides And Materials

All of our previous workshop and presentation slides and materials are available in one location, from Google Drive.

From now on, we are only going to keep the latest-greatest version of each talk/workshop and announce changes on Twitter.

More info


at

Saturday, 29 August 2020

APPLE IPHONE X FACE ID CAN BE HACKED WITH SILICON MASK

Just a week after Apple released its brand new iPhone X on November 3, a team of researchers has claimed to successfully hack Apple's Face ID facial recognition technology with a mask that costs less than $150. They said Apple iPhone x face id can be hacked with silicon mask easily.

apple iPhone x face id hacked
Yes, Apple's "ultra-secure" Face ID security for the iPhone X is not as secure as the company claimed during its launch event in September this year.

"Apple engineering teams have even gone and worked with professional mask makers and makeup artists in Hollywood to protect against these attempts to beat Face ID," Apple's senior VP of worldwide marketing Phil Schiller said about Face ID system during the event.

"These are actual masks used by the engineering team to train the neural network to protect against them in Face ID."

However, the bad news is that researchers from Vietnamese cybersecurity firm Bkav were able to unlock the iPhone X using a mask.

Yes, Bkav researchers have a better option than holding it up to your face while you sleep. Bkav researchers re-created the owner's face through a combination of 3D printed mask, makeup, and 2D images with some "special processing done on the cheeks and around the face, where there are large skin areas" and the nose is created from silicone.

The researchers have also published a proof-of-concept video, showing the brand-new iPhone X first being unlocked using the specially constructed mask, and then using the Bkav researcher's face, in just one go.

"Many people in the world have tried different kinds of masks but all failed. It is because we understand how AI of Face ID works and how to bypass it," an FAQ on the Bkav website said.

"You can try it out with your own iPhone X, the phone shall recognize you even when you cover a half of your face. It means the recognition mechanism is not as strict as you think, Apple seems to rely too much on Face ID's AI. We just need a half face to create the mask. It was even simpler than we ourselves had thought."

Researchers explain that their "proof-of-concept" demo took about five days after they got iPhone X on November 5th. They also said the demo was performed against one of their team member's face without training iPhone X to recognize any components of the mask.

"We used a popular 3D printer. The nose was made by a handmade artist. We use 2D printing for other parts (similar to how we tricked Face Recognition 9 years ago). The skin was also hand-made to trick Apple's AI," the firm said.

The security firm said it cost the company around $150 for parts (which did not include a 3D printer), though it did not specify how many attempts its researchers took them to bypass the security of Apple's Face ID.

It should be noted that creating such a mask to unlock someone's iPhone is a time-consuming process and it is not possible to hack into a random person's iPhone.

However, if you prefer privacy and security over convenience, we highly recommend you to use a passcode instead of fingerprint or Face ID to unlock your phone.

Related posts


at

inBINcible Writeup - Golang Binary Reversing

This file is an 32bits elf binary, compiled from go language (i guess ... coded by @nibble_ds ;)
The binary has some debugging symbols, which is very helpful to locate the functions and api calls.

GO source functions:
-  main.main
-  main.function.001

If the binary is executed with no params, it prints "Nope!", the bad guy message.

~/ncn$ ./inbincible 
Nope!

Decompiling the main.main function I saw two things:

1. The Argument validation: Only one 16 bytes long argument is needed, otherwise the execution is finished.

2. The key IF, the decision to dexor and print byte by byte the "Nope!" string OR dexor and print "Yeah!"


The incoming channel will determine the final message.


Dexor and print each byte of the "Nope!" message.


This IF, checks 16 times if the go channel reception value is 0x01, in this case the app show the "Yeah!" message.

Go channels are a kind of thread-safe queue, a channel_send is like a push, and channel_receive is like a pop.

If we fake this IF the 16 times, we got the "Yeah!" message:

(gdb) b *0x8049118
(gdb) commands
>set {char *}0xf7edeef3 = 0x01
>c
>end

(gdb) r 1234567890123456
tarting program: /home/sha0/ncn/inbincible 1234567890123456
...
Yeah!


Ok, but the problem is not in main.main, is main.function.001 who must sent the 0x01 via channel.
This function xors byte by byte the input "1234567890123456" with a byte array xor key, and is compared with another byte array.

=> 0x8049456:       xor    %ebp,%ecx
This xor,  encode the argument with a key byte by byte

The xor key can be dumped from memory but I prefer to use this macro:

(gdb) b *0x8049456
(gdb) commands
>i r  ecx
>c
>end
(gdb) c

Breakpoint 2, 0x08049456 in main.func ()
ecx            0x12 18

Breakpoint 2, 0x08049456 in main.func ()
ecx            0x45 69

Breakpoint 2, 0x08049456 in main.func ()
ecx            0x33 51

Breakpoint 2, 0x08049456 in main.func ()
ecx            0x87 135

Breakpoint 2, 0x08049456 in main.func ()
ecx            0x65 101

Breakpoint 2, 0x08049456 in main.func ()
ecx            0x12 18

Breakpoint 2, 0x08049456 in main.func ()
ecx            0x45 69

Breakpoint 2, 0x08049456 in main.func ()
ecx            0x33 51

Breakpoint 2, 0x08049456 in main.func ()
ecx            0x87 135

Breakpoint 2, 0x08049456 in main.func ()
ecx            0x65 101

Breakpoint 2, 0x08049456 in main.func ()
ecx            0x12 18

Breakpoint 2, 0x08049456 in main.func ()
ecx            0x45 69

Breakpoint 2, 0x08049456 in main.func ()
ecx            0x33 51

Breakpoint 2, 0x08049456 in main.func ()
ecx            0x87 135

Breakpoint 2, 0x08049456 in main.func ()
ecx            0x65 101

Breakpoint 2, 0x08049456 in main.func ()
ecx            0x12 18

The result of the xor will compared with another array byte,  each byte matched, a 0x01 will be sent.

The cmp of the xored argument byte,
will determine if the channel send 0 or 1


(gdb) b *0x0804946a
(gdb) commands
>i r al
>c
>end

At this point we have the byte array used to xor the argument, and the byte array to be compared with, if we provide an input that xored with the first byte array gets the second byte array, the code will send 0x01 by the channel the 16 times.


Now web have:

xorKey=[0x12,0x45,0x33,0x87,0x65,0x12,0x45,0x33,0x87,0x65,0x12,0x45,0x33,0x87,0x65,0x12]

mustGive=[0x55,0x75,0x44,0xb6,0x0b,0x33,0x06,0x03,0xe9,0x02,0x60,0x71,0x47,0xb2,0x44,0x33]


Xor is reversible, then we can get the input needed to dexor to the expected values in order to send 0x1 bytes through the go channel.

>>> x=''
>>> for i in range(len(xorKey)):
...     x+= chr(xorKey[i] ^ mustGive[i])
... 
>>> print x

G0w1n!C0ngr4t5!!


And that's the key :) let's try it:

~/ncn$ ./inbincible 'G0w1n!C0ngr4t5!!'
Yeah!

Got it!! thanx @nibble_ds for this funny crackme, programmed in the great go language. I'm also a golang lover.


Related news


at

C++ Std::String Buffer Overflow And Integer Overflow

Interators are usually implemented using signed integers like the typical "for (int i=0; ..." and in fact is the type used indexing "cstr[i]", most of methods use the signed int, int by default is signed.
Nevertheless, the "std::string::operator[]" index is size_t which is unsigned, and so does size(), and same happens with vectors.
Besides the operator[] lack of negative index control, I will explain this later.

Do the compilers doesn't warn about this?


If his code got a large input it would index a negative numer, let see g++ and clang++ warnings:



No warnings so many bugs out there...

In order to reproduce the crash we can load a big string or vector from file, for example:


I've implemented a loading function, getting the file size with tellg() and malloc to allocate the buffer, then in this case used as a string.
Let see how the compiler write asm code based on this c++ code.



So the string constructor, getting size and adding -2 is clear. Then come the operator<< to concat the strings.
Then we see the operator[] when it will crash with the negative index.
In assembly is more clear, it will call operator[] to get the value, and there will hapen the magic dereference happens. The operator[] will end up returning an invalid address that will crash at [RAX]



In gdb the operator[] is a  allq  0x555555555180 <_znst7__cxx1112basic_stringicst11char_traitsicesaiceeixem plt="">

(gdb) i r rsi
rsi            0xfffffffffffefffe  -65538


The implmementation of operator ins in those functions below:

(gdb) bt
#0  0x00007ffff7feebf3 in strcmp () from /lib64/ld-linux-x86-64.so.2
#1  0x00007ffff7fdc9a5 in check_match () from /lib64/ld-linux-x86-64.so.2
#2  0x00007ffff7fdce7b in do_lookup_x () from /lib64/ld-linux-x86-64.so.2
#3  0x00007ffff7fdd739 in _dl_lookup_symbol_x () from /lib64/ld-linux-x86-64.so.2
#4  0x00007ffff7fe1eb7 in _dl_fixup () from /lib64/ld-linux-x86-64.so.2
#5  0x00007ffff7fe88ee in _dl_runtime_resolve_xsavec () from /lib64/ld-linux-x86-64.so.2
#6  0x00005555555554b3 in main (argc=2, argv=0x7fffffffe118) at main.cpp:29

Then crashes on the MOVZX EAX, byte ptr [RAX]

Program received signal SIGSEGV, Segmentation fault.
0x00005555555554b3 in main (argc=2, argv=0x7fffffffe118) at main.cpp:29
29     cout << "penultimate byte is " << hex << s[i] << endl;
(gdb)


What about negative indexing in std::string::operator[] ?
It's exploitable!

In a C char array is known that having control of the index, we can address memory.
Let's see what happens with C++ strings:






The operator[] function call returns the address of string plus 10, and yes, we can do abitrary writes.



Note that gdb displays by default with at&t asm format wich the operands are in oposite order:


And having a string that is in the stack, controlling the index we can perform a write on the stack.



To make sure we are writing outside the string, I'm gonna do 3 writes:


 See below the command "i r rax" to view the address where the write will be performed.


The beginning of the std::string object is 0x7fffffffde50.
Write -10 writes before the string 0x7fffffffde46.
And write -100 segfaults because is writting in non paged address.



So, C++ std::string probably is not vulnerable to buffer overflow based in concatenation, but the std::string::operator[] lack of negative indexing control and this could create vulnerable and exploitable situations, some times caused by a signed used of the unsigned std::string.size()










Related news


at
Subscribe to: Posts (Atom)