Cатсн²² (in)sесuяitу / ChrisJohnRiley

Because we're damned if we do, and we're damned if we don't!

Category Archives: Penetration Test

SANS SEC710: Advanced Exploit Development

SANS_Logo_REVAfter spending the week doing the Advanced Web App Penetration Testing class, what could be better than spending a couple of day doing exploit dev! Yeah, nobody said I was smart, but I am a sucker for punishment.

Day 1 – Linux

The class kicked off with a discussion of the dynamic Linux memory, followed quickly by a couple of interesting (albeit similar) heap exploit exercises. The class moved quickly (lots of content, little time) into overwriting function pointers (BSS segment exploitation). As usual the exercises (labs) that follow each section helped reinforce the information from the previous section. Although the exercise programs are simple (and often simple purposed) they do a good job of easing you into the exploit type your working on without distracting you with huge monolithic programs.

After lunch we started in on format string attacks, which left the class a little confused I think. So many characters that we’re not accustomed to in exploitation. Still, things sorted themselves out, and surprisingly I was even able to get the exploit working using direct parameter access techniques.

To finish up the day there were 2 exercises: The first was a proftpd exploit (that for some reason didn’t like working on my version of VMware Fusion). The second was the bootcamp portion of the class, and was based on a challenge from the DefCon 18 CTF pre-quals.

Unfortunately we didn’t get too much time on the bootcamp as we spent more time on format strings and fighting with proftpd than planned.

Day 1 was mostly performed using older (Gutsy/Edgy Linux) so very little (if any) ASLR or other advanced protections in place. That’s not to say the information in day 1 isn’t worthwhile… it’s just like everything else, it’s a starting point!

Day 2 – Windows

Monday morning kicked things off with an overview of patch diffing (using BinDiff, PatchDiff2, and turbodiff) with IDA Pro. For people who don’t know how IDA works, the class went through some basics on using IDA for diffing. I found this a bit of a shame personally. I have no intention of buying IDA Pro (as I’m not an exploit dev) and the demo version used in class doesn’t support diffing (which is the primary use for SEC710). I’d have liked to have seen the class stick to open-source or free versions to keep the playing field flat for everybody in class. Still, BinDiff and IDA Pro are the de-facto standard, so I can see where the class is coming from. Using free or open-source alternatives may have made the examples so complex as to be unusable.

Some background info was a little fluffy for my liking. For example, the section on Microsoft patches started off with a discussion on how Microsoft releases patches and how to get patches from the MS website. Good info, but mostly known and not really something that warrants more than a 60 second refresher.

The real meat of day 2 was working through the old ms07-17 ANI exploit. Taking it from patch diffing with IDA (free or pro) through to a working exploit on a Vista host. The final exploitation used heap spraying to get code execution. Unfortunately the walkthrough of the exploit on a Windows Vista system was trickier than first thought and didn’t run as smoothly as it could have. Exploitation isn’t easy though, else we’d all be doing it…

Although the appendix talks about ROP gadgets and touches on Windows 7 x64 and Windows 8, these weren’t covered in the class itself. There is an exercise at the end of the book however that touches on Win7 exploitation.

Conclusion

A Lot of topics the class covered were a bit over my head as I don’t do this stuff on a daily basis, and unfortunately spent most of day 2 fighting with VMware fusion issues. SEC710 is not an easy class and tries to cram a LOT of information into the 2 days without going too long despite the bootcamp section. At the end of the class there is still a lot of content that needs to be reviewed to solidify things however, as well as the additional appendix content that’s not really covered in normal class. Exploit development isn’t for the faint of heart though, and anybody who thinks they can walk out of a 2 day class as a reverse engineer or exploit developer is fooling themselves.

People seem to want to compare SEC710 with Corelan’s Win32 Bootcamp. Although they both cover exploitation, SANS SEC710 covers different topics from the Corelan Live bootcamp (Linux being the biggest example) and the classes with SANS don’t run as long ;) (Corelan likes to run 12 hour sessions both days… which is exhausting, but fun!).

Realistically there is no comparison between the two classes. SEC710 covers topics that are not covered in the Corelan class, and vice versa. As a result you end up with a broader knowledge from SEC710, but a much more detailed view from the Corelan class. Neither is better, they are simply different! Having said that, I found the explanations of the techniques are not as clear in SEC710 as they are in the Corelan Live – Win32 Exploit Development Bootcamp. Then again, having 2 days to focus on Windows means less setup, and more time to really deep dive without the confusion of describing different operating systems and how they differ.

Overall I enjoyed the class (despite not really being an exploit developer myself)… Everytime I sit in on one of these classes I learn a little more. Maybe one day I’ll actually have time to do the after class work to actually understand things fully!

Personally I hope they make some changes to SEC710 to make it deeper. To manage that I think they’d need to split the class into a 2 day Linux exploitation and a 2 day Windows exploitation class. Covering all the information in a single 2 day class just isn’t really feasible and leaves the student wanting more!

Links:

SANS SEC642: Advanced Web App Penetration Testing and Ethical Hacking (review)

After taking a year off from SANS London (a trip to Colombia was too much to resist last year), I flew back over to sunny London (ha) to attend the new SEC642: Advanced Web App Penetration Testing class with Justin Searle. As I’ve had a few people ask about the class I thought I’d write-up some thoughts as I go through the class… Hope they come in handy for people interested in the class content!

Day 1

Day 1 kicked off with a quick refresher on the testing methodology to ease people into things. SEC642 is strongly focused on the discovery and exploitation of vulnerabilities, but the importance of recon and mapping was emphasised during the process, as well as the process used to work through an application from initial recon through to the exploitation phase. One key point raised, and one that most people ignore, was the requirement to finish discovery of flaws (or potential flaws) in an application, BEFORE starting to exploit them. Although the exploitation phase is where we all have the most fun, it’s important for our clients to ensure we have as much coverage of the application as possible.

Jumping straight in, we discussed the more abstract and oft mis-used or unknown features of Burp Suite. It’s amazing the features that you never notice or use simply because you didn’t know they were there. Things like the Burp web interface (http://burp) and the ability to output log files (yes, even in the free version). We also touched on Burp scripting, although briefly. I’d loved to have dived into some more detailed scripting, but I get the feeling this process will be changing slightly with the 1.5 pro release, so maybe it’s better to wait anyhow ;)

With everybody on the same page with Burp, we moved into LFI (Local File Inclusion) and RFI (Remote File Inclusion). Alongside the simple examples there were some advanced methods exploiting LFI issues on various target platforms. Particularly interesting was the PHPINFO trick for using LFI to gain remote code execution on a system, as well as some interesting php://filter tricks to read the content of PHP files without them executing. It was good to have a test lab to try out the intricacies of these tricks and get the chance to get them running well and truly understand the ins and outs of the techniques.

To finish of day 1 we talked SQL Injection, with a short refresher in the basics before jumping into more advanced exploitation (including timing based and heuristic and binary search trees). We finished up day 1 with a couple of  SQLi labs to try out some of the more common SQL Injection tools (Havij, SQLmap)…

Day 2

Moving into the second day we shifted focus to “discovery and exploitation for specific applications”. We kicked things off with coverage of DOM based XSS, which is something that is often discussed, but seldom tested. Although the theory is simple enough, detection (and in particular automated testing tools) to discover DOM based XSS is not always an easy task. No discussion of XSS would be complete without looking at how it can be leveraged to attack clients, and as expected a number of possible payloads were discussed. It’s nice to see some examples of keylogging and geolocation payloads present, but the addition of scriptless attacks was particularly interesting. It was one of those “Oh yeah, that’s obvious… why didn’t I think about that sooner” moments. Sometimes you just can’t inject JavaScript, so having a few useful non-JavaScript attack payloads will certainly come in handy for those tricky apps.

web-app-security-imgMoving on from XSS, the class discussed more advanced XSRF attacks focusing more on the use of AJAX to perform attacks that are invisible to users. After some bad JavaScript coding (I’m no coder) we discussed CSRF protections and methods to bypass them by combining XSRF and XSS vulnerabilities within an application. The discussion of XSRF culminated in the creation of a simple self replicating XSRF attack (ala sammy).

To finish off the day we focused on application specific attacks against Sharepoint and WordPress systems. Personally I’d rather have spent the time discussing more in-depth workings of Sharepoint (or other enterprise grade systems such as Lotus Domino, SAP, etc…) than WordPress. Then again, you can’t please everybody all the time, and it was good to see @ethicalhack3r‘s wpscan mentioned in the WordPress section.

Overall day 2 was a little slow for my liking. Although it was nice to get some refresher on some points, it would have been cool to play with more varied XSS payload tricks, and maybe even look at some non-JavaScript injection (VBscript,…) and XSS via CSS, Flash files etc… Maybe SEC742 ;)

Day 3

Of all the content, the crypto day was the one I was looking forward to most out of the class. Crypto is often something people skim over on a penetration test, so it’s nice to get some practical exercises in more advanced crypto based attacks.

The day started off with a quick grounding in common ciphers and hash algorithms, and moved on to methods for identifying encryption within web applications. The meat of the day was spent discussing attacks against CBC and ECB encryption modes (including bit flipping, CBC chosen plaintext, padding oracles and ECB shuffling attacks). With a good mix of theory and practical examples/exercises the class really helped to give a good understanding of how things work in the background, and how the can be exploited to attack or extract data from a web application.

Day 3 was a theory heavy day, and certainly a departure from days 1 and 2… I would have liked to have spent more time looking at crypto flaws, but there’s more gold in them their web applications than crypto alone!

Day 4

No advanced class would be complete without talking about bypassing web application firewalls and filters. Day 4 covered some of the more common ways to detect and enumerate WAF’s and other protections, and how to work around some of the protections they offer. Some interesting techniques such as DATAURI and CDATA blocks were touched on, as well as the more common comment and onerror/onload style bypass techniques. We also covered some groundwork on HTML5 and it’s use in injection and bypassing common filters. The day finished up with a quick look at sqlmap tamper scripts and the little used evasion techniques built into sqlmap itself.

I felt that day 4 was a little basic for an advanced class. With so many options for evading detection or active filtering, I think the coverage was a little light.

Day 5

Day 5 stepped away from the world of Web Applications for a while to venture into mobile security. Although it seems at first blush to be a bit of a strange thing to include in a web app class, a lot of mobile application testing crosses over into the web app realm. Things like SOAP and REST are common to mobile applications and web application testing, providing the perfect chance to cover some mobile security alongside the standard web application testing.

Some of the background information on mobile platforms was a little too detailed for my liking (interesting, but not really relevant to web application testing), the exercises proved interesting and allowed people to play with capturing web traffic from mobile emulators.

Day 6

As with a lot of the SANS penetration testing classes, the final day of the class was a capture the flag style challenge to enforce some of the topics covered in the class. A majority of the keys were pretty simple to find, and I won’t spoil it for you by giving you too much info. I’d have like to have seen some more of the crypto content in the CTF, but I guess in a small timeframe you can’t do everything!

Overall the CTF was a fun experience… and as usual, I did terribly! Somehow I just can’t get into CTFs

Conclusion

The SEC 642 is a very young course, and isn’t without its flaws and issues. Saying that, the foundation is there for a good followup to the SEC542 class. With a few tweaks and changes (that I’m sure are already in the works) the SEC642 class should provide a good addition to the SANS penetration testing range of classes. If you’re doing penetration testing and found the SEC542 class a little too light for you, then SEC642 is definitely something you should look at in the future.

I would have liked to have seen even a passing mention to Metasploit as it pertains to Web Application testing, perhaps even replacing some of the less advanced sections with a few useful examples and labs. Still, you can’t have your cake AND eat it… and most people don’t see Metasploit as a useful tool in their web application testing arsenal (mores the pity!).

Some days may spend a little too long reviewing basic principles (sometimes for good reason), as well as a little too much focus on defense sometimes (defense is good, but this IS an exploitation course). You can’t please everyone though, and I think the class strikes a reasonable balance.

Links:

{Quick Post} Mail headers

I know this topic has been discussed in various venues under the flag of OSINT, but I came across a nice example that I thought was worth sharing… even if just to re-iterate the point!

Following an email to a unnamed company, threw up a couple of interesting facts that companies should really be aware of. Information disclosure is always present, but email headers and failure notices are a goldmine of information if you take the time to dig into them.

Note: nothing I’m posting here is private or restricted. Anybody sending an email to the public relations email address will receive the same information. Don’t shoot the messenger!

Diagnostic information for administrators:

Generating server: democorp.CORP

group@democorp.com
#550 5.7.1 RESOLVER.RST.AuthRequired; authentication required ##

Original message headers:

Received: from mx4.dfw1.democorp.com (10.7.9.76) by smtpout.democorp.com
 (10.12.120.25) with Microsoft SMTP Server id 14.2.298.4; Mon, 9 Jul 2012
 09:14:34 -0500
Received-SPF: Pass (mx4.dfw1.democorp.com: domain of
  xyz@c22.cc designates 209.85.214.180 as permitted
  sender) identity=mailfrom; client-ip=209.85.214.180;
  receiver=mx4.dfw1.democorp.com;
  envelope-from="xyz@c22.cc";
  x-sender="xyz@c22.cc"; x-conformance=spf_only;
  x-record-type="v=spf1"
Received-SPF: None (mx4.dfw1.democorp.com: no sender
  authenticity information available from domain of
  postmaster@mail-ob0-f180.google.com) identity=helo;
  client-ip=209.85.214.180; receiver=mx4.dfw1.democorp.com;
  envelope-from="xyz@c22.cc";
  x-sender="postmaster@mail-ob0-f180.google.com";
  x-conformance=spf_only
X-SBRS: 4.4
X-SenderGroup: None
X-MailFlowPolicy: $ACCEPTED
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtkBAHvm+k/RVda0kGdsb2JhbABCA4JKpEeHVgGIfAgiAQEBAQkJDQcUBCOCIAEBAQEDEgIsAQE4DxYGAwECLyISAQUBEgIIBw4ECBqFb4F8C45NjioJA4pmhC4BBY5kBotAgmuDIYspihCBEoUwhESDIj6EAIFd
Received: from mail-ob0-f180.google.com ([209.85.214.180])  by
 mx4.dfw1.democorp.com with ESMTP/TLS/RC4-SHA; 09 Jul 2012 09:14:33 -0500
Received: by mail-ob0-f180.google.com with SMTP id uo19so20894072obb.11
        for <group@democorp.com>; Mon, 09 Jul 2012 07:14:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=c22.cc; s=c22;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        bh=UTOmJBpa86TfxGjU5tQXis28YV6Sw/gTVT6wUE6UMws=;
        b=eSSc9Wsxr4Tn1WRIl6iQX8C67WGREgXDr1/U8r4vSfUTMRxXbyH4pYYdGR08yt8RQi
         iC1AkTr1hNqvBUJ4mt5ELhfW8NPwfRD9W2DShyFS2engogMPg6EKt6DuWuCy0hLRJOzN
         hmPSk/1VTuegKJa8nIAwTW5I/hCL8EkJKtn1M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20120113;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type:x-gm-message-state;
        bh=UTOmJBpa86TfxGjU5tQXis28YV6Sw/gTVT6wUE6UMws=;
        b=X+t+5o5x/V/kpc1b2fMKr31W1wj5jLnkEfhwjLVEqLrLMczv2WjyI0VCDXDmBLJQ7R
         DvDRMRnB+Hwk/xhDwOcogOvHucrXk3wCrgAGZqnFbKgqjcoR99OnRIaSgFmYeHE1lNmN
         twOHoamsRoBmeh8xtuCzt24WdcBiSrw9VzugUu2xJ+3/9kWrJijqk0I4VaFDrNIeu6TH
         DmGIEtZojB0MLLZC/a4x2Bg7AhnKElP0AQTnOihXw+CuoJcbI1GzIdCkB3mBHtnvPW9Z
         GmtqoKjvwvxaYOlOPkM3zKilOJ4oc8QywG89sFDT7+zs3zaL53JPlmJGpzV3rBjmOY4J
         eQ9g==
Received: by 10.182.216.99 with SMTP id op3mr15297272obc.30.1341843273175;
 Mon, 09 Jul 2012 07:14:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.209.3 with HTTP; Mon, 9 Jul 2012 07:14:12 -0700 (PDT)
In-Reply-To:
References: <CAOXycj0yy-qAmWUz6PpqjAVX=XOV3=eEJN3VU=iQsZfj_zDH0g@mail.gmail.com>
From: Chris John Riley <xyz@c22.cc>
Date: Mon, 9 Jul 2012 16:14:12 +0200
Message-ID: <CAOXycj2BvTr19Raa-qt4KbBo0QigNATR20VH9fwpKL3oJwQxdA@mail.gmail.com>
Subject: subject
To: <group@democorp.com>
Content-Type: multipart/alternative; boundary="f46d044786e7a4540a04c4663b39"
X-Gm-Message-State: ALoCoQkSGcaZiYEGGYIMbwVNAM5LTm/F/gFzBwRRIeWWGriOQ48yR0cwLsmbBD6aFt5YFVyrA+
Return-Path: xyz@c22.cc

Taking some of the more interesting points from the above message,  you can extract the obvious information such as internal IP range and the version of Exchange Server in use (14.2.298.4) from the first few lines of the error (lines 10-11).

Digging a little deeper however you can also extract some interesting information about the security in and around the email system (lines 32-35). This includes details on the use of TLS for email transfer (ESMTP/TLS/RC4-SHA), and a hint to the cipher (dependant on the support ciphers on the sender-side). What’s also interesting is the “Received-SPF” and “DKIM-Signature” (lines 13 and 36). In the case of SPF the remote mailserver is actively checking the SPF record and is performing a reverse lookup to check that the sending host is permitted to send email on behalf of the sending domain (c22.cc). In this case everything is fine, but it’s important to know if you’re performing an authorised pentest… especially if you’re phishing ;)

The last little bit of information you can squeeze out is the exposed “X-IronPort-Anti-Spam” and “X-SBRS” headers (lines 27-31). From this you can gather that the remote server is running IronPort and the email you sent scored a 4.4 on the IronPort’s anti-spam rating. Again, this is good for those tests where you’re phishing and need to see what score your emails are getting. Simply sending your prepared email to a non-existent (or in this case, failing) email address should net you some feedback on how good your phishing email is perceived by the IronPort.

The “X-SenderGroup” and “X-MailFlowPolicy” headers (lines 28 and 29) are also added in by the Cisco IronPort, so might be a source of interest!

My suggestion to companies is to check the data that your mailservers are exposing through failure notifications… even if you can’t stop this data from leaving your network via configuration tweaks, it’s at least good to know what information you’re providing to attackers!

Follow

Get every new post delivered to your Inbox.

Join 132 other followers