Information Security, Privacy and Regulatory Compliance

It seems as though we as an industry having been having this debate now over what is consider to be responsible disclosure for as long as I can remember. For whatever reason though, this topic seems to once again be picking up some focus again as I`m hearing about it in podcasts and seeing more of it on some websites. Why, I`m not entirely sure. Personally, I think this is a horse we've spent more than enough time beating on and that beast needs to just be put to sleep already.

In my own view of this, it's real simple. When we, as a community, discover a defect in a piece of code, we need to take the high road and work with the vendor to allow them a reasonable amount of time to offer a fix to the general population. As I say that though, there are some side thoughts to bear in mind with my own personally recommended process.

Once you have discovered a flaw and can both provide documented proof of the defect, you must be able to repeat the documented process for how you exploited the flaw. Exploiting a flaw, not remembering how you did it with no repeatable process, than spamming a vendor and expecting some resolution without providing any useful information deserves you nothing but a kick in the /bleep/.

Designate a timeline with the vendor. This timeline should include a reasonable amount of time for the vendor to respond to your report, develop a fix for the defect, test the fix in their own test environment, schedule a release date of the fix and finally when you as the “discoverer” of the defect can announce the discovery and resolution of the flaw.

Any deviation from the timeline must of course result in some repercussions. If the vendor deviates from the timeline without proper communication, all bets are off and I would personally release the information to the world. If you deviate from the timeline without proper communication to the vendor, the vendor should have the ability to pursue civil and/or criminal action against you.

I use the word reasonable often, and with good reason. A reasonable amount of time for a vendor to acknowledge receipt of the reported defect in their software, in my opinion is no more than two weeks. Anything outside of that I consider to be stonewalling. A reasonable amount of time for a vendor to verify the existence of the defect in their software is no more than two weeks after notification. A reasonable amount of time for a vendor to perform their development and testing of the fix for their code is no more than one month after notification.

You'll note that no where did actually state that the vendor must respond to the notification. Should the vendor choose to respond and create the timeline, wonderful. However, lack of response from the specific vendor then sets the timeline to whatever you as the discoverer of the flaw feel appropriate. Bear in mind though that the release of any exploit code against a software defect may result in some negative feedback from the community as a whole if you intentionally did not give a vendor adequate notification or time to resolve the issue.

For historical reasons, these are the two more popular generally accepted “Responsible Disclosure” practices along with a brief overview of each.

CERT Vulnerability^[?] Disclosure Policy (VDP)

The CERT VDP is of course referenced the most due to the popularity of the CERT/CC. Their stance is likely one of most aggressive of the surviving VDP's today. Within the CERT/CC VDP, once CERT receives a vulnerability^[?] notification. CERT notifies the affected software vendor immediately upon receipt of the vulnerability notice. Included within the notification to the vendor is the contact information for the individual that reported the vulnerability, unless of course the individual requested to remain anonymous. 45 days after the receipt of the notification by CERT, they will publicly announce the details of the vulnerability. During the 45 day window, CERT will maintain communication with the individual who reported the vulnerability.

Rain Forest Puppy Vulnerability Disclosure Policy

Rain Forest Puppy, oh how I miss this guy...RFP's VPD was created with a slant empowering the researcher than the vendor.

The researcher notifies the vendor of the vulnerability. If the vendor does not reply within 5 days, the researcher is free to release the vulnerability information to the public. If the vendor does reply back to the researcher within 5 days, the researcher should assist the vendor to replicate and remediate the vulnerability. During this time frame, if there is no communication from the vendor to the researcher for a 5 day period, the researcher is free to release the vulnerability information to the public. Once the vendor has developed a fix/patch for the software, the vendor should communicate as such to the researcher. The researcher and the vendor will then jointly develop the disclosure statement.

Whichever method you decide to use, bear this in mind - Each of us has a responsibility to the entire community. One person acting selfishly can easily cause a black-eye to the entire industry. Respect the rest of us and simply communicate..

Nikto is a lightweight, portable, PERL based web application scanner. The only requirements for Nikto to run are PERL and NET SSLeay, NET SSLeay is only needed if you plan on auditing SSL based applications. Nikto requires you to input the targets from the command line, because of this we’ll also be using NMAP with the http-headers NSE scripts to identify and gather basic information on HTTP based services for this overview. Nikto, as a standalone package, does not include the ability to perform port/service scanning. As such, NMAP will additionally need to be installed on the system performing the audits. NMAP is not a requirement; it just makes things easier…

Required Software/Packages:

Nikto

• http://cirt.net/nikto2

Net SSLeay

• http://search.cpan.org/CPAN/authors/id/S/SA/SAMPO/Net_SSLeay.pm-1.25.tar.gz

NMAP

• http://www.nmap.org/download

NMAP HTTP-Headers NSE

• http://nmap.org/svn/scripts/http-headers.nse

NMAP with NSE to discover potential Web Applications

This section assumes you are running at minimum nmap 5.21, nmap 5.2x is required for the application awareness checking of nmap. To begin, we will be probing the targets systems to discover all services and identify what is running on them using the service aware nmap config, but also using the http-headers nse to gather interesting information about the system(s) with potential web applications. From the nmap output, we’ll be targeting those systems running some type of web application. Side Note: for those services that show up as unknown, be sure to manually probe them later. nmap --script http-headers.nse -p 1-65535 –A

I’m targeting all ports here via nmap as some people still believe security through obscurity is a valid mechanism, don’t overlook anything. There are several other options for service level probing you may want to investigate, but for this I’m doing the quick and dirty.

Once nmap has completed its run, it will spit out everything it found to the console, from that list we will target the services to be audited with Nikto.

$ nmap --script http-headers.nse 192.168.0.1 -A

Starting Nmap 5.21 ( http://nmap.org )
NSE: Script Scanning completed.
Nmap scan report for 192.168.0.1
Host is up (0.0012s latency).
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.2.3 ((CentOS) mod_python/3.2.8 Python/2.4.3 mod_ssl/2.2.3 OpenSSL/0.9.8e-fips-rhel5 mod_perl/2.0.4 Perl/v5.8.8)
443/tcp open ssl/http Apache httpd 2.2.3 ((CentOS) mod_python/3.2.8 Python/2.4.3 mod_ssl/2.2.3 OpenSSL/0.9.8e-fips-rhel5 mod_perl/2.0.4 Perl/v5.8.8)

Installing Nikto and targeting the discovered web applications

Obtain the Nikto package and the NET SSLeay packages from the following locations:

Install NET SSLeay then untar the nikto package to your home directory, update Nikto

./nikto.pl –update

From the nessus NSE scan above, we found the following services in operation that are of interest:

• 80/tcp open http Apache httpd 2.2.3
• 5801/tcp open vnc-http RealVNC 4.0
• 3000/tcp open http WEBrick httpd 1.3.1
• 443/tcp open ssl/http Apache httpd 2.2.3

At the command line, we target these web applications specifically with Nikto by using the following type of command:

./nikto –h 'target' -p 80,443,5801,3000 –ssl –output report.html

As Nikto is performing the targeted assessment, any potential issues will be displayed to the console. As the scan is occuring, all results are output to the html file with the details of the scan along with the corresponding OSVDB^[?] identifiers broken down by service port tested.

The export format may additionally be set to either csv or XML as needed: report.csv, report.xml

Executing nmap and passing the results directly to nikto

This is useful when you want/need to check all active web servers in the target subnet(s). The following executes the nmap scan of the target subnet then pipes the discovered hosts to nikto.

nmap 192.168.0.0/24 -oG - | ./nikto.pl -output subnet.html -h -

Closing

Nikto standalone, I wasn't overly thrilled with. But again, in a pinch it is a nice tool to keep in the box. In testing nikto, some scans were needed to be run several times for nikto to actually do what it had been configured to do via the command line. The reporting isn't that clean, still leaves a lot of room for interpretation and understanding of common issues.

Whole Disk Encryption (WDE^[?]) – And Comparison of PGP vs TrueCrypt for WDE

In this day and age there is absolutely no reason for any business with laptops being used for business or personal reasons that contain sensitive information to not be encrypted.

• AT&T Laptop stolen with payroll data
• Stolen laptop exposes 207,000 Army reservists
• Laptop stolen containing Veteran Affairs patient information

Whole Disk Encryption, also known as Full Disk Encryption, is what it says; it encrypts all information contained on the specified disk or partition. WDE should not however not to be confused with file system encryption. With WDE one key is used to encrypt the entire disk. Should the key become compromised, the entire disk is thereby compromised. For those individuals needing or who are required to transmit sensitive information on their laptops, I would strongly recommend using WDE in conjunction with file system encryption.

File system encryption is often known as folder or file encryption because it was designed, from a high level, to encrypt specific targets within the system whereas WDE deals with the entire disk.

• File System encryption examples can be found in a previous blog post on TrueCrypt Containers for examples.

TrueCrypt vs PGP	TrueCrypt	PGP
Cost	Free	$149.00
Encrypt internal, external and removable media	yes	yes
Encrypt all user data, applications, boot sector and swap files	yes	yes
Shred/Wipe Function	no	yes
Encrypt Email	no	option $$
Encrypt IM	no	option $$

TrueCrypt Whole Disk Encryption on Windows - Step by Step

Select Create Volume

Encrypt the system partition or entire system drive

Type of System Encryption - Normal

Area to Encrypt – Encrypt the whole drive

Encryption of the Host Protected Area – If you know there are utilities in the Host Protected Area (HPA) you do not want encrypted, select No – Otherwise encrypted the HPA as well

Number of Operating Systems – Select the appropriate response, typically this will be 1

Encryption Options – Select the Preferred Encryption and hashing Algorithms – for NIST^[?] compliance select AES^[?]

• Notes:
• Unlike PGP below where you generate your public/private keypair that can be used for other PGP plug-in applications, the keys for TrueCrypt are generated based on the movement of your mouse and are only used for drive encrypt/decrypt functions
• If you are overly paranoid, you can select a cascading algorithm here such as AES+TwoFish to increase the strength

Password – enter the password, this will be used to access the system once the entire disk has been encrypted

Rescue Disk – The iso image created must be copied off the system and it is recommended it be burnt to a CD. This will be required if the password is forgotten or any portion of the loader becomes corrupted. Once the image has been burnt, eject and reinsert the CD and click next to allow Truecrypt to verify the image. Once it has completed, it will ask you to reboot, select yes for the encryption Pretest.

At the boot prompt, enter the password you had entered earlier.

Once Windows boots, you'll be presented with the Pretest screen and the option to begin the encryption process, select Encrypt, go for a coke...

The encryption status window will appear, once the disk encryption has completed a notification window will appear.

That’s about all that you need to do.

If for whatever reason you want to permanently decrypt the drive, open the TrueCrypt application, select System then “Permanently decrypt system partition/drive”.

PGP (Pretty Good Privacy) WDE on Windows - Quasi Step by Step

The setup is pretty straightforward and almost identical to the TrueCrypt setup; install the application from the exe. Once it finished open the PGP Desktop application from the system tray and click on PGP Disk then Encrypt Whole Disk.

• During the installation you`ll be prompted to create a key pair. These keys will be used for encrypting and decrypting the drive(s). These are also the keys you`ll use if you buy the extra PGP addons such as email. Make sure you use your legitimate email address during creation.

It is recommended you create a recovery disk, same as a above.

Select the disk to encrypt then select the keys you created during installation by selecting Add User Key.

Click Encrypt, go for a coke..

By default PGP uses AES-256 for encryption and SHA-1 for hashing. As far as I am aware there is no possible customization to either the encryption or hashing algorithms.

Soap Box

While I am a huge fan of TrueCrypt for only WDE or file system encryption, it does not scale well in large deployments like PGP offers with the Universal Server. With the PGP Universal Server, enrollments and encryption policies can be controlled and deployed from a central server. The PGP server can generate "reports" from the server on demand. I put the quotes around the word report because the export is simply a csv export of the entire database structure, which is severely lacking in the ability to perform decent reporting and database maintenance.

Seriously though, with whatever solution you choose..choose one. The 30 minutes of your time it takes to install and configure the software will pale in comparison to being immortalized on the Internet as yet another failure to protect sensitive information...