Wednesday, October 23, 2013

A Ghost In Your Network

It is common that, in a penetration testing,  the red team may also be in charge of assessing the physical security in a company. In such circumstances, many  pentesters try to drop a device on the costumer's network to gain full access.

The effectiveness may be quite high, but it depends on how skilled the defender is. For example, a diligent sysadmin may scan the network every other day, spotting the device soon or later.  What can we do to change this?  How can we hide from the defenders?

It turns out we can use an old trick available in almost all PC devices, that is barely used nowadays and it has been there for ages. All PCs have a real time clock that can be programmed to automatically wake-up/boot our computer at a given time in the future.  What if we could drop a device that could sleep for days, waiting for the right moment to wake-up and drop a remote shell? The sysadmins can scan and scan and scan... They will not find it because it only runs for a couple of hours at night!

Imagine the following scenarios:
  • A rogue Access Point appearing every night at 10pm from nowhere, that gives direct access to the internal network for 30 min (unless you prevent it from going back to sleep).
  • A remote shell to your Meterpreter instance every night to run some scheduled tasks, before disappearing again from the network.
  • A rogue device that wakes up to exfiltrate data for a short period of time and then it goes back to sleep for days.

How can we configure our system to behave this way? It turns out its is fairly easy, because we only need to change a  file in our Linux installation. Every time our PC goes to sleep or it shuts down, the system writes the current time into /dev/rtc0 to be sure we are not waking up by mistake. This is a pretty standard behaviour in all Linux distributions. In my case, the tests were done in Ubuntu.


On /etc/init/hwclock save.conf , you can find the script that resets the hardware clock. You can see in bold the lines I added to keep the time I had set previously.

# hwclock-save - save system clock to hardware clock
#
# This task saves the time from the system clock back to the hardware
# clock on shutdown.

description     "save system clock to hardware clock"

start on runlevel [06]

task

script
    . /etc/default/rcS
    [ "$UTC" = "yes" ] && tz="--utc" || tz="--localtime"
    [ "$BADYEAR" = "yes" ] && badyear="--badyear"
    ACPITIME=`cat /sys/class/rtc/rtc0/wakealarm`
    exec hwclock --rtc=/dev/rtc0 --systohc $tz --noadjfile $badyear
    echo "$ACPITIME" > /sys/class/rtc/rtc0/wakealarm
end script

How can I hook a script to be executed when my device wakes up? To do so, you have to  drop an executable script on /etc/pm/sleep.d/. This script will be executed every time the device wakes up or sleeps and it receives a single parameter to differentiate this circumstance.


#!/bin/sh

case $1 in
        suspend|suspend_hybrid|hibernate)
                #this code will be executed before we go sleep.
                /usr/local/bin/disable_evil_ap.pl
        ;;
        resume|thaw)
                #this code will be executed when we wake-up.
                /usr/local/bin/enable_evil_ap.pl &
                /usr/local/bin/set_next_wake_up.pl
        ;;
esac
return 0


At some point you have to write a UTC Unix Timestamp  into /sys/class/rtc/rtc0/wakealarm. In the example above we assume it is done by the script /usr/local/bin/set_next_wake_up.pl.

At the end, when the task is finished, we have to call the pm-suspend command, that will start the suspend to RAM process,. This process will execute again the script above but with suspend as the single parameter.

Friday, October 4, 2013

Efficiently Managing Your Linux Systems With Spacewalk And Puppet

Some months ago, I had been given the task to upgrade our home-grown linux management platform. This platform was written around Kickstart and worked pretty well for many years but it fell short and now we need something most robust and scalable.

This post describes the tools we have decided to use and why. As always, there isn't a single tool/platform that offers all we needed and we had to combine several of them to achieve the results. The text has been structured based in the needs we had.


Installation of new systems
Ideally it should be based in Kickstart to not rewrite again all the code done in the last years. This shouldn't be a problem because almost all the tools in the market are based in PXE and Kickstart. To do this, we use the Cobbler tools that come installed with Spacewalk.

All the inventory, installation, etc.. is done with  Cobbler because it is easy to script and more powerful compared with a simple web GUI.

Patch management and auditing
Spacewalk is probably the 'de facto' tool if you are running RedHat based Linux systems. This tool permits to create groups that is very handy if you want to carry a single action in many systems at one. An example would be, applying a patch in all the integration systems for testing before doing the same in the production systems.

Alternatively, you can use open-scap to verify that all your systems comply with your regulations: mainly patch level and configuration. See also the OpenSCAP page for RHEL6.

Configuration management
We decided to use Puppet instead of Spacewalk. This is the case because its configuration management tool was too simple and inefficient for our needs. In a nutshell,  you have to push all the configuration files with a web GUI and then add/edit the file permissions (too much manual work), it didn't have template engine, inheritance and other advanced features that are indispensable if you are managing a big data centre.

On the other hand, Puppet has a robust template language and inheritance, with many documentation/examples on the web. Many sysadmins are scared when they hear about this tool, because it is known to be complex and difficult to use, but it is quite the opposite unless you are trying to build something extremely big like a SaaS system.

In our setup, we moved all the complexity out off Kickstart, leaving a 50 lines kickstart file, and we decided to rewrite it with Puppet even though it required some extra time to have the new platform ready. In a few weeks of  work, we ported all the code and now we can ensure that all servers in a group are configured  the same way and no unexpected changes are made, changing/updating the configuration of all servers is a matter of a few key strokes and it is really easy to deploy/extend new systems.

Another good point is that Puppet is configured with text files and, therefore, it is really easy to use combined with any SCM like Git or Subversion to track back all the changes. In case something goes wrong, it is possible to revert the changes to the previous working version in a matter of seconds and without a big hassle.

Monitoring and alerting
For monitoring and alerting we decided to keep using our old Nagios installation, because it has proven to be reliable. Spacewalk can do some alerting and monitoring but we didn't trust it for such a critical task.



Wednesday, June 19, 2013

Trying to Tame Selinux

If you have ever had to fight with Selinux, you know how annoying it can be. In my experience, Selinux is a good layer of security if you have a good knowledge of what your applications can do. A good example would be a DNS or e-mail server, because the code and features they offer barely change.

On the other hand, trying to use Selinux with a complex system like a web application can be a drama unless it is integrated in the development cycle, that will not happen.  These kind of applications change constantly and it requires effort and time to keep the policies updated, without taking into account that the developers will press you because they just want to get things done. As a result, many sysadmins will get pissed off and will opt to simply disable Selinux to have an easy life.



The video below is a presentation that took place in the Red Hat Summit in 2012 and introduces Selinux in REHL 6.



Monday, June 10, 2013

Nothing to hide? The surveillance state

Many Europeans are familiars with laws tailored against our privacy. Here is common that any ISP or phone provider has to keep all their data three years in case the state needs it for a prosecution. Furthermore, more and more news confirm that many states are using state financed trojans to spy on their citizens.

Last week PRISM hit the news with a bit scandal . The big American service providers cooperating with the NSA to spy on their citizens!.  Of course this reminds me the Chaos Communication Congress that took place in Berlin in 2008, with the motto Nothing to Hide.


If you are a good buddy, why trying to protect your privacy? You haven't done anything wrong, do you? :)

Here is the link to the 25c3 keynote.

Monday, May 27, 2013

Bypassing the Corporate Proxy

This is a post in Spanish that explains how to bypass a corporate web proxy (and its filters) by using standard (not true 100%) Unix tools. In this scenario, the user wants to bypass a proxy (a Windows Proxy) that is using NTLM authentication in order to visit forbidden pages and/or for for privacy reasons.


The following tools are used:
  • cntlm is proxy that let our tools go through the proxy by doing the NTLM authentication bits. It will be listening in localhost and behaving like a common HTTP proxy.
  • corkscrew to tunnel SSH traffic over HTTP proxies
  • An ssh client to open a Socks proxy in localhost and an ssh server listening on 443.
  • A web browser that supports Socks proxies (e.g. Firefox)

The traffic will flow as follows:

Firefox -> ssh client -> corkscrew -> CNTLM -> Corporate Proxy -> SSH server -> Inet.

IPv6 security

This is a short video that discusses the security problems in IPv6, mainly DoS and MITM similar to the ones existing in IPv4. Unfortunately, the speaker doesn't introduce any tool for testing/pentesting our networks.

The talk discusses the problems found in the protocol and also exposes some extensions implemented in Cisco devices that may help to reduce the impact, even though they are not widely implemented in all platforms.

 The original source is SecDocs.


Tuesday, March 5, 2013

Mounting NFS shares through Meterpreter

This blog post is a quick resume on the subject and you can find all the details in the blog post written by Rob Fuller.


The idea behind this technique is that you have managed to create a Meterpreter session in a network and you have spotted (though a network scan or in configuration files) a server exporting data with NFS. Of course, you do not want to mess with the box and lose the shell so the solution is to tunnel all this NFS traffic though Meterpreter all the way to your own box.


Rob Fuller proposes the following setup:
  • Route all the connections to the target network through the active Meterpreter session.
  • Run Metasploit's Socks proxy in the background so we can run external programs against our target. In combination with the previous point, the traffic generated by our external program will be routed to the remote network through our Meterpreter session.
  • Use an NFS client to mount the remote volumes in your box. The problem here is that this client must support TCP connections because the programs used to "socksify" (like proxychains) only supports TCP packets.

The proposed NFS client is NfSpy  for a simple reason, it was written to abuse the trust relationships in NFS before version 4 (NFSv4 uses Kerberos for authentication), that is almost all the systems you may find in a pentest. Abusing these relationships you can bypass security restrictions like squash_root (a legit NFS library would treat root like the nobody user). You can find detailed information in the README file.

Monday, January 14, 2013

Changing the File Encoding in Unix

From time to time, Unix users have to deal with files sent by colleagues that are not properly encoded and this may cause a bit of a trouble.

You may find your self trying to write a shell script around a file, but a cat only spits gibberish. Or, if you try to work with something a bit more elaborated  like grep or sed, it will not find any match. Huh? Chances are that the file encoding is not ASCII and the standard Unix tools will not understand its content.


$ less myfile.txt
"myfile.txt" may be a binary file.  See it anyway?
$ file myfile.txt
myfile.txt: Little-endian UTF-16 Unicode text, with CR, LF line terminators

At this point, there are two options. You can write a small script with your favourite language or use the standard tools in your system, instead.  The final result will be the same, because all use the same set of functions for the conversions.

If you want to program a bit, the following languages use iconv for character set conversion.

C

http://www.kernel.org/doc/man-pages/online/pages/man3/iconv.3.html

PHP
http://php.net/manual/en/book.iconv.php

Perl
http://search.cpan.org/dist/Text-Iconv/Iconv.pm

Python
http://pypi.python.org/pypi/iconv/1.0

Ruby
http://ruby-doc.org/stdlib-1.9.2/libdoc/iconv/rdoc/Iconv.html


If you are writing a shell script, you can always use the iconv program.  It accepts the input/output encodings and the source file. It will send the result to the standard output.

$ iconv -f utf16 -t ascii oldfile > newfile