Archive for the ‘methods’ Category

Pivot Mercilessly!

Wednesday, March 17th, 2010

I just returned from a great trip to SANS 2010, in Orlando, where I was taking SEC 560 – Penetration Testing.  Our instructor, Ed Skoudis (an amazing guy, by the way), repeatedly hammered into our brains the mantra “Pivot Mercilessly!”

This concept is something that a penetration tester or vulnerability assessor needs to always keep in mind – look for the easy toehold into a system, and then see where you can go from there.  “Pivot” throughout the environment using the weak link as a starting point.

I was performing an assessment recently on a Solaris system that demonstrated this concept very effectively.  One of the boxes was vulnerable to a relatively old telnet vulnerability , which we exploited with pleasure – granting us root access to the machine.  From there, we examined the trust relationships inside the network and noticed that this box had “r service” trust relationships set up with many other machines in the network.  So, we used rsh to connect to numerous other boxes, all with root level access, and from those boxes to others… quickly we had the entire system PWNED.

All of this was made possible by a single box with one weak spot.  This is likely the case with most systems out there – maybe you’ll have one or two boxes vulnerable to exploits, especially in a well-managed corporate network.  From there, it’s up to you to pivot your way through the rest of the system!

Tags: , ,
Posted in Attacks, methods | No Comments »

Summarizing PKI Certificate Validation

Monday, January 19th, 2009

Security certificates and the methods used by websites to show that they are secure enough for users to trust are notoriously complex. To shed a little light on this, I’m going to explain how PKI certificate validation works.

PKI (Public Key Infrastructure) describes a method of asserting the identity and validity of a person (or entity) that you have not previously met or interacted with through the use of certificates containing identifying information and public keys (these certificates are more properly called X.509 certificates). PKI accomplishes this by defining a central authority who is mutually trusted by all users of the system. The following logical diagram shows how this works for a scheme where I am presenting my credentials to a user to setup a trusted communication path between us.

Simple PKI Diagram

Simple PKI Exchange

As shown in the diagram above, the burden of figuring out whether or not a certificate can be trusted ultimately falls on the end user. The user is responsible for going through the step of verifying a certificate with a Certificate Authority to figure out if the certificate presented to him is valid. Ultimately, it is the software used by the user (mostly web browsers) that perform this validation.

Before describing the certificate validation process, let’s spend a few moments first describing what a X.509 certificate contains. In short, a certificate contains information identifying the owner of the certificate, an identifier of the central authority that issued the certificate, a unique serial number, a validity date range, and other optional fields that indicate how the certificate can be used. In addition to this information, a X.509 certificate contains information needed to verify the integrity of the certificate such as a public key that is owned by the certificate owner and a field describing the hash and encryption functions used to create the digital signature of the certificate. The digital signature is an encrypted one way hash of the certificate contents. This signature is created using the private key of either the certificate owner or, for certificates issued by a Certificate Authority, the private key of the Certificate Authority.

Certificate validation, described in RFC 5280, is notoriously complex due to issues of backwards compatibility with older X.509 standards, overloading the meaning of fields contained in certificates, and other technical issues. That being said, it is still easy to describe the overall process used by end user software to perform certificate validation.

The first step of validating a certificate is to first verify the certificate’s integrity. This is done by first creating a one way hash of the certificate contents (using the hash algorithm indicated in the certificate). This hash is stored temporarily in memory. Next, the digital signature embedded in the certificate is decrypted using the public key included in the certificate (or, for CA issued certificates using the public key from the CA root certificate). The decrypted digital signature (which is again a hash of the certificate contents) is then compared to the hash that was computed locally. If the hashes match, then the user knows that the certificate has not been altered since it was created.

Next, the certificate is checked to ensure that it has not expired. This is done by verifying that the current time falls within the validity dates included in the certificate. Next, the certificate usage fields are checked to ensure that the certificate is being used for the purpose it was intended (via the keyUsage field). For example, if the keyUsage field of a certificate is set to cRLSign but the certificate is presented by a bank website, the certificate is not being used as intended and will be rejected. Finally (and probably most importantly), the certificate is checked to see that it has been issued by a trusted certificate authority.

This last step bears more discussion as it is the validation step that is most important in trusting a certificate. An important field embedded in a X.509 certificate is the issuer field. The issuer field lists the name of a certificate authority which has vouched for the validity of the certificate. Recall the step where the integrity checks are performed. The user must decrypt the digital signature using a public key. Instead of using the public key embedded in the certificate, the user looks at the issuer field to identify a Certificate Authority certificate (called a root certificate) that contains the public key that should be used to verify the certificate. The root certificates are stored locally on the user’s computer, so the software searches through this list to fetch the correct root certificate. Once the root certificate has been found, the public key from the root certificate is used to decrypt the digital signature in the certificate being validated. If the signature is validated, the user knows that the owner of the root certificate (the Certificate Authority), has signed the certificate being presented and therefore vouches for the contents of the certificate.

At this point, the only remaining step is to see if the certificate has been revoked by the Certificate Authority (due to a possible compromise of the certificate or of the Certificate Authority itself). Since the list of root certificates that are stored on user’s computers are not frequently updated (the list is usually selected by the OS or browser vendor), there must be a way for the software to dynamically query the Certificate Authority to check if there is a problem with the certificate. This is accomplished using 2 different techniques: certificate revocation lists (CRLs) and an online check called Online Certificate Status Protocol (OCSP).

CRLs are lists that are periodically issued by a CA that contains a list of certificate serial numbers that have been deemed to be invalid by the CA. The CRL also contains a date range indicating when the CRL should be considered expired and a new list should be obtained. Browser software is expected to regularly download the CRLs for all root certificates that it has knowledge of. When using CRLs, the final check for a certificate’s validity is to verify that the certificate’s serial number does not appear in the latest CRL for the CA.

OCSP is a protocol that is used by browser software to query a CA dynamically for the revocation status of a certificate. The query request contains the serial number of the certificate being checked as well hashes of the issuer name and public key. The request is sent to a OCSP server operated by the CA. The response will either indicate that the certificate is valid, revoked, or is unknown. When using OCSP, the final check for a certificate’s validity is to verify that the CA’s OCSCP server reports back that the certificate is ‘good’.

In summary, the certificate validation process is complex and resource intensive. The PKIX community has recognized this as becoming more of a problem with the prevelance of mobile devices that have limited processing resources. A solution that is being proposed is a mechanism to offload the responsibility of performing all of the certificate validation steps to a centralized server that is trusted by users. This mechanism is called Server-Based Certificate Validation Protocol defined in RFC 5055. In a future post, I’ll examine more about SCVP and discuss different use cases for how it can be deployed to provide security in mobile wireless networks.

Tags: , , ,
Posted in methods | 1 Comment »

Recovering a PGP Whole-Disk-Encrypted Drive

Friday, January 9th, 2009

This week I had a frustrating incident occur that I’d never wish upon anyone again – my PGP-encrypted laptop hard drive was corrupted!  Luckily, I was able to recover the data after hours of research and labor.  The whole experience was a painful one and it’s really turned me off from whole-disk encryption as a whole.

The initial problem was caused by one of my least-favorite pieces of software in the world – the Ubuntu graphical installer.  I was installing Ubuntu onto an external hard disk while using a Ubuntu LiveCD, and in the process of installing the OS, it overwrote the MBR on my laptop’s hard disk.  This seems to be a common pitfall affecting Ubuntu users.  Installing GRUB to the first hard disk is apparently the default behavior, according to several posts on the Ubuntu forums.  I must have missed the “Advanced” menu option to specify the bootloader location.

Installing GRUB to the MBR wouldn’t be terrible, if not for the fact that PGP Whole Disk Encryption (WDE) also uses a non-standard Windows bootloader – a piece of software called BootGuard that prompts the user for the decryption key to the drive.  Because GRUB took over the MBR on my hard drive, BootGuard would no longer execute – and thus the contents of my two partitions were stuck as encrypted with no decryption mechanism on the disk.

Adding further frustration to this issue was the fact that Ubuntu (loaded onto the external HD) wouldn’t even boot up without the laptop’s HD – because the GRUB boot loader was on the internal, encrypted HD, rather than the external HD that held the rest of the operating system.

So, I was stuck with an encrypted Windows installation and a halfway-usable fresh Ubuntu install.  What’s a guy to do?

Fortunately, if there’s one thing that our office has, it’s a lot of computers.  I was able to use a backup laptop to begin doing some research into recovery options.

PGP has recovery boot disks that can be used to decrypt a drive, so this was the first thing I tried.  With my encrypted (and inaccessible) disk in the bay of my laptop, I booted with the PGP recovery CD.  Unfortunately, this returned an error – “Internal error accessing disk, 0×80″.  A common error, if you do a little googling.  Something was wrong in the disk’s partition table or boot record – I would need to try another method.

The first method I found in the PGP Knowledge Base was in Tech Note 807 , which suggests creating a Windows PE recovery disk that supports PGP disk recovery.  I followed this path for a while, but had some issues slipstreaming the PGP software into the disk.  I gave up eventually after seeing a few other simpler methods suggested.

The simpler recovery method recommended by the members of the PGP forum and the PGP Knowledge Base was to install PGP Desktop on another PC, slave the encrypted drive to that machine, and decrypt the drive using the second PC.  I was able to get the PGP Desktop software from our administrator and install it temporarily on a new computer, then cable in my encrypted drive with a IDE to USB adapter.  This looked promising at first, with the machine able to recognize the drive and see its (unreadable due to encryption) partitions, but PGP wasn’t able to identify the drive as holding encrypted data on it.  After a few tries (and a few hours), I decided to move 0n and try a different vector.

I had seen a post on the support forum suggesting using a Windows disk to rebuild the MBR to a normal Windows state.  After doing this, the PGP recovery disc may work, since PGP is prepared to deal with a situation like this (somehow!).  By doing this, I realized I would lose the GRUB bootloader info for my Ubuntu installation, so I first pulled that off the drive from within Ubuntu (cat /boot/grub/menu.lst > /home/menu.lst).  This would give the UUID of the Linux installation if I ever want to try and get it working and bootable.

After doing that, I decided to just go for it.  After installing the encrypted drive into a spare laptop chassis, I put the Windows disc into the CD drive, booted to the recovery console (type R when prompted), and then ran the fixmbr command for the drive.  Rebooted, and…. unable to find operating system.  This was progress!  No more GRUB bootloader!

Finally, I put in the PGP recovery disk again, booted off it, and instead of the error I saw before, it continued on to the recovery console – and it recognized my PGP-encrypted disk!.  I typed in my passphrase, and then, very cautiously, chose “D” to decrypt the drive.  It very slowly started to decrypt.

The entire decryption process when running from the recovery disk takes quite a long time – on this disk (60GB), it was only about 15% along after 90 minutes.  I left the computer plugged in overnight and let it run.  When returning to the office this morning – it was done!  I put it back into my original laptop chassis (I was using a temporary one while I rebuilt a new installation of Windows on a spare HD in the main chassis), and it booted up as if nothing had ever happened.  The whole thing was pretty funny, actually – to see the little guy churning along as if it hadn’t been on the brink of death just 24 hours before.

This entire experience has left a bad taste in my mouth regarding whole disk encryption.  It’s very secure, and my experience with PGP prior to this incident had been pretty drama-free, but when it fails, it fails very dramatically.  PGP has very sparse documentation about the recovery process, and seems to take the opinion that their software is so reliable that they don’t need to spend much time making recovery a little bit easier.  For a user who’s done nothing wrong, they make the barriers to recovery too high – I had the decryption passphrase, and a simple mistake was enough to ruin all my data.  I was on the verge of scrapping the drive, suffering an unexpected data loss (which even regular backups can’t protect against perfectly).

I’ll probably avoid PGP WDE in the future, but whole disk encryption as a concept isn’t going away anytime soon.  It would be good for developers to keep disaster recovery methods in mind when creating their software!

Tags: , ,
Posted in Securism, methods | 18 Comments »

An Introduction to Protocol Fuzzing

Tuesday, December 30th, 2008

I have been considering running a basic level of protocol fuzzing on some known/unknown services for some recent projects. These are mostly penetration tests, but with particularly locked down or limited points of entry. I look at fuzzing as a way to both demonstrate more value in the penetration test and to potentially find new holes in an environment where known vulnerabilities don’t work or don’t exist.

“Fuzz testing” or “Fuzzing” is the process of taking an expected input or output and mux’ing it up with unexpected data. It began as a software testing method, but is now commonly used to detect potential security problems. It’s easiest to understand protocol fuzzing when testing Web applications:

In a typical web application login process you submit a username and password over the network. Fuzzing this communication would likely involve replacing a normal username/password pair with random data of random (and often long) lengths, but might also involve changing other HTTP response data.

The goal is to discover checks in the services programming which don’t parse the data they receive correctly. Under typical expected conditions they work fine, but in the process of fuzzing you try and discover conditions under which they do not work fine. These can lead to the discovery of new buffer overflows, cross site scripting, and other vulnerabilities.

There are a lot of fuzzing tools and frameworks out there, most of them targeting the web application space (I’ll be dedicating a later post to these). Here are a few which can be used in arbitrary protocol fuzzing:

  • ProxyFuzz – A python based proxy which will will randomly change the contents of either side of a communication stream.
  • Taof – A python based GUI proxy with a somewhat easy to use interface to select which parts of a communication are fuzzed. It can also bind itself to a locally running process to better determine when a process is having issues with fuzzed data.

There are many advantages to fuzzing:

  • You can discover interesting vulnerabilities without having a clear understanding of a protocol
  • Fuzzing can operate at all levels of the OSI model. Most fuzzers are built at the application, network, and transport levels, but fuzzing principles can work on any level.
  • Applicable to both the server and client ends of a protocol.
  • Many of the vulnerabilities discovered through fuzzing are buffer overflows and can lead to the execution of arbitrary machine code.

And several disadvantages:

  • If you don’t have much knowledge of the protocol structure, it becomes a more or less a brute-force approach.
  • Encrypted protocols are difficult to fuzz. Most fuzzer’s operate as intermediary or proxy applications and would need to either decrypt communications on the fly or have the client program’s cooperation in mux’ing the traffic.
  • As an automated method of attack, there is often a lot of work involved in finding out what exactly went wrong when an anomaly is detected and how to exploit it in a controlled manner.

Fuzzing is a big topic and an area I’ll be exploring more later.

Tags: ,
Posted in methods | No Comments »