FAMILIA TELERIN

Familia Bueno

I have developed a fast emulator for modern shellcodes, that perform huge loops of millions of instructions emulated for resolving API or for other stuff.

The emulator is in Rust and all the few dependencies as well, so the rust safety is good for emulating malware.

There are shellcodes that can be emulated from the beginning to the end, but when this is not possible the tool has many features that can be used like a console, a memory tracing, register tracing, and so on.

https://github.com/sha0coder/scemu

In less than two seconds we have emulated 7 millions of instructions arriving to the recv.

At this point we have some IOC like the ip:port where it's connecting and other details.

Lets see what happens after the recv() spawning a console at position: 7,012,204

target/release/scemu -f shellcodes/shikata.bin -vv -c 7012204

In the console, pressing "enter" several times to emulate step into several steps and we arrive to a return instruction.

Let's see the stack in this moment:

The "ret" instruction is going to jump to the buffer read with recv() so is a kind of stager.

The option "-e" or "--endpoint" is not ready for now, but it will allow to proxy the calls to get the next stage automatically, but for now we have the details to get the stage.

SCEMU also identify all the Linux syscalls for 32bits shellcodes:

The encoder used in shellgen is also supported https://github.com/MarioVilas/shellgen

Let's check with cobalt-strike:

We can see where is connecting and which headers is using, so right now we can replicate the communications.

In verbose mode we could do several greps to see the calls and correlate with ghidra/ida/radare or for example grep the branches to study the emulation flow.

target/release/scemu -f shellcodes/rshell_sgn.bin -vv | grep j

target/release/scemu -f shellcodes/rshell_sgn.bin -vv -c 44000 -l

The -l --loops options makes the emulation a bit slower but track the number of iterations.

Is possible to print all the registers in every step with -r or --registers but also is possible to track specific register for example with --reg esi

target/release/scemu -f shellcodes/shikata.bin --reg esi

In this case ESI register points to the API name, if we track EAX or ECX will see that are the counters of the loop. These shellcodes contains a hard loop to locate the API names.

The flag -i or --inspect allow to monitor memory using expressions like "dword ptr [eax + 0xa]"

target/release/scemu -f shellcodes/shikata.bin -i 'dword ptr [esi]'

And more things to come... find a demo below:

https://www.youtube.com/watch?v=qTYmMjW3DFs

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

Familia Bueno

FAMILIA TELERIN

domingo, 28 de enero de 2024

Fast Emulator For Shellcodes In Rust

Read more

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

Related news

sábado, 27 de enero de 2024

3275 hash passwords

Seguidores

Archivo del blog

Datos personales