Minimal CentOS 6.2 Install

Similar to my past attempt to come up with a minimal CentOS 4.x install, I attempted to remove as many unnecessary RPM's from CentOS 6.2 install.  The result is a 183 package install.  You can find the list of minimal CentOS 6.2 RPM's here.

Cheers,
VVK

thc-ssl-dos on Backtrack 5

If you are trying to install the thc-ssl-dos on BackTrack 5, you might run into the issue of outdated libssl libraries (requires libssl-dev).

Host: i686-pc-linux-gnu
          Compiler: gcc
    Compiler Flags: -O2 -Wall
Preprocessor flags:  -I/usr/local/include -I/opt/openssl-1.0.0e/
      Linker flags: -L./  -L/usr/local/lib -L/opt/openssl-1.0.0e/
         Libraries: -lssl -lcrypto -lnsl
WARNING: OPENSSL LIBRARIES ARE TO OLD! UPDATE THEM!\n
WARNING: OPENSSL LIBRARIES ARE TO OLD! UPDATE THEM!\n
WARNING: OPENSSL LIBRARIES ARE TO OLD! UPDATE THEM!\n

To get around these warnings, you can simply grab the latest copy of openssl, build, and then point thc-ssl-dos configure script to use the latest libraries.

$ tar -xvzf openssl-1.0.0e.tar.gz
$ cd openssl-1.0.0e
$ make
$ sudo mv ../openssl-1.0.0e /opt/
$ cd ../thc-ssl-dos-1.4
$ ./configure --prefix=/opt/thc-ssl-dos --with-includes=/opt/openssl-1.0.0e/include/ --with-libs=/opt/openssl-1.0.0e/
$ make
$ sudo make install

THC-SSL-DOWN has been configured with the following options:

              Host: i686-pc-linux-gnu
          Compiler: gcc
    Compiler Flags: -O2 -Wall
Preprocessor flags:  -I/usr/local/include -I/opt/openssl-1.0.0e/include/
      Linker flags: -L./  -L/usr/local/lib -L/opt/openssl-1.0.0e/
         Libraries: -lssl -lcrypto -lnsl

       Debug build: No
Configuration complete. Now type: make all install

$ cd /opt/thc-ssl-dos/bin
$ ./thc-ssl-dos
     ______________ ___  _________
     \__    ___/   |   \ \_   ___ \
       |    | /    ~    \/    \  \/
       |    | \    Y    /\     \____
       |____|  \___|_  /  \______  /
                     \/          \/
            http://www.thc.org

          Twitter @hackerschoice

Greetingz: the french underground

./thc-ssl-dos [options]
  -h      help
  -l   Limit parallel connections [default: 400]

Cheers,
VVK

Minimal CentOS 4.8 Install

I am never satisfied with Red Hat's version of the "minimal" option during an install.  Their version of minimal install comes with unnecessary (IMHO) packages like bluez-*, various PPP and ISDN packages etc.

It is a pain to manually go through and "trim the fat", but I did.  Here is the list of RPM's required for a bare-bones RHEL/CentOS 4.8 install.  Note, to avoid breaking package dependences, I did not use --no-deps.  There are a few packages which could still be removed (mdadm, dmraid, logrotate etc.) but I find them useful, so I decided to keep them.

# rpm -qa | sort | uniq | wc -l
156


You can download the list of minimal RPM's from here.  If I find time, I'll also post the list of minimal RPM's for RHEL/CentOS 5.5.

HTH,
VVK

SSL/TLS Weak Cipher

While reviewing a Qualys report, I noticed the following "QID: 38140 SSL Server Supports Weak Encryption Vulnerability".  Of course one can verify Qualys findings one cipher at a time using openssl, but in order to verify all supported cipher-MAC combination, I needed to find an automated tool. Here are some of the useful ones I found:

1. Qualys SSL Labs - Good choice if you need to generate a presentable report for management.
2. CryptoNark - In addition to checking SSL Ciphers, it also does HTTP Track/Trace check and 'Unsafe' URL check.  You will need to install some custom Perl modules to get it working.
3. SSLscan - Comes bundled with BackTrack4.

It is a lot easier to quickly verify your remediation using these tools, as opposed to submitting another Qualys scan.

Update (6/21/11): Here is a new tool from Leviathan Security to help test SSL Re-negotiation vulnerability. (also see "(Really) Testing for SSL/TLS Re-negotiation")

Cheers,
VVK

Shifted Password Strategy = Simple Obfuscation

Recently Adam Pash posted an article on lifehacker titled “Shift Your Fingers One Key to the Right for Easy-to-Remember but Awesome Passwords”. The basic idea behind this trick is to generate what appear to be complex passwords by merely placing your fingers one key to the right and typing something easy to remember. For example, “Password” would become “{sddeptf”.

Due to a lack of a better term, I will call this approach “Shifted Password” in this post.

Initially I thought Shifted Password was a great idea, and I wondered if it is a better and simpler approach to the one proposed by Bruce Schneier’s in his Wired article titled “Secure Passwords Keep You Safer”. However after careful consideration, I have come to the conclusion that Shifted Password approach is neither practical nor secure.

Practicality
People are no longer accessing their password protected resources using only a laptop/desktop with a full size keyboard. The use of alternative input mechanisms and variations in keyboard layout (iPhone, Blackberry, Dvorak etc.) renders Shifted Password strategy ineffective.

Security
Although passwords generated using Shifted Password strategy might appear to be strong (more complex), the fact is Shifted Password is merely an obfuscation of a simple password (easy to remember). In other words, shifted password is not a good substitute for a complex password.

For example, if someone wants to use "myDogSpot” as the password, the Shifted Password version would look like “,uFphD[py”. Looks secure! But is it? The fact is it is still vulnerable to a dictionary brute force attack. These attacks might not be common yet, but it is a matter of time till the attackers smarten up and modify their attack strategy to include this obfuscated variation.

Over at Command Like Kung Fu blog, they already have a post titled "Shifty Passwords” which shows how easy it is to compensate for this obfuscation using unix tr command and generate a new shifted version dictionary based on an existing dictionary.

$ cat dict.txt | tr "$r1$R1$r2$R2$r3$R3$r4$R4" "$r1s$R1s$r2s$R2s$r3s$R3s$r4s$R4s" >shift-dict.txt

Conclusion
In the lifehacker article, Adam Pash concludes:

"Something longer but still really lame, like, say, "topsecretpassword", becomes "yp[drvtry[sddeptf". These may not be perfect compared to secure password generators, but they're likely orders of magnitude better than a lot of people's go-to passwords."

I would humbly disagree with Adam, because I think that the appearance of complexity could fool a user into a false sense of security. I think claiming that Shifted Password approach is "magnitude better" is a bit of a false advertisement.

If you are willing to accept the practical limitation of Shift Password strategy, it could prove to be useful, granted that you use a complex password to start with (catch 22!).

In my book, I am going to score this as Bruce Schneier 1, Adam Pash 0. :-)

Cheers,
VVK

Minimal Postfix (SMTP only)

While configuring Aide on a standalone system, I needed to configure SMTP in order to receive the cron job output. In absence of a mail gateway server willing to relay, I was left with the only option of running a local SMTP daemon. I installed Postfix and noticed that by default it runs on loopback interface and starts approximately 83 processes.

[root@localhost postfix]# netstat -ap | grep master | wc -l

83

I didn't really need all the additional Postfix features, so I set out to configure the bare minimum setup.

After spending some time going through the /etc/postfix/master.cf file, and some trial and error, I managed to narrowed the configuration down to the following:

smtp inet n - n - - smtpd

pickup fifo n - n 60 1 pickup

cleanup unix n - n - 0 cleanup

qmgr fifo n - n 300 1 qmgr

tlsmgr unix - - n 1000? 1 tlsmgr

rewrite unix - - n - - trivial-rewrite

smtp unix - - n - - smtp

Now, Postfix starts up only 20 processes.

[root@localhost postfix]# netstat -ap | grep master | wc -l

20

Note: Mail sent using such a setup is most likely to end-up in your spam folder.

Cheers,

VVK

Unintrusive RPM Distro Audit

As a consultant, I am often faced with an unfamiliar Linux system (usually RHEL). I always find it useful to understand which files that shipped with rpm packages have been modified, since it is usually a good indicator of what customizations have been performed on the system. To determine the modified files, I simply run:

% rpm -qa | xargs rpm --verify --nomtime | less

# Sample output:

missing /usr/local/src
.M...... /bin/ping6
.M...... /usr/bin/chage
.M...... /usr/bin/gpasswd
....L... c /etc/pam.d/system-auth
.M...... /usr/bin/chfn
.M...... /usr/bin/chsh
S.5..... c /etc/rc.d/rc.local
S.5..... c /etc/sysctl.conf
S.5..... c /etc/ssh/sshd_config
S.5..... c /etc/updatedb.conf

The following is taken from the rpm man pages (Verify Options section):



c %config configuration file.
d %doc documentation file.
g %ghost file (i.e. the file contents are not
included in the package payload).
l %license license file.
r %readme readme file.

S file Size differs
M Mode differs (includes permissions and file type)
5 MD5 sum differs
D Device major/minor number mismatch
L readLink(2) path mismatch
U User ownership differs
G Group ownership differs
T mTime differs

Using this trick, I can quickly determine what configuration files have been modified as well as any metadata modifications (ownership, link etc.).

Cheers,
VVK

3rd Party RPM Packages

While auditing an RPM based system, I started wondering what would be the easiest way to determine all the packages installed from 3rd party repositories, such as rpmforge.  Such knowledge is often useful, since some of these repositories contain packages which replace standard packages (example: php packages from remi repository).

I did not find any RPM query flags to query based on Vendor or Packager.  Which meant, extracting the information using queryformat and then parsing the output.

rpm --querytags provides a list of tags you can request in your queries.  For my purposes, I could use VENDOR and PACKAGER.

To find all 3rd party packages you can run:

~]# rpm -qa --queryformat '%{NAME}: %{VENDOR}\n' | grep -v ": CentOS"
gpg-pubkey: (none)
rpmforge-release: Dag Apt Repository, http://dag.wieers.com/apt/
gpg-pubkey: (none)
ncftp: Fedora Project
segatex: Dag Apt Repository, http://dag.wieers.com/apt/
python-xattr: Dag Apt Repository, http://dag.wieers.com/apt/
gpg-pubkey: (none)
gpg-pubkey: (none)
ipython: Fernando Perez


As you can see from the output above, I have ignored packages vended by CentOS.

Similarly, to select packages packaged by Dag Wieers, you can run:

~]# rpm -qa --queryformat '%{NAME}: %{PACKAGER}\n' | grep Dag
rpmforge-release: Dag Wieers
python-xattr: Dag Wieers


Cheers,
VVK

WMP & Outlook Express on Win2k3 - Why?

I recently attempted to harden a Windows 2003 standard installation. I was surprised to see Outlook Express and Windows Media Player (WMP) installed by default, specially considering the poor security track record of Outlook Express and WMP.

What was more shocking to me was the fact that Microsoft does not offer any option to easily remove these via Add/Remove program. Instead, Microsoft suggests a very convoluted method to get rid of Outlook Express and none for WMP.

I fail to understand the reasoning behind:

1. offering Outlook Express and WMP as default options.
   
2. lack of easy uninstallation.
3. increasing your threat surface by including such historically vulnerable pieces of software.
4. the purpose of a mail client and media player on a server class operating system.

I did not want to risk destabilizing the system, so I left Outlook Express and WMP alone. I also applied the three critical updates suggested by Microsoft.

• MS07-034: Cumulative security update for Outlook Express and for Windows Mail
  
• MS08-048: Security update for Outlook Express and Windows Mail
  
• MS06-078: Vulnerability in Windows Media Format could allow remote code execution

Cheers,
VVK

Daemons utilizing tcp_wrappers

While glancing over "Hardening Red Hat Enterprise Linux 5" by Steve Grubb from Red Hat, I came across a nice little tip.  I always knew the common daemons which were compiled with tcp_wrappers support, but somewhere in the back of my mind I always wondered how to get a definitive list of all daemons on my system which were compiled with tcp_wrappers. 

Following output generated on Fedora11 and only pertains to executables in /usr/bin and /usr/sbin.


$ sudo egrep libwrap /usr/bin/* /usr/sbin/* | awk -F 'bin/' '{print $2}' | awk '{print $1}' | sort
exportfs  
hoststat
mailq
mailq.sendmail
mailstats
makemap
makemap
newaliases
newaliases.sendmail
pacat
pacmd
pactl
paplay
parec
pasuspender
pax11publish
praliases
pulseaudio
purgestat
rmail
rmail.sendmail
rpcinfo
rpc.mountd
rpc.rquotad
sendmail
sendmail.sendmail
smrsh
sshd
stunnel


Cheers,
VVK