So its the day after the conference and I sit here in bits. Unfortunately since friday i’ve been struck down with an attack of sciatica however I downed my ibuprofen along with a few paracetamol for good measure and drove the many hours up’t north and found myself in Sheffield at the best conference I have had the pleasure of attending thus far.
Robin (@digininja) appears to have taken all of the best bits from every conference out there and packaged them into one incredibly affordable weekend.
It started on the friday when arriving up in sheffield, the actual real conference starts on the saturday but there is a well publicised “pre-con” meet up in a local tavern. The best bit about this being a relatively new to the field (4ish years now) and shy as hell i’m not exactly known to anyone. I’m not in the league of sausages, I know a few testers and I can now recognise a few of the twitter legends I follow, but I’m not exactly on any invite lists for pre-con meetups or beers.
All of that doesn’t matter here, as its a publicised meet up, everyone rocks up and all of a sudden I’m talking to folk such as digininja, Finux DaveHardy20, FreakyClown, etc… people i’ve followed since starting out in the world of infosec, over a few beers and shooting some pool. There are no barriers and for someone who suffers from extreme social anxiety usually, I found it brilliant.
Saturday came and wow… again a brilliant setup. Breakfast provided for the attendees, a kids track that resulted in some AWESOME lego robotic RUBIK cube solvers, fantastic conference loot (loving the lockpicks from Mad.Bob) and a keynote by the one and only Campbell Murray (@xyz2k). Refreshingly a well balanced technical talk but also not too heavy for the first talk, opened the conference with a good few laughs #blindslided and left me nodding my head excessively at everything he had to say.
The Gist: Penetration Testing was never meant to be a test of compliance. (Checkbox Pentesting) and Red Teaming as we (the industry) call it is NOT Red Teaming…
Analogy: Red Teaming is taking a block of thermite to the hinges of a safe door and smashing it in with a sledgehammer
it’s how penetration testing should and used to be with a wide scope, a definition of the client’s crown jewels and an allowance for the testers to make use of their imagination, not for them to be constrained to arbitrary compliance objectives, low costs and unrealistic timelines.
Following up that talk I watched an exceedingly knowledgable Darren Martyn (@infodox – http://insecurety.net/) give a bloody blinder of a talk on hacking embedded devices. Not a talk aimed at those of you with exceptional hardware hacking experience but rather aimed at the low hanging fruit, through a series of examples and a detailed case study he illustrated just how easy it is to find these flaws and then to exploit them. If you run a home router, chances are it’s part of someone’s botnet, this stuff was ridiculously easy to do and has made it firmly onto my “to-do” research list.
A few more talks and a lunch that had more than enough food to share amongst the numerous attendees the next talk worthy of particular mention for me was Dave Hardy’s and Ben Turner’s talk on powershell and their work with the metasploit framework. These chaps have taken metasploit’s capabilities with powershell and made it bloody brilliant.
Gone are the days of running a single script and bodging scripts to work. They have created a full blown new “payload” type which returns you a full powershell session with backgrounding, the ability to actually interact with the objects returned as and when you require them and a whole series of utility post modules/scripts that make life even easier.
Evading AV? Powershell is easy mode right now for doing that, these chaps have modified inveigh (read: responder using powershell) in order to work appropriately with the new payload type, you can now invoke-mimikatz within a powershell session and essentially given the armoury of powershell scripts out there, you basically never have a reason to touch disk and therefore never get caught by AV.
Seriously, I can’t do their work justice with a simple write up as part of a post here but check out their websites and get the info.
So that brings us to the closer where Harold and Kumar (FreakyClown and Dr Jessica Barker) went to White Castle and taught us to burn the motherf…ker down #pookie. Or rather gave us a disturbing account of how the infosec world could go. The issue we have as an industry is trying to sell what is basically ineffective, we scare-monger users and our sales staff promote new shiny bleeping blinky products until they are blue in the face but people don’t appear to respond as we believe they should and we say that it’s their problem. It isn’t, it’s ours and we as an industry need to drive a new approach.
Roll on to the evening party where netitude placed £3k behind the bar, I believe we achieved the goal of drinking the bar dry by about midnight. It was a brilliant evening, starting with a scavenger hunt, Dr Jessica Barker (@drjessicabarker) and FreakyClown (@__freakyclown__) led us all once again only this time into a quiz that proved I do not know my game consoles anywhere near as good as I thought I did but oddly I do know that Coco Chanel was the inventor of the Trouser Suit and “purdy” is a haircut. 🙂
Throw in some copious amounts of drinking with a few chaps from Prospective Risk, Netitude and others while being expertly chaperoned by a member of the SteelCon day staff who’s only name I remember is “Laura” and “Woody”.
The “Flatcappers” (the conference badge was a traditional flat cap) partied the night away and it all ended for me in the early hours of the sunday morning where I was left wondering “wtf!?” as we emerged to bright sunlight.
05:10am… bedtime, thank goodness for late checkout 😉
A truely fantastic conference with the right mix of tracks, talks and one that doesn’t just focus on the 9-6pm conference but one that really put the effort in around the sides to provide a cracking experience that will have me smashing that F5 key once again to grab a ticket next year.
For those of you that want more, on the Sunday they also had laser tag/quasar activities and pizza lunch planned out, I myself opted to sleep and neck paracetamol 😉
After a weekend of activity, my sciatica attack never did end and I was left crawling out of my car this evening poking at my medicine cabinet unable to stand up properly, trying to knock the dihydrocodine off the shelf so I may get some relief.
I may be in agony but every minute was worth it. I learned so much in the company of so many excellent people, it was worth every wimper.
So if you’ve recently tried browsing to my site in the last 30 days or so you may have been presented with a not so helpful error message showing that my bandwidth had been exceeded.
Turns out my site was the victim of a dDoS attack/bruteforce at the end of May/Beginning of June and initially while my hosting provider noticed it and informed me of the attack, the “fix” I implemented which was to eliminate xml-rpc.php from my wordpress site initially showed a huge drop in CPU cycles from the hosting PoV, what I didn’t appreciate is that error pages come out of your monthly bandwidth entitlement.
So… 12 hours later a grand total of 5GB of “404 – page not found” texts were downloaded and pow, site was down.
Hosting provider has been a great help throughout the attack and while there were some false starts and confusing conversations going on I finally got through to their support ninja’s had my “fix” confirmed as working and my site is now up and running, at least until someone takes it upon themselves to burn it down or have another go at logging in.
The fix…not using .htaccess to deny (that results in burning your data allowance, but does reduce CPU load) but rather use .htaccess to perform a 302 to http://0.0.0.0 for any matching request.
MWR HackFu 2015
I was invited along to HackFu this year and spent a hugely enjoyable 3 days. MWR Infosecurity definitely know how to run a major cybersecurity event and while a majority of us were penetration testers or security researchers teams were mixed with software developers, mathematicians, etc… even those who did not have a technical skillset could learn new skills such as lockpicking or use their powers of deduction to discover clues and work out who were the moles and the mastermind behind it all.
Incredibly well structured and the challenges I took part in were so well thought out they’ve given me a few good ideas to put together one of my own. From interfacing with game AI to produce “real world” effects from associated hacks to emulating ICS systems having to hack a water pump to retrieve a usb key.
Honestly, if ever you get the opportunity to participate in it, leap for it and go expecting the unexpected 🙂 Genuinely a fantastic time.
I run a headless install of virtualbox with phpvirtualbox as the front end to it at home on an old N54L microserver (16GB ECC RAM, 2TB Raid 5 Array, Ubuntu Server LTS), it runs beautifully aside from one thing.
It uses VRDP (which is a bloody neat solution, I love it) to show the consoles and CTRL-ALT-DEL doesn’t actually get sent to the host.
Instead, use CTRL-ALT-END and that’ll see you right.
That took a keyboard mash and a bit of googling to find that one.
When importing a vulnerable VM a colleague has made and exported using OVF format into virtualbox… even though you have the XP safe “PCNET-FAST III” selected that should work without any need for additional drivers (here’s looking at you intel)…
Make sure you “update” the driver to the non VMWare Accelerated version, otherwise your network interface will not start.
That’s 30 to 60 minutes of “WTF!?!?” that I’ll never get back.
So every quarter my company arranges an internal “conference” where the members of my team have to come up with some sort of presentation discussing research or learning that they have done in the past 3 months.
Often this presentation is written in the last few hours of the last day left and scraped together in a panic, however this time I found myself with a topic of particular interest that I needed to know more about.
I’m a penetration tester, a jack of all trades if you will however my strengths I would say primarily lie within web application security or circumventing client lockdowns.
My network-fu leaves much to be desired and I will say it is one of my weaker points.
So please forgive me if indeed this post is teaching you to suck eggs or appears to be rather low brow for a working penetration tester, this field is by no means my forte and this post is about something that actually I don’t see too much of and ultimately is a result of being bucket-dunked into a world of pain and wanting to actually improve my knowledge to a degree where it’s no longer as painful.
It is an amalgamation of a series of blog posts, with most of the information coming from the chaps at spiderlabs (who have now in the time I took to write up this post, released part 3 of their post on cracking IKEv1 and it’s a cracking read, highly recommend it).
So onto the content…
Finding the damn things
IPSEC VPNs traditionally run on UDP port 500. The use of UDP is an important factor here as UDP based services don’t have to offer any feedback or indication that they’ve received stuff (UDP/IP networking 101). Worse still the RFC for this states that IPSEC VPN endpoints can quite happily drop whatever they do get on the floor if they don’t like it and will silently do so.
So send the wrong stuff and you could end up seeing:
That outcome appears to be either a special configuration or due to a particular vendor’s implementation. I have seen it in the wild but traditionally this happens:
I receive a notify message. Notify in the world of IPSEC VPNs tends to mean (at least in my research) one of two things.
It doesn’t like the “transform” you’re using to communicate with it.
It doesn’t like you – it may have an access list associated with it and you’re not in it so it will not negotiate a connection with you.
If it’s number 2 in that list, you’re on your own. I’m interested in the case of number 1.
What is a Transform?
A transform is a series of “instructions” that specify things like:
Diffe-Hillman Group ID
What those things do is somewhat unimportant for the purposes of this post however all you do need to know is that these are typically specified in terms of numbers on the command line.
AES 256, SHA1, PSK Auth, DH Group 2 translates into –trans=7/256,2,1,2
ike-scan is old
So our main problem is that ike-scan comes from a period of time (2003-2007) where AES support on VPNs does not appear to have been widespread. In fact much more common was the use of DES and 3DES encryption and as such ike-scan’s default scan setup scans for exactly that.
So now we know this lets follow ike-scan’s own guidance (available at their wiki: http://www.nta-monitor.com/wiki/index.php/Ike-scan_User_Guide) and script ourselves a brute forcer.
The next bit of code will generate EVERY transform listed within the nta-monitor wiki, however as the wiki reveals each transform is a 16bit unsigned number, giving you 65536 possible values across 4 parameters, resulting in 18 million trillion combinations (65535^4) or 18000000000000000000 (20 digits long) for those who prefer actual digits so it’s somewhat unreasonable to smash that many transform requests across a network connection not forgetting the fact that the vast majority of numbers in that list are likely to not be implemented as anything so the guideline in the wiki (generated from the RFCs concerning implementation of VPNs) is as good a solution as any.
for ENC in 1 2 3 4 5 6 7 8; do for HASH in 1 2 3 4 5 6; do for AUTH in 1 2 3 4 5 6 7 8 64221 65001; do for GROUP in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18; do echo “--trans=’$ENC,$HASH,$AUTH,$GROUP’” >> ike-dict.txt ;done ;done ;done ;done
And now you have a dictionary of 10,800 transforms to throw at any VPN you may come across which should increase your chances of success.
Using the dictionary effectively
So bare with me on this one. If speed is your thing, the wiki suggested method is probably best. With my virtualised test rig of an ASA 8.0 box I can smash ~150 transforms in a single proposal and it’ll respond properly, reducing the actual number of network requests to 72.
However if it’s a local network I like to encapsulate it in a while loop. It’s rusty and greatly adds to the time for testing (takes something like 3 minutes instead of 1) but it simplifies things when you don’t have the necessary lookup tables or cannot be bothered to figure out the syntax to recreate the handshake once your discovery scans are completed.
while read line; do
echo ike-scan -M $line 127.0.0.1
ike-scan -M $line 127.0.0.1
; done < ike-dict.txt
Yep it’s simplistic and dirty but hey a simple double grep then just gets me the line I want.
grep -B7 "1 returned handshake" ike-output.txt | grep "--trans"
Being Overly Aggressive…
So the truth of the matter is that the above does Main Mode handshakes which to my knowledge are invulnerable. However my knowledge extends as far as google fu and the NSA handbook (Network Security Assessment Vol 2, not the National Security Agency) so feel free to correct me in the comments if you’re wrong, this is as much a learning exercise for me as it is for anyone who is reading this trying to figure things out.
While I’ve only ever seen machines responding for the same transforms regardless of Main Mode or Aggressive Mode, according to my research I’ve discovered that a machine may respond for a different transform for each method. So in truth the only way of truly discovering all possible Aggressive Mode capable VPN endpoints is by scanning with -A. Unfortunately this will greatly slow down your scan taking at least 2 seconds per connection so I would advise only using the wiki based method for that.
Assuming you’ve now found yourself a VPN endpoint that responds to aggressive mode handshakes. What next?
Pskcrack tends to be the tool of choice in most of the online articles you’ll read online. People favour it for bruteforcing/dictionary attacking the hashes. Fact is, this too is ancient tech.
Based on CPU cycles it struggles when you compare it to ocl-hashcat or cuda-hashcat (depending on the flavour you prefer).
PSKCrack ~ 100 plaintexts a second were attempted.
Hashcat (CPU Based) ~ 2000 plaintexts a second.
cuda-hashcat (GPU Based) ~ 2.6 million plaintexts a second.
Using cuda-hashcat to brute force the resulting hash is clearly the way forward as the optimisations and improvements (including the ability to make use of GPU processing power) far out-perform the traditional PSKCrack route.
Myths and Realities
The common misconception is that IKEv1 + Aggressive mode handshakes are bad, that you only ever receive a valid handshake when you correctly guess a groupid and that using these two things, results in the ability to crack a hash, gaining access to the internal network and therefore Nessus ranks them as a CVSSv2 score of 5.0 suggesting that a partial loss of confidentiality is possible and that difficulty of exploitation is low. This may well have been the case in 2005 but in 2014, 9 years on things have changed somewhat and in my opinion the vast majority of encounters of this configuration will be low.
In order to gain access to a VPN using IKEv1 and Aggressive Mode Handshakes you need the following:
A working transform (Done as part of discovery)
A valid Group ID
So we need two things? Not quite. Most if not all VPN instances also employ secondary authentication methods, be that X-Auth, Certificate based or RSA Two Factor Auth. So now we’re adding a second level of complexity, i’m not great at network comms and certificate based/RSA attacks are likely beyond my skillset so we’re skipping that.
If you can do it, awesome. However i’m not the fastest tester so trying to capture RSA tokens across the wire and replaying them before they expire will just end in epic failure on my part. I’ll focus on X-AUTH the weakest of the 3 methods.
So now we’ve established we need:
A working transform
A valid Group ID
A valid X-Auth Username
A valid X-Auth Password
Having all 4 of the above will finally grant you access to the network behind the endpoint of some sort.
Enumerating Group IDs
So I’ve seen and read countless (even recent) VPN attacking articles that say:
Use a groupID to obtain a handshake, shove it all in pskcrack and use the psk to connect to the network
The problem with that is that since 2005 Cisco has been patching group ID enumeration vulnerabilities.
Prior to 2005 – Only a valid Group ID would return a handshake. This is known as CSCeg00323 and is now patched on pretty much all systems you would come across. Despite this, searching for “VPN” attacks will often result in this being overlooked and the demonstrations you find will ignore the fact that this has been fixed.
Now with or without a valid group ID a handshake is always returned. If the ID is invalid (as is likely to be the case when brute forcing) the handshake and the resultant hash is generated using a random password (in some cases null), which if cracked, will get you no closer to gaining access to the hallowed network.
So we move onto method 2 of enumerating group ID’s…
Prior to 2010 – Only a valid Group ID would return a dead peer detection header. This is also known as CSCtj96108 and would result in this contrasting output in ike-scan.
Some tools support this in particular the spiderlabs chaps have a few scripts available at their github that do this detection when given a dictionary of words to brute force.
Additionally the enterprising chaps at portcullis have “iker” which does much the same.
However, this was patched 4 years ago, by making EVERY request return a DPD entry.
Additionally as it was 4 years ago, that’s plenty of time for hardware refreshes and actual patches/firmware updates to be applied. As your (and mine) mileage may vary with this one we move onto the latest way for enumerating group ID’s.
I have to thank Spiderlabs for all of this as essentially this is their baby, i’m just writing it here in this blog as well a reminder to me and to share the good news.
After the 2010 patching of DPD, a person far more intelligent than me decided to see what else might be different between a valid and invalid VPN response and during his research discovered that there were differing packet counts depending on the validity of the Group ID sent.
In the case of a valid ID 2 responses would be expected. In the case of an invalid ID, 6 responses would return over a longer period of time (almost as if the service tries incredibly hard to resolve the bad ID).
The major downside with this attack is that it takes time, a considerable amount of time. Those 6 responses span 30 seconds, now there are ways to speed it up (e.g. assume 3 or more responses = fail) but even then it’d still be at 9 seconds per ID attempted.
Additonally, this vulnerability was patched in 2013 as CVE-2013-1194 and I know of no others that replace it.
However the vulnerability above is to my knowledge our last hope of discovering valid IDs on relatively modern kit and to my knowledge the only tool that makes actual use of it is the groupenum.py (note the python extension this time) provided by spiderlabs and available at their github given above. I am unsure if IKER provides the same capabilities, it mentioned “response analysis” in it’s blurb but i’m not sure if that means DPD detection or packet counting support.
A downside to this is that groupenum.py currently only supports DES and 3DES transforms, so in the case of the above AES256 VPN endpoint, there’s no simple script to do it on my behalf.
If I were a master coder of python (or actually did the Python E-Learning package my company has bought for me) I’d have a bash at coding it up myself, maybe you (the reader?) can help out?
In my opinion i’ve pretty much discounted using IKE-SCAN as a valid tool for finding VPNs and will in future be making more use of Portcullis IKER.
Purely because it’s a tool that appears to test a large number more transforms than I believed were present than ike-scan and it automates group ID bruteforcing if you provide it a dictionary using at the very least the first two methods discussed and may in fact make use of the third.
Additionally it automatically scans for aggressive mode transforms too. It is essentially a start, go-make-coffee, review results tool. Perfect for a busy pentester doing a million and one other things in a narrow timeframe.
Continuing on and beating XAUTH…
So our current status is:
We’ve discovered the VPN Endpoint
Found a valid transform it is willing to communicate with
Using a dictionary we’ve correctly guessed a valid Group ID.
If you were to take what was out there on VPN security you would be forgiven for thinking that’s it! We’re in… but we’re not. We still need those X-AUTH credentials.
How do we get those? MitM is the only way I came across (Edit: This has changed, read on for more info). Pretty sure you could brute force them but you don’t even know a valid username for the service so you could be there a fair ol’ while.
So once again the IKEv1 + Aggressive Mode issue becomes even more difficult to break, As you need to be appropriately placed to perform said MitM attack, however assuming there are people logging in from coffee shop hotspots and you’re there too. This is where FIKED comes in.
FIKED – Fake IKE Daemon
Using the details you have discovered so far and some arp-spoofing or Wifi pineapple, Jasager/Karma action you can using FIKED set yourself up as a fake VPN endpoint, with the correct group ID, which would complete Phase 1 auth and move the client to phase 2, where the XAUTH comes in.
The client would blindly send their credentials believing that they are connecting to the right VPN endpoint (no certificate checking with XAUTH), et voila! You have captured their creds in the clear.
So in order to get FIKED to work you have to figure out a way of forwarding the victims traffic through yourself. I achieved this by setting up 2 arp-spoof sessions to capture traffic in both directions between target and their gateway.
However, FIKED was the only tool I found capable of performing this MitM attack and despite me having successfully set up arpspoof (tried ettercap too but wanted to rule out weird packet forwarding nonsense), in both directions, with TCPDUMP showing UDP traffic on port 500. FIKED never responded to my requests and VPNC on my victim box would just hang until it timed out never receiving a handshake.
Only by deliberately connecting to the FIKED VPN endpoint could I actually get the screenshot I used above. Colleagues I demo’d this to suggested that it could be that I was using 2 virtual hosts, across a virtualised network causing the issue and that may still be the case. I never did get around to pinning it down despite spending many hours on it.
If you can get this working, please do let me know what on earth I was doing wrong.
Now you have:
Located a VPN Endpoint
Successfully obtained a handshake with it
Discovered a valid Group ID
Performed a man in the middle attack against a client and captured the XAUTH credentials
Finally, now you can connect and reap the rewards of completing one of the most involved “hacks” you’re likely to complete in your lifetime. If this is a CVSSv2 score of 5.0 then CVSSv2 is even more broken than I thought.
The use of aggressive handshakes is nothing without some context applied, as is the case with most things in the security world but I have seen many reports with it just shoved in with no context applied. CVSSv2 score 5.0.
This whole process was a learning experience that taught me from the ground up some information about VPN’s in particular this variant, but I learned a lot about other subjects as well. It got me comfortable with the ins and outs of some rather complex cisco stuff (at least in my opinion) and let me get to grips with the intricacies at getting Virtual Box working in tandem with GNS3 on Ubuntu 14.04.
It also led to some expensive purchases from Ebay. So if you want a Cisco VPN Concentrator 3000 series with 2 SEP-E modules, dual redundant power supplies and no idea if it works or not. Let me know 🙂
But wait… there’s more!
I mention in a section above about bruteforcing XAuth protection. It turns out the enterprising chaps at Spider Labs have once again been busy and have released a script called ikeforce.py to do just that.
I won’t completely regurgitate their blog-post here as I think I’ve done enough of that above, but if you’re interested in taking this further and proving the risks of IKEv1 Aggressive Mode to a client I’d highly recommend checking it out (Link in the reference section below).