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).
Why do I get excited whenever I am presented with a thin client, with an RDP or CITRIX or VMWare View session to a backend virtualised desktop?
Because you can almost guarantee the thin client is the easiest local lockdown check you’ll ever do.
There are some caveats to this in that thin clients using some custom *nix firmware can be stupidly hard to do anything with locally at least, however if you see any of the embedded OS style thin clients, well chances are you’re already administrator on that device you just didn’t know it.
Let’s take a common terminal I see knocking about, the Wyse terminal. Its principle defence against you is that of the “restricted account” and its “file based write filter” with that filter turned on, everything you do is only temporary.
Due to the FBWF, doing patching and updates on the OS really is a pain in the arse, add in the normal situation that the devices they are rarely controlled by GPO preferring to be controlled by a local policy instead and you’ve got yourself a tasty burger.
So first, what is this restricted account thing I’m talking about? Well on Wyse both the “user” and the “administrator” accounts are local administrators. The only difference is that the User account Sid is listed within a “restricted profile” registry key. Any accounts not in that have full access to the underlying OS.
So first, get yourself a shell. Pop it via any of the means I’ve discussed previously (to come in a future blog post). Even if you resort to dropping it on a USB and getting it in that way alternatively here is yet another “breaking the jail” method that worked pretty well on an XP Embedded thin client.
As the normal user, open up printers and faxes, using the view menu open the folder bar. Now browse the ram drive based file system to either create or find an “unknown file” you need something that windows doesn’t know how to open. Double click and you’ve got the open with dialog. Within this, specify a path to an executable you wish for the file to be run in. Make this path c:\windows\system32\command.com. (If its windows 7 pop powershell.exe or powershell_ise.exe instead) Hit okay and apply or whatever you need to confirm your change and get out of the dialog.
What happens next is interesting, command.com will spawn, fail to understand the actual file and then drop you to a command prompt.
It won’t have a system path so every command will have to be fully written out but it will work. I suggest doing:
Before doing anything else, swiftly followed by as remember every account is local admin on this terminal and the only controls are a write filter and a restricted profile registry key:
net.exe user /add hacker password123
net.exe localgroup administrators hacker /add
Now you need to log off, which is not as awkward as you think given there are no menu options for that on the restricted account and chances are ctrl alt del doesn’t let you either.
shutdown.exe -l -t0
Enter this command and hold down the shift key. You don’t want to restart the machine or the FBWF will reset everything and you don’t want it auto logging in as the user account either which the shift key should help with. When the Wyse terminal finally logs off, login as your hacker user.
Voila, you’re now local admin on the box, with a full desktop and no application controls applied as your Sid is no longer the one listed as a restricted profile. Disable the FBWF, now any change you make will be permanent, install that key logger or bind shell and have fun.
Following either of the above links points to their support channels, which require a valid support agreement (which I don’t have) or require it to be one of the listed “accepted bug report” programs available through connect. Which I couldn’t find a suitable program to class this under, coming up against a brick wall and given the MSRC response suggesting that this is not a security bug I’ve decided to do a blog post disclosure. This is what follows.
This issue stems from the ability as an non-administrator user to circumvent group policy based settings that seem to imply a disablement or prevention for a feature, in particular this was first noticed when examining the proxy settings of a host, originally editable from within the Internet Explorer connections tab.
The policies in question have the following wording:
“Disable the Connections Page”
The above policy infers within its description that no other policies are required to ensure the protection of the connection settings. From experimentation, this appears to be an incorrect assumption.
“Prevent Changing Proxy Settings”
This policy appears to only “grey” the GUI, it does not prevent actual changing of the proxy settings, and fails to set ACLs or harden the settings sufficiently against attack
This policy appears to suggest that it blocks the modification of the auto configuration URL and prevents a user from modifying the “Detect Settings Automatically” checkbox. However as per the previous proxy settings policy, it merely affects the appearance of the GUI and does not protect the settings from modification by a non-administrative user.
Create a local user on your machine, don’t add him to any special groups. In fact you just want a non-administrator, someone you’d not expect to be able to bypass a group policy.
Using ‘gpedit.msc’ as an administrator, navigate to the following root and enable “Disable Changing Automatic Configuration Settings”.
Root: User Configuration/Administrative Templates/Windows Components/Internet Settings/
With that setting enabled and a user created. Log out of your administrator account, log back in as the user under test.
Open Internet Explorer and view internet settings, navigate to the connections tab and view the Lan Settings. It should appear as per the screenshot below.
You will be unable to change the “Automatically Detect Settings” Tick box.
Now fire up regedit (this can also be done via VBA, VBS, BAT, Powershell, WMI, whatever you need to access registry keys).
Edit it so that the 09 becomes 01, or rather subtract 8h from the 9th byte of this value.
Now reload up Internet Explorer and view the Lan Settings once again.
Voila, Policy is still applied but settings have just been edited by yourself.
Okay so the issue in the above example is not a huge one, unless there is a second route out of the network (or one you manufacture one as an authenticated attacker) its of limited use.
However it highlights what could be a possible security issue with other Group Policy Objects. A GPO in my opinion that states it prevents modification or changing of an item should do exactly that, however these policies only appear to disable the GUI interface, the actual sensitive data that should be protected is freely accessible and worse still, editable by a normal non-administrator user.
Granted, a sysadmin is going to apply more than just GPO to his machine and registry keys and registry editing facilities should indeed be acl’d away so only administrative accounts may alter the settings but the documentation on MSDN and within the GPEDIT tool itself suggests that these policies should be sufficient to prevent user modification of the named settings which clearly is not the case.
I intend having a poke about myself to see where else Microsoft deem it sufficient to disable the GUI but still allow write access to the registry keys that actually hold the sensitive data, if any of you (1?) readers of the blog find any, be sure to post it in the comments below.
Quick two second google turned up this beauty: http://msdn.microsoft.com/en-us/library/ms815238.aspx which lists all the GP objects and the registry keys they affect, looks like I have an exciting time reading through accessenum output ahead of me. HKCU stuff is usually a safe bet (aside from some keys contained in “policies”) for being editable.
So after a conversation with a colleague of mine I’ve realised that perhaps the severity of this issue may be lost in the abstraction of the above from a client system where I initially encountered it. The above issue will allow you to take over the control of the computers proxy settings at will, what follows is a “what if” scenario explaining the issue in detail.
Bob is in his local museum. They provide a kiosk based system there for viewing a few museum webpages that describe various exhibits, it also allows users to access facebook to “like” and “share” and a few email services for free.
Bob is a clever chap however and despite having no address bar and no normal route out of the Kiosk jail, he sees a “terms and conditions” link which appears to link to c:\kioskfiles\terms.docx
docx?!? So word viewer must be installed? no way would the museum have built the kiosk based upon a corporate build and then locked it down?
Bob clicks the link, Word 2010 fires up and displays the terms and conditions for using the kiosk. Oh, now life gets interesting, Bob is a follower of @scriptmonkey, and remembers his post on macros and code execution so he breaks out the macro editor and runs a few commands, command prompt is no go, due to GPO but oddly regedit is accessible, granted he’s only the lowly kiosk user at the moment so what can he do?
Bob edits the AutoConfigURL to point at C:\doesntexist.txt and tries browsing to a website not explicitly allowed, one that would result in a blank white page normally. Pow! the website pops up.
It appears the kiosk is on the wider network just forced to connect via a proxy first to enforce the site rules.
Perfect, now Bob sets the DefaultConnectionSettings key such that the 05 from before is now set to 01. Meaning that no auto configuration script or automatic detection takes place. He sets the EnableProxy key to 1, to enforce a proxy setting. He then adds his own internet based proxy to the registry key ProxyServer.
Confirming he still has internet access, he closes his open windows and walks away.
Few minutes later Jane comes along. Clicks the facebook “share this exhibit” button, logs in…
What just happened? (TL:DR)
The ability to modify the proxy settings for current user and bypass group policy protections as a normal non-administrator user is a particular risk to shared user based systems, Demo machines in PC World, kiosks, “sheepdip” machines, etc…
A malicious user is able to compromise the system, redirect traffic (in the case of internet explorer its often the case that other programs follow IE’s settings) to their own proxy server, harvesting credentials, sensitive data/information, etc…
In the example above I used regedit but this is possible using VBA/VBS/Batch/WMIC as well, meaning there is more than one way to skin this particular cat.
The GPO based protections that prevent access via the GUI should also prevent modification of these settings via the registry. In addition the modification of these keys do not appear to be documented anywhere within the above linked table, in fact those listed registry keys only list “policy” based keys, which just confirm whether or not the policy is set in this case instead of providing the enforcement of the particular rule.
So, whats your opinion? Were MSRC right to classify this “not a security vulnerability”?
It appears a chap has seen this blog post and did some more work on understanding the PAC file contents (array.dll?script if you’re running a TMG) and has now developed a sweet little post exploitation metasploit module to perform DNS spoofing against a compromised host.