Information Security, Privacy and Regulatory Compliance - System Hardening

BART (Basic Audit and Reporting Tool) on Solaris 10/OpenSolaris

nospam@example.com (Keith Pachulski) — Fri, 30 Jul 2010 23:57:08 -0400

As a follow-up to a conversation regarding this; BART is one of those integrated features that is often overlooked in the Solaris 10/OpenSolaris distributions. BART at it's core function similar to other host file integrity check systems. While it is a nice tool for small shops, it is by no means well suited for large scale deployments. For mid to large scale system integrity verification and host level intrusion detection/prevention systems I`m of course still an advocate of OSSEC^[?]. For clarification, BART only performs file integrity checking and does not monitor log files or system processes etc...

Creating the BART Manifest

This would be an example of a simple manifest recording the attributes of all files within the /etc, /boot, /sbin and /usr directories and generate an md5 hash for each file.

bart create -R /etc /boot /sbin /usr > /bart/control

Included in the control file would contain single line entries for each file, link, etc

/X11/fontpath.d/misc:unscaled:pri=15 L 35 120777 - 4c50ebb0 0 0 ../../../usr/X11/lib/X11/fonts/misc
/X11/gdm/Init/Default F 2640 100755 owner@::deny,owner@:read_data/write_data/append_data/write_xattr/execute/write_attributes/write_
acl/write_owner:allow,group@:write_data/append_data:deny,group@:read_data/execute:allow,everyone@:write_data/append_data/write_xattr
/write_attributes/write_acl/write_owner:deny,everyone@:read_data/read_xattr/execute/read_attributes/read_acl/synchronize:allow 4a0c3
e11 0 3 bf7503995330dc79b078bdba2171d657

Each line will contain a notation defining what each entry is, these are as follows:

# Format:
#fname D size mode acl dirmtime uid gid
#fname P size mode acl mtime uid gid
#fname S size mode acl mtime uid gid
#fname F size mode acl mtime uid gid contents
#fname L size mode acl lnmtime uid gid dest
#fname B size mode acl mtime uid gid devnode
#fname C size mode acl mtime uid gid devnode

- B for a block device node
- C for a character device node
- D for a directory
- F for a file
- L for a symbolic link
- P for a pipe
- S for a socket

Further available attributes are as follows:

size - File size in bytes.
mode - Octal number that represents the permissions of the file.
acl - ACL attributes for the file. For a file with ACL attributes, this contains the output from acltotext().
uid - Numerical user ID of the owner of this entry.
gid - Numerical group ID of the owner of this entry.
dirmtime - Last modification time, in seconds, since 00:00:00 UTC, January 1, 1970, for directories.
lnmtime - Last modification time, in seconds, since 00:00:00 UTC, January 1, 1970, for links.
mtime - Last modification time, in seconds, since 00:00:00 UTC January 1, 1970, for files.
contents - Checksum value of the file. This attribute is only specified for regular files. If you turn off context checking, or if checksums cannot be computed, the value of this field is –.
dest - Destination of a symbolic link.
devnode - Value of the device node. This attribute is for character device files and block device files only.

Create the diff manifest and check for changes

To verify BART is functioning correctly, we'll create a test file in the /etc directory

keithp@opensolaris:/bart# touch /etc/thisisatest

Once the test file has been created we now need to run BART again to generate the differential manifest

keithp@opensolaris:/bart# bart create -R /etc /boot /sbin /usr > /bart/control-diff

After the diff manifest has generated, we then verify that any changes that have occurred, as well as checking for the test file being created.

keithp@opensolaris:/bart# bart compare control control-diff > bart-modifications
keithp@opensolaris:/bart# more bart-modifications
/thisisatest:
add

The test file we created was detected. No other modifications were found. The downside to BART is that if any changes were discovered that were legitimate. BART does not automatically update the control file. The control-diff would now become the primary file from which future checks are performed against. To automate the BART checks, add a cronjob to perform the creation of the new differential file as well as performing the compare jobs.

0 7,14,21 bart create -R /etc /boot /sbin /usr > /bart/control-diff
30 7,14,21 bart compare control control-diff > bart-modifications

Centralized BART Monitoring

With some creativity, through the NFS/automount, you can create a hub and spoke type design where the spoke systems individually create the control and diff files. The control files can be moved to the central server and the diff files remain on the spoke systems. Additional cronjobs would be created that would compare the manifest on the central server to the diff manifest located on the spoke systems. Bearing in mind of course that NFS is not encrypted by default but with some simple tweaks you can implement service level encryption to secure the NFS traffic between the central and spoke systems. But again, why recreate the wheel?

Again, it's nice to tinker with or act as a second line of auditing. But I would strongly urge a system like OSSEC be implemented to perform the centralized monitoring and reporting.

Nikto with NMAP for Web Server Scanning

nospam@example.com (Keith Pachulski) — Sun, 20 Jun 2010 16:15:00 -0400

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.

Vulnerability & Patch Management - My Two Cents and recommendations

nospam@example.com (Keith Pachulski) — Sat, 29 May 2010 11:00:57 -0400

I’m on a vulnerability^[?] management and patch management tangent. No real reason why other than I was listening to a podcast and a comment irked me so I decided to write this up. This is a high level overview of my recommendations on implementing a program. As always if you have any questions on this feel free to ping me.

Identification of Assets

For whatever reason, I find this to be one portion of any vulnerability management process that continues to fail whether it is private or public sector. Network and Systems people love to turn up new technology but they typically do not want to generate any documentation on what the system is, who is responsible for it, what applications are installed onto the system and if some other person is responsible for those installed applications. This is a critical step to being capable of performing any type of vulnerability management.

Vulnerability^[?] Identification & Tracking

Vulnerability identification can be discovered from many sources including risk assessments, vendor notifications, open sources of information (exploit-db, securitytracker, packetstorm, etc) or vulnerability assessments through automated tools (Nexpose) or manual assessments (Penetration Testing, Risk Assessments).

Vulnerability, in itself, is a broad term. Vulnerabilities can be initially discovered pre-production through system or application configurations such as running an outdated version of MySQL or allowing connections from public facing systems to protected internal resources. These types of pre-production vulnerabilities must be documented in the Identification of Assets phase.

Vulnerabilities discovery through commercial sources or clearing houses are typically assigned a criticality grade or score (CVE^[?], CVSS^[?], Critical, Medium, etc). Those vulnerabilities that have been discovered from open sources, to which commercial or clearing houses have not process, you must review and assign a grade to the vulnerability. Based on the grade or score, coupled with the criticality of the systems that may be affected along with the probability of exploitation, we can then properly gauge the response to remediation.

If you are unsure of how to perform the grading on your own, or just want a quick and dirty, the DHS^[?] has made available a CVSS v2 Calculator available at the following URL:

• http://nvd.nist.gov/cvss.cfm?calculator&version=2

Vulnerabilities discovered after deployment must be tracked from discovery to remediation. This is heavily reliant on some type of internal tracking system, personally I use redmine, to track the lifecycle of the vulnerability from the time it is discovered, the entire internal review and assessment, recommended corrective actions, implementation of remediation action to verification and finally the lessons learned or RCA^[?] (root cause analysis). On a side note, any remediation actions must be included in the system documentation. This will assist in not on the vulnerability/patch management process, but will also greatly improve incident response timelines when necessary.

Response Planning

When new vulnerabilities are discovered, a response planning process should be engaged. As part of the response planning, the focus should be on the specific vulnerability as well any risks identified during the internal review and assessment. Once a new vulnerability has been discovered, there is of course a greater chance of exploitation of the vulnerability. The planning process should of course involve the incident response team but must also include the system/applications owner(s) as well as the applicable operational group (i.e networking, systems administration).
Vulnerability Remediation

At this point in the lifecycle, we’ve identified the vulnerability, identified the vulnerable systems, developed a remediation plan, engaged the incident response capability and are ready to implement the chosen solution. Prior to actually correcting the vulnerability, ensure the system/application owner(s) have been properly notified. Included within the notification must be the projected time frame to begin as well as conclude the corrective actions. Make sure the notification includes all applicable individuals so no one feels left out, this has come back to bite more than one handler.

• You’ve also created your back-out plan and you’ve also run the entire corrective and back-out past the system/application owners right? =)

Keep in mind that the chosen remediation method must follow the documented process previously defined and agreed upon. This process must be adhered to by all involved parties. Any deviation from the process must be authorized, if for some reason the deviation does not allow for authorization at the time, the reasoning for the deviation must be documented and the affected parties later informed of the deviation in totality.

Remediation Methods Overview

Remediation methods are typically classified into the following three:
• Installation of a security patch
o Application of security patches may replace specific portions of the application code that have been determined to expose a vulnerability

• Modification of a system or application configuration parameter
o Modifying the configuration of how the application, or a portion of the operating system, functions that has been determined to expose a vulnerability

• Removal of the affected application or service
o If, after thorough review, it is determined the vulnerable piece of software, or portion of the underlying operating system, is not a functional necessity of the system, the software or service should be removed.

Remediation Methods

1. Installation of the Software Patch
a. All software patch testing should be performed on non-production systems.
b. Verification should be performed to ensure installation of the most recent security patch does not inadvertently remove previous security patches.
c. If multiple patches were published, verify there is not a specific installation sequence.
d. Prior to installation of the patch, ensure that any applications that may rely on the portion of the application, or operating system, have been fully tested to ensure continued operability post patching.
e. The length of time to properly verify a patch or subset of patches is variable based on the scope of the patch and whether the patch will interact with subsets of the operating system or other applications. The exact time frame of patch testing must be defined by the parties responsible to the systems/applications to be patched as well as the group performing the testing.
i. Security patch installations should additionally be implemented into baseline operating system installation procedures.
f. Manual verification of the security patch should be performed through the use of an automated vulnerability assessment tool (Nexpose) or manual verification.
g. Once testing of the security patch has been completed, the patch(es) are to be introduced into the patch distribution system (i.e. SCCM) for dissemination into the environment.

2. Modification of System or Application Configuration Parameters
a. Modification of configuration parameters has traditionally been a “from the hip” response to a vulnerability, as such they typically do not receive thorough testing as security patches.
b. Configuration modifications should first be performed on non-production systems. Configuration modifications may impact operational privileges and in some cases functional stability. As such, post implementation of configuration changes should include monitoring the system/application for proper functionality and stability.
c. Manual verification of the security patch should be performed through the use of an automated vulnerability assessment tool or manual verification.
i. Configuration modifications, when permanent, should be implemented into the baseline operating system and/or application installation procedures.

3. Removal of the Affected Application or Service
a. Removal of the vulnerable application or service effectively eliminates the vulnerability. Prior to removal of the application or service however, a thorough analysis of the system and applications in operation must be performed to ensure that removal does not impact the operational requirements of the system.
i. Just because you think java is not needed on that server running Oracle 11gr2, from your perspective; realize that in doing so you may make that Oracle Enterprise Manager or Grid Control application stop functioning completely.
b. Removal of applications or services, as with patching, should be performed on test systems. A pre-defined period of time should be stated for review of the operational integrity of the system post removal.
c. Manual verification of the security patch should be performed through the use of the Vulnerability Assessment tool.

A final option, typically utilized by Governmental agencies, would be the issuance of a RAF^[?] (Risk Acceptance Form). The RAF neither mitigates nor eliminates the vulnerability, but indicates that the system/application owner recognizes that a potential vulnerability exists, acknowledges that no changes to the system will occur and accepts the potential risk. In my personal opinion, this is an option that should rarely, if ever, be utilized.

• Something else to bear in mind, the entire remediation process should follow your organization change management process..you do have a change management process right?

Remediation Verification

Upon completion of the selected remediation effort, verification must be performed through manual review of configuration files or patch installation logs and vulnerability assessments. It is my personal recommendation that systems/applications which have had some corrective measures made against them be monitored for at minimum one week to ensure system/application integrity and availability.

Disk Encryption - The OpenSource Solution - TrueCrypt

nospam@example.com (Keith Pachulski) — Sat, 17 Apr 2010 12:22:41 -0400

My "secure" USB drive and a toilet bowel had a duel and the toilet bowl won. With that, I was torn between buying a new "secure" USB drive for $70-100 or buying a base plain USB drive and finding some disk encryption software. Of course in the back of my mind was a task of encrypting the entire disk on my laptop. With that I set out to find a free and moderately easy to use disk encryption software package. My requirements for the software package were the following:

- Must work on all the different operating systems I commonly use (Windows & Linux)
- Must be portable, if needed to be accessed on a different system it must work with at most installing the application
- Must be able to encrypt the entire file system
- Must be able to create virtual encrypted volumes (volume must not be overtly visible)
- Must be able to create an encrypted file system on removable media (SD or USB & volume must not be overtly visible)
- Must allow for auto-mounting of the encrypted file system, either virtual or removable media
- Must automatically unmount the drive when system is shut down or idle for a predefined time period
- Must lock/wipe the device on a predefined numbers of authentication failures
- Must use NIST^[?] approved encryption and hashing algorithms

After tinkering with 12-13 different software packages I decided on TrueCrypt, it met all my requirements except the lock/wipe the device on authentication failures. I could live without that one.

In creating the volumes, you are offered standard encryption algorithms or cascading algorithms. Cascading meaning you can implement multiple types of encryption algorithms built atop each other. Supported direct and cascaded algorithms include the following:

- AES^[?] in XTS Mode (NIST Approved)
- TwoFish
- Serpent

Cascading algorithms include the following:

- AES-TwoFish
- Serpent-AES
- Serpent-TwoFish-AES
- AES-TwoFish-Serpent

Speed wise, the direct algorithm is the preferred choice. AES will be the fastest of the available algorithm selections. If you are more concerned with security of the data at rest, the AES-TwoFish-Serpent cascade algorithm is recommended. bearing in mind, using the cascade algorithms will significantly slow the overall encrypt/decrypt throughput.

Hashing algorithms supported include the following:

- RIPEMD160
- SHA512 (NIST Approved)
- Whirlpool

Quick Volume Setup Guide for Removable Media for the Windows Operating System

Insert the USB or SD card into the reader or USB slot, open TrueCrypt and click on Create Volume.

- Select Encrypt a non-system partition/drive
- Volume Type - Standard TrueCrypt volume
- Select the USB drive (IMPORTANT NOTE: Make sure you select the USB drive and not your primary hard disk)
-- you'll get an error asking you to confirm that you want to encrypt the device, select yes

- Volume Creation Mode
-- Create encrypted volume and format it

- Encryption Options (select what you want here)
-- Encryption Select AES
-- Hashing Select SHA512

Volume Size - Select next as you're encrypting the entire file space

Volume Password - Enter the password you want to use to access the encrypted volume here

Volume Format - select NTFS for the filesystem type - do not select Quick Format, select Format

Once the device has been wiped and encrypted, remove the USB device and reinsert it into the system.

Quick Setup Guide for Creating Encrypted File Containers

Create a dummy file someone on your primary harddisk, for simplicity I used c:\temp\TrueCryptVolume

From the TrueCrypt application, click on Create Volume

- Select Create an encrypted file container
- Standard TrueCrypt Volume
- Click on Select file and navigate to where your container file is located - when prompted if you want to replace it select Yes
- Choose the encryption and hashing algorithm of your preference
- Designate the desired size of the encrypted volume
- Set the volume password
- Select NTFS for the filesystem and click on format - click yes to the warning to confirm creating the container
- Mount the container by clicking on Select File, navigate to the container file, select an unused drive letter, then click on mount

Enabling Automount for TrueCrypt Volumes

From the TrueCrypt application select Settings -> Prefereces - Checks the boxes next to the following options:

- TrueCrypt Background Task Enable
- Start TrueCrypt Background Task
- Mount all device-hosted TrueCrypt Volumes
- Mount Favorite Volumes

If you want the drives, after being idle for a predefined time period, to automatically dismount, select the "auto dismount volume after no data has been read/written to it for" and enter your time limit.

Click OK - Click Auto-Mount Devices, you will be prompted for the volume password.

Important Notes

Be aware that all disk encryption programs only protect the information "physically" written to the encrypted media be it virtual or physical. Any information you access is temporarily stored in system memory. If a computer system is not:

- shut down properly
- suffers from a power failure
- the removable media is removed without being unmounted
- as well as slew of other issues that may cause an unclean memory purge

May result in sensitive information being inadvertently left in temporary file space on the hardrdrive of the computer. If the entire system harddisk, as well as removable media, is encrypted, this is not an issue.

if you are encrypting the entire system harddrive, there have been some freak occurrences of on improper shutdown, the boot record becoming corrupted; Thereby turning your computer into a doorstop. However, full disk encryption is the recommended path if the information on your laptop for example is sensitive and may cause some severe impact to you if it were say stolen..not that laptop theft ever occurs right =)

Hardening the base PHP Installation to prevent common exploits

nospam@example.com (Keith Pachulski) — Wed, 31 Mar 2010 22:01:00 -0400

PHP "out-of-the-box" allows for an extremely broad set of access permissions, which of course isn't surprising. What we're going to cover here are the basic options that I would recommend be changed prior to any server entering into the production environment offering PHP based web applications to the Internet user base.

There are a handful of configuration options that should be modified, all of these are contained in the php.ini file. Before en-masse changing everything here, I strongly urge you to evaluate the needs of those who may be utilizing the server. Some of the options that are going to be noted here as "to be changed" or disabled, may impact the functionality of custom or 3rd party PHP packages. These are however graded as critical items that if not addressed may result in compromise of your system.

Default PHP Configuration

An overview of PHP Configuration change options can be found here

expose_php: By default this is enabled, this will allow an outsider the ability to determine that you are running PHP and what version of PHP is installed, it is recommended this be disabled. This will also cut down on the noise some web scanners generate that grab the banner searching for PHP installations.

expose_php = Off

Base Directory: by default this is not set and allows for a php script to potentially access any file on the server, modify this to the base web directory

open_basedir = /var/www/html

allow_url_fopen: This allows external URLs to be remotely included in php queries. This should be disabled to prevent your scripts from being forced to call external resources

allow_url_fopen = Off

file_uploads: This allows for files to be uploaded to the server via PHP. Unless this is absolutely needed for operations, it is recommended this be disabled:

file_uploads = Off

Default Insecure Functions

With the base install, the following insecure functions are enabled by default. To disable these insecure functions you would use the disable_functions option in php.ini - The disable_functions options is a comma separated in the php.ini file it would be entered as such:

disable_functions = proc_nice, proc_terminate, proc_close

apache_note - this is used to pass PHP strings between apache modules, such as passing PHP variables to Perl
apache_setenv - passes PHP variables to Apache subprocesses
dl - loads a PHP extension, this is known to cause stability issues
escapeshellcmd - escapes characters in a string to trick a shell command into executing arbitrary commands
exec - executes an external program
passthru - executes and external program and displays the raw output
popen - opens a process file pointer
proc_close - terminates a process started by proc_open
proc_open - starts a process
proc_nice - changes the priority of a running process
proc_get_status - fetches the status of a process
proc_terminate - allows the termination of system processes
putenv - sets an environmental variable for the active session, once the session is complete the variable is removed - bad idea, disable it
shell_exec - executes a command via the shell and returns the complete output as a string - bad..
system - executes an external program and displays the output - do I really need to explain this one?
virtual - performs apache subrequests, not the recommended method. Use include() or require() instead.

Default Insecure Classes

There is one class that should be disabled, which is enable upon installation. As with the previous, this is set in the php.ini file.

splFileObject allows for an object oriented interface to a given file. Unless this functionality is absolutely needed it should be disabled.

disable_class = splFileObject

Once these modifications are made, the system should be relatively safe from a large percentage of the automated attacks directed against PHP. I make no promises for sloppy PHP coding though =)

Enjoy..