I started writing this blog post a long time ago (October 2013 wordpress tells me) and figured it was about time I published it just to clear my decks of “draft” posts as it were. I intend to publish things more often but maybe not all Pentest based, some ham radio and electronics gumpf may filter into it as those are also hobbies of mine.
With that and the slight addition that this was going to be NFAL Episode Two on it’s own so its now kind of NFAL Episode 2.5 The continuing adventures of noddy testing… on with the original post!
Forgive me if this comes across as teaching all 1 of my readers to suck eggs but this is just a dump of common ways I often find useful for breaking out of kiosk jails.If you’re a penetration tester or even a savvy user, chances are you already know of these methods but this is noddy stuff, purely because I thought it made for a fun blogpost, it was fun playing with it on client systems at least.
I did this as a talk at an internal company training day and titled it “Smashing Windows” slides for the talk will be attached at the bottom of the blogpost for what it’s worth but I’ve no recording of it and this blog post is essentially just it regurgitated from memory 🙂
Recently I did some testing involving the “Remote Application” features of terminal services through a terminal services web gateway.
Initially logging in using AD credentials on the front page you’ll be presented with a few icons on the webpage which in turn launches applications. (Similar to CITRIX stuff i’ve seen in the past). You get presented with a full application as if it is on your desktop, similar in the way VMWare Fusion works on the Mac, its not a full “session” but rather an “application session”.
The beauty with it (at least from our point of view) is that File – Open, will open files on the remote server (providing they haven’t GPO’d paths out of the address bar, etc).
Spawning any processes will spawn them on the remote server and present them to you over terminal services. So if you get an external link to click, it’ll spawn IE which again will be on the remote server.
Another thing to note is that the processes you’re spawning will be on the application server serving that particular application not the web host that is just presenting the applications.
For a recent client I had access to about 6 different applications each one hosted by a pair of load balancing application servers. So breaking the jail on one, got me MSTSC and I just logged in using that into the other application servers/etc that made up the network (having a nice portable portscanner/discovery tool is very useful at this point).
Method #1 – Open Sesame
The File Open and File Save dialogs are king. If you have access to one of these you’ve basically got a mini explorer.exe. There are several avenues of attack.
The Orange Box – Known as the breadcrumb, this little thing normally is affected by some GPO and is limited in use but can be handy hopping back up the directory structure.
The Yellow Box – Filename box, Unlike the breadcrumb this one appears to be affected by different GPO policies and is not always locked down. I have been able to browse to C:\windows\system32\cmd.exe in here when the breadcrumb wouldn’t let me out of my own profile. Try typing exact paths to existing files and you may find yourself lucky.
The Red Box – Search and Help. Two great ways of breaking out of the jail. Search can often get you files, providing your “high” enough up the tree. Help can find you ways of popping Internet Explorer open. So can search if its unsuccessful finding files, it’ll often prompt you for “search online” which will likely result in IE spawning.
The rest… it’s unlikely you’ll get a nice folder pane on the left hand side, normally you’ll end up with some basic folders available but no ability to browse out of your user profile if its locked down, but its worth a quick look and the file type box, that will limit you when writing a file or saving one. If it has an “all files” option, that’s better.
Finally right click! try it… if you’re lucky you’ll be able to write a file, rename it to .bat or .vbs, get some script running commands for you, its a long shot but hey it might work.
Method Two: IExplore.exe your hard drive
Aside from the usual address bar file://c:\ or browsing to your own metasploit browser autopwn. There are also ways and means of breaking out of this that aren’t so obvious.
File – Open… Or the address bar, IE can open any files. It’s not limited by file filter, it can also open network resources just fine and view folders. Great for accessing hack armoury resources.
Drag and drop… Want to exploit the file “open with” dialog? Drag and drop an unknown file extension onto it and it’ll pop it right up after you hit “open”.
Working on an embedded windows client (*Cough* Embedded XP Wyse Terminals*cough*) and have no access to the file system? That sucks. Try tools – Internet options, open objects and open files will often net you two different drives, the first being the system ram drive, the second being your user profile area.
Finally, have access to the file system but still can’t spawn anything interesting? Try firing up word or any of the office suites, how?… Look for “read me” and licence files.
You may get lucky and find some .doc style terms of service links or be able to create your own .doc. Once you’re in word go for macro execution and you’re winning.
Method 3: If in doubt… give it a clout!
Also consider the windows error reporting dialog, on one particular job I couldn’t access notepad.exe myself and the file open dialog I had access to could only see *.acme files, so was pretty useless.
On occasion I get given the task of testing a client’s website using the terminal provided by said client in order to in the client’s words “Prove what a malicious user can do with the tools we give them”.
So in order to not drive myself mental trying to pentest a web app manually in IE, without being able to change any settings. I work out a way to get burpsuite on the box.
The beautiful thing about burpsuite being that it’s JAVA and java.exe happens to be one chuffing huge hole with endpoint protection mechanisms and application whitelisting.
Okay so problem 1 solved.
Onto problem 2 now, they lock down their “connections” tab in internet settings but as we already know how to bypass whatever pre-existing proxy connection they have and replace it with our own burpsuite details using a little VBA and the techniques given in this post this is no longer a problem.
Problems always come in threes so what is problem 3 you ask?
Or more specifically, the distinct lack of a “continue” link to allow us to ignore the self signed cert warning and continue with our traffic being intercepted by our burpsuite proxy.
This situation is actually a product of the following GPO setting:
Anyone who’s been around any length of time with IE probably already knows that this error page is a resource loaded from a local dll. This is true for every “friendly http error” message you get in IE.
Question is, how does the DLL know not to show the “continue” message?
It does it by a variable within the URI, what variable? the “PreventIgnoreCertErrors” variable. This variable is usually not shown with the error message unless the GPO setting is set to enabled.
So you know what is coming next, yup. Copy Pasta my friends, So copy & paste and remember to change the damn variable to 0 before taking a screenshot 😉
and hit enter.
And finally, do what the message says, click continue…
Voila! Now you can test with your self-signed burp certificates or bypass yet another security control (that is actually a fairly wise one to have) on your network.
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).