/dev/random

Years after years, OpenSSH became the default SSH daemon on most of UNIX environments as well as other systems. It offers a lot of features which make it terribly customizable and powerful.

For a while, the ‘Match” keyword appeared in the list of directives. It allows conditional blocks of configuration directives. If the criteria(s) defined are matched, new directives may overwrite the default ones. This is extremely useful to build complex configurations.

Examples: Users connecting from an internal subnet can use their password but must use their RSA key to authenticate when connecting from unknown hosts. Port forwarding can be restricted to users of a specific group.

The current version of OpenSSH supports four criteria with the “Match” directive:

• User – To match one or more local users
• Group – To match one or more local groups
• Host – To match a FQDN or domain name
• Address – To match a single address or subnet.

Each condition may contain a single or comma-separated values and support patterns:

• Host *.rootshell.be
• User john, leo, !chris
• Address 192.168.1.16/28

When a condition is met, all the directives below will be applied until the next “Match” section or the end-of-file. This is why, they must be defined at the end of your sshd_config file. Let’s have a look at the following example:

   # Allow administrators to use the agent & X11 forwarding
   Match Group admin
      AllowAgentForwarding yes
      X11Forwarding yes

   # Regular users cannot forward TCP sessions and cannot use a password
   Match Group users
      AllowTcpForwarding no
      PasswordAuthentication no
      Banner banner.users

   # Users from the DMZ are chroot'd
   Match Address 192.168.0.0/24
      ChrootDirectory /var/sandbox

This is very powerful! But when you start to play with such nice features, you quickly become frustrated by the limited criteria, only four in the current version. This afternoon, I discussed with my friend Chris John Riley about the “Match” feature. He wished to be able to use different authentication types depending on the port used to connect to a host. It looks indeed a cool feature. Let’s dive into the OpenSSH source code.

First, it’s good to know that OpenSSH allow multiple instances of the directives “Port” and “ListenAddress”. In my sshd_config file, I use:

   Port 22
   Port 443

Then, I wrote a small patch which implements a new “Match” criteria called “Localport“. In the source code, a function already exists to return the local port used:

   /* Returns remote/local port number for the current connection. */
   static int
   get_port(int local)
   {
        /*
         * If the connection is not a socket, return 65535.  This is
         * intentionally chosen to be an unprivileged port number.
         */
        if (!packet_connection_is_on_socket())
                return 65535;

        /* Get socket and return the port number. */
        return get_sock_port(packet_get_connection_in(), local);
   }

It’s easy to use it and compare the returned value with the port(s) defined in the “Match” condition. Now, I can use the following conditions:

   Match LocalPort 22
      PasswordAuthentication yes
      RSAAuthentication no

   Match LocalPort 443
      PasswordAuthentication no
      KerberosAuthentication yes
      AllowTcpForwarding no

Etc… Interesting isn’t? And, by using different ports, it is possible to increase the server security. It is also possible to play with QoS. Port 22 can be assigned to regular users and port 443 (with reserved bandwidth) to administrators. This way, you will be able to reach your server even in case of heavy network load.

Remark: not all directives can be used in conditional blocks! Check out the sshd_config man page for the list of supported directives.

My OpenSSH patch is available here. It is based on the source code of OpenSSH 5.5p1. As usual, there is warranty at all. Use it at your own risks.

I’m certainly not addicted to web stats. This blog has a Google Analytics marker but I don’t follow the statistics on a regular base. After all, I’m blogging for fun and I don’t need to keep my audience at a certain amount or don’t need to attract more visitors – even if a growing audience is very rewarding. That’s a good opportunity to thank all my readers! Did you also notice that no commercial ads are displayed here? (Except for some specific security events or podcasts but they deserve!)

On the other side, I keep an eye on the server logs. I’m addicted to “logs”. They provide very useful information about your visitors and their behavior. Never forget: You need logs and you need to take care of them. Event if they contain non-critical information, the same details may get a very high value in the future when you’ll have to investigate a security incident. Think about this…

So, while reviewing the log file of the web server running this blog, I found something interesting. I published my last post yesterday at 18:40 GMT+2. Google fetched and indexed the data less than three minutes later:

   66.249.71.147 - - [29/Aug/2010:18:41:01 +0200] "GET /2010/08/29/back-online-2/ \
   HTTP/1.1" 200 15085 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; \
   +http://www.google.com/bot.html)"

Another statistic? Since the beginning of this month, the Google bot hit this blog 30056 times! Ok, honestly, blogs are not the best references. Lot of blogging platforms notify Google when new content has been published with messages such as “Hey, Google, I’ve something for you!“. But regular websites are also very often “crawled” by Google. A small forum maintained by myself (with a very low activity) has been visited by Google 3509 times this month.

What does it mean? If you publish some content on the Internet, don’t expect a chance to bring your data off-line. The time to read this post, they already have been indexed! Bots like the Google one have powerful algorithms and know where to find relevant information. “CTRL-Z does not work on the Internet”

I’m back online after a few days off in France with my wife, kids and… less Internet connectivity (but never far from a WiFi hotspot to check urgent mails). Helas, everything has an end and I’m already back in Belgium…

Step one, process the huge monstrous backlog of pending information: multiple mailboxes, Tweeter feeds, RSS feeds. And I don’t even speak about my business e-mail!

Step two,  cleanup my social digital life and process all pending requests on LinkedIn and Facebook. I’m not a Facebook addict but this is a “place to be” for security reason. It is always interesting to keep an eye on new buzzes generated by this monster.

Step three, probably the most important one. I definitively need to keep my planning up-to-date! The coming months will be really intensive but amazing! On 21st and22nd of September, I’ll move to Spain to attend SOURCE Barcelona 2010.

A two-days security conference with a good mix between technical and business approaches. Back to Belgium on Wednesday 23rd, just in time to build the network of BruCON, the 2nd edition of our Belgian Security guys’ baby.

It looks like a lot of people will move from Barcelona to Brussels at the same time to attend both events. Lot of fun coming! This BruCON edition will also be an opportunity for a live podcasters meetup with big-names like:

• Pauldotcom (United States)
• Exotic Liability (United States)
• Disaster Protocol (Europe)
• aluc.tv (Europe)
• Eurotrash (Europe)
• DiscussIT Pubcast (Africa)

In October, go to London to cover the RSA Europe conference.

The schedule is being fulfilled with tracks and speakers. Like SOURCE, this conference proposes a good balance between techies and tie holders. Finally, end of October, this will be my 3rd participation to hack.lu in Luxembourg.

This should close up my conference roll-out for 2010. But, I’m always open to opportunities!

Last but not least, step four, the server running the free shells platform died a few weeks ago due to a SAN crash. I’m currently busy to rebuild a brand new system.

This is a long story… but it is finally solved thanks to the developers of the BackTrack distribution! For a long time, I used a good old Orinoco PCMCIA card to play around with WiFi networks. But it died and I was looking for a brand new toy. After reviewing some discussion groups and asking for advices, I decided to buy a brand new card from Alpha Networks. They produce good devices and not very expansive. There was two cards in competition: The AWUS036N and AWUS036NH. The second one is the new model. It offers more signal and is 802.11n compatible. Unfortunately, like a lot of new devices, the card was not supported by the “old” release of BackTrack. More precisely, it was available as a standard card to connect to a wireless network but injection of packets was not possible.

During BlackHat 2010, a new version (R1) was released with the following changes:

• Kernel 2.6.34 – With fragmentation patches, etc.
• Updated tools, such as Maltego and SET.
• Improved driver support, broader range of wireless cards supported.
• Faster desktop experience due to kernel.
• Fluxbox environment added.

Yes! A new kernel and support for a broaden set of wireless cards! A few days after the conference, it was released to the public. Unfortunately, still no out-of-the-box support for the AWUS036NH card! I re-installed my BackTrack persistent USB-key using the wonderful tutorial provided by Kevin Riggins on infosecramblings.com. After more investigations and compilations, I’m finally able to use my card for monitoring and injection! Here are the steps I followed.

First, keep your BackTrack environment up to date:

  # apt-get update && apt-get upgrade && apt-get install firmware-ralink

Mine was already ok. Then, compile and install the Linux wireless compatibility package. This one is provided on the BackTrack media but not installed (no idea why?). There is already a new version available on wireless.kernel.org (2010-07-24) but I did not tested it. Install the driver using the following commands:

  # cd /usr/src/drivers/compat-wireless-2010-07-10
  # ./scripts/driver-select rt2x00
  # make
  # make install
  # make unload
  # modprobe rt2800usb

Normally, it should be fine but, in doubt, just reboot! Once done, connect your USB Wireless card and you should see something like this in /var/log/messages:

  usbcore: registered new interface driver rt2800usb
  usb 1-1: new high speed USB device using ehci_hcd and address 4
  rt2800usb 1-1: firmware: requesting rt2870.bin

Now, let’s test the interface in monitor mode:

  # airmon-ng start wlan0

  Interface  Chipset             Driver
  wlan0      RaLink RT2870/3070  rt2800usb - [phy0]
                                 (monitor mode enabled on mon0)

  # airdump-ng mon0

You will see the detected WiFi network and all the classic stuff (beacons, packets, etc). Now, let’s test the injection:

  # airdump --test mon0
  15:40:51  Trying broadcast probe requests...
  15:40:51  Injection is working!
  15:40:52  Found 1 AP

  15:40:52  Trying directed probe requests...
  15:40:52  xx:xx:xx:xx:xx:xx - channel: 11 - 'xxxxxxxxx'
  15:40:53  Ping (min/avg/max): 0.203ms/2.512ms/4.130ms Power: 3.86
  15:40:53  29/30:  96%

Looks good! But a new problem popped up:

  # aireplay-ng -1 0 -e xxxxx -a xx:xx:xx:xx:xx:xx -h xx:xx:xx:xx:xx:xx mon0
  16:26:45  Waiting for beacon frame (BSSID: xx:xx:xx:xx:xx:xx) on channel -1
  16:26:45  mon0 is on channel -1, but the AP uses channel 11

Once again, some reading of online material revealed that this is a know problem. To fix this, apply the following patch (credits go to DomInat3):

  # cd /usr/src/drivers/compat-wireless-2010-07-10/net/wireless
  # patch -p0 <chan.patch

And recompile the driver as already describe above. After reboot, try injection again:

  # aireplay-ng -1 0 -e xxxxx -a xx:xx:xx:xx:xx:xx -h xx:xx:xx:xx:xx:xx mon0
  19:17:57  Waiting for beacon frame (BSSID: xx:xx:xx:xx:xx:xx) on channel 11
  19:17:57  Sending Authentication Request (Open System) [ACK]
  19:17:57  Authentication successful
  19:17:57  Sending Association Request [ACK]
  19:17:57  Association successful :-) (AID: 1)
  #

Case closed! The installed driver worked for me. My WiFi adapter is a AWUS036NH (802.11b/g/n Long-Range Wireless USB Adapter) but the procedure should stay the same for others.

Happy wireless hacking…

The job of security professional is definitively not an easy one! You have to be dedicated to your job and, once your business hours completed, there are all the remaining tasks which help us to keep your expertise level at the highest level. Hopefully, we do this with passion (otherwise, I pity you!)

Attending security conferences is a must for everybody who wants to learn how new threats may hit users and systems. If you live in Europe, I recommend you the following ones in September: SOURCE Barcelona and BruCON. You can also follow webcasts, listen to podcasts. There are lot of places to learn! Once you grabbed interesting information, you come back to work fully motivated and try to implement the right counter-measures to protect your users from these new threats. After all, it is your job no?

Then, problems arise! As a good security professional, you will try to have the highest level of security in your infrastructure (ideal situation). Unfortunately,  too much security controls may have a bad impact on your users, preventing them to perform they work in good conditions.

Keep in mind the security triangle (below). This triangle helps you to find the right balance between:

• Security
• Functionalities
• Ease of use

In an ideal situation, the black point must stay at the center of the triangle, this is the best balance. If you increase one of the components, the two others will be affected. If you increase the security (move the point nearby the top corner), you will increase the distance with functionalities and ease of use. Same for the ease of use. By adding nice features to your environment, you fill decrease the security.

Examples are multiple: You have mobile users requesting access to customers data. Good security practice is to authenticate users via strong authentication (the black point moves in direction of the security-corner) but you have to deploy a procedure to manage token-related issues (lost, broken, loss of sync) to not block the mobile users to access their data (ease of use). If you allow your users to update the data while on the move (a new functionality), you decrease the security and the ease of use. There are plenty of examples like this one.

That’s why your security policy can be compared to a recipe! You have to find the best balance between all the ingredients. Like cooking, there are basic rules that must be respected but then it is up to you to spice it as you like. As for the “compliance”, see this as “Controlled Designation of Origin” (or AOC in French). Compliance is performed via a consistent and traditional manner. Try to keep the security triangle in mind!

I was looking for a Nagios application to install on my iPhone for tests purpose and I was surprised to find more hits than expected. It’s true that Nagios is one of the best (if not THE best) open-source monitoring solutions. There is a huge community of developers and contributors busy to add extra features or tools around the core application.

It sounds logical that a lot of projects started to expand Nagios monitoring capabilities to mobile devices. This post focuses on iPhone devices but the same logic applies to all mobile platforms.

Before deploying an application on my mobile, I had a look at the security aspects! Basically, Nagios is a web-based applications and could be accessed directly from any mobile browser (no web 2.0 technology is used). The best way to access it is to access it through a  (SSL)VPN. But the standard web interface is not designed for small screens. Using a wrapper is much more convenient and use perfectly the mobile native interface but introduce some risks…

First,some applications are available for free and only provide a “read-only” access to the Nagios data. On the other side, paying applications offer more features and allow the user to interact with the Nagios servers via a “read-write” access. Possible actions are the Nagios classics: enable/disable checks, add comments, schedule downtime, acknowledge problems etc.

Second, I reviewed some available applications on the AppStore. They use different methods to access the Nagios data:

• Some access  a MySQL database. In this case, Nagios must be configured to use NDOutils, an add-on which uses a MySQL backend to store the monitoring data.
  Example:  The old versions of N-Mobility.
• Some access directly the Nagios standard interface (based on CGI scripts) and “simulate” a browser.
  Example: TouchMon.
• Some uses a specific wrapper coded in PHP which grabs the Nagios data using the standard CGI scripts
  Example: New version of N-Mobility or iNag.

Of course, you can restrict access to Nagios via the organization WiFi network but today, users need mobility! The main consequence is: data could be accessed via wild WiFi, Edge or 3G networks. If you plan to deploy Nagios application on mobile devices, there are several security issues that you have to keep in mind:

• Nagios servers contains critical data and must not be directly reachable from the Internet. The data contained in the configuration files and check results has even more value than a port scan from a pen-tester point of view. It’s just like a gold mine!
• Data sent between the Nagios server and the iPhone will pass via untrusted networks. They must be encrypted using SSL.
• How to authenticate the mobile devices? Only authorized devices can retrieve Nagios information.
• What about the data stored locally in the mobile device memory? How does the application handle the data?

Here is an example of architecture to deploy a Nagios mobile application “in the wild”:

Click to enlarge

The traffic coming from the Internet must of course be filtered by a firewall. The mobile devices will use a server in a DMZ where will be installed the “wrapper”. Connections from this wrapper to the Nagios server will be restricted and inspected by a second firewall. The traffic between the mobile devices and the proxy (at least) will be encrypted and authentication is mandatory.

A good recommendation is to allow only a “read access” to the Nagios data. This will allow the mobile user to have a clear view of what happens on the monitoring infrastructure. If he needs to perform an intervention, he will use the regular remote access solutions (corporate laptop, SSL VPN, token, etc).

To conclude, the remaining question is: do you really need to access Nagios when you are not at the office? Just from my own point of view…

When you are connected to a network (Internet or private), your TCP/IP stack must know which DNS server(s) use to resolve host names into IP addresses.

For a while, publicly alternative DNS servers – like OpenDNS or Google DNS – implemented a blacklist protection mechanism. If a domain is suspected of delivering malicious content such as malwares, those services redirect you to special warning pages or alternative sites. This action is performed at DNS level. Basically, it’s a good initiative but some problems may arise.

First, DNS is a critical service on your network. Can you really trust an external server? By using an external DNS server, you allow 3rd parties to redirect your traffic to unwanted servers. Second, in a corporate environment, it is normally not permitted to use external DNS servers. Finally, you maybe don’t need a full bullet-proof blacklist but you just need a quick way to block malicious or unwanted sites.

Why not implement a home-made solution? If you operate your own DNS servers, ISC announced a solution for you: DNS RPZ or “Response Policy Zone“. How does it work? If you maintain a Bind server  to perform recursive queries, it may be configured with a rule to forbid specific domain name (it won’t resolve them). The goal is to link your DNS with a good reputation provider which will provide the rules. The support of RPZ is provided for Bind 9 via a patch. Once patched, your Bind will recognize the new option called “response-policy”:

    options {
        // Enable RPZ
        response-policy { zone "rpz.provider.com"; };
    };

Honestly, if you get Response Policy Zones from an external partner, you don’t solve the trust issue explained above, you just moved it! But those zones are transferred like any zone using standard protocols (AXFR). It could be possible to review them.

RPZ is not a brand new blacklist technology. To prevent users to visit some sites for multiple reasons (corporate policy, malware protection, children protection, …), two methods are used: at application level (via a proxy + content filtering) or at DNS level. RPZ can be an interesting in this case with a reduced time to implement a new blacklist entries. It will also consume less resources.

Finally, don’t forget that RPZ could be used at the 8st layer of the ISO model: the “political layer“. Censorship could easily occur with RPZ implemented in ISP’s or Government name servers!

URL shortener on-line services are very helpful. You probably already use them every day. With mobile Internet and micro-blogging services like Twitter , it’s much more convenient to use short URLs.

But the downside is, once again, the bad guys who quickly understood the opportunity of new type of attacks. It’s so easy to hide a suspicious URL behind a shortened one. Who can tell the difference between “bit.ly/abcdef” and “bit.ly/uvwxyz” ? People suffering from “clickmania” are the first victims!

That’s why it is recommended to adopt a safe behavior and to not open a shortened URL if you’re not 100% sure that the hidden address is safe. And who can claim to be sure? Some applications propose a quite good support of those services. They automatically decode and show you the original site. A good example is the Twitter client, Tweetdeck:

Click to enlarge

There are also plug-ins for different browser which decode shortened URLs on the fly:

• Long URL Please for Firefox
• View Thru for Chrome

But, some services offer a very nice feature which does not require any extra piece of code. Examples? If you would like to visit a short URL coming from bit.ly, add a “+” sign at the end of the URL and you will be redirected to the corresponding statistic page showing you the real URL and the number of hits. Same feature for is.gd but this time, add a “-” sign. I suppose that other shortener services support the same feature.

Finally, some sites are fully dedicated to URL decoding, like prevurl.com. It decodes URL and displays a thumbnail of the original website. Use it by adding your URL as argument: http://prevurl.com/?url=http://is.gd/w or by filling the form.

Don’t forget, “+” is your best friend on bit.ly!

SCADA systems are in front of the security scene for a few days since the disclosure of the Siemens default password story. SCADA stands for “Supervisory Control And Data Acquisition“. It’s a set of tools and protocols used in industrial environments. I wrote an article about security & SCADA a few months ago. Was it a premonition?

But there is another domain where computers are more and more used: the processing of medical information. Not the beloved social security numbers (and other nice stuffs) in the United States, but technical data like medical imaging or the control of medical devices (scanners). Still a few years ago, the IT infrastructure in most hospitals was used to perform administrative tasks. Today, computers are everywhere and infrastructure needs exploded in terms of requirements (storage, bandwidth, etc). Even, banned technologies like Wi-Fi are now widely deployed.

From a personal experience: I had an opportunity to work in a medical environment on a firewall issue. After the upgrade, while browsing the logs, I detected suspicious activities from an IP address: connection probes on port 445 to random IP addresses. Do I need to give more details?

After some investigations, the IP address was assigned to a PC connected to a scanner. Case closed? Certainly not!

• Impossible to shut down the PC (the scanner must be available 24×7)
• No administrative rights on the PC
• Warranty broken if the PC configuration was changed
• The scanner manufacturer had to come on site to “fix the bug”

But the most scaring fact is: how was this PC infected? It had no Internet access, restricted applications. I suppose the insertion of a rogue USB key was the source of the problems. Consequences of such infection can be dramatic: network congestion, slow response times (which is critical when information must be processed in real-time), etc.

With this example, I would like to draw attention to the problematic security of such equipments. Dear SCADA & Medical devices manufacturers, your solutions must be bullet proof (They control devices which can have a major impact on people if not working properly). Don’t forget that, in most cases, you rely on widely deployed solutions like Microsoft Windows or Linux. Don’t rely only on your customers to ensure proper security. It’s a  job to be performed jointly by multiple parties. If one fails, the whole security will be affected, just like the weakest link of a chain. If your organization uses SCADA or medical devices and the manufacturers recommend unsecure behavior (like using default passwords), this must be a “no-go”! Using in SCADA or medical environment, security must be taken into account like on a regular network.

For a long time ago, I did not write about OpenBSD which remains one of my favorite operating system. The last version (4.7) was released in May and introduced, as usual, a lot of interesting changes.

OpenBSD comes of course with it’s own firewall called pf (“packet filter“). Plenty of features are available but pf gained even more power since the last OpenBSD release with the introduction of the divert sockets support (for both IPv4 & IPv6). What’s this?

First, divert sockets are not new. They are available for a while on FreeBSD (also supporting the pf firewall) or Linux since kernel version 2.2). When you need to intercept packets passing through your UNIX server, you use the library libpcap (and the associated tools like tcpdump) or raw sockets. But this operation remains “read only” – I mean – you just grab a copy of the packets for further analyze. Did you ever dream about a cool way to process packets outside the core firewall process and, even better, re-injecting them in the traffic flow? That’s the purpose of the divert sockets.

First of all, some important remarks:

• Packets sent to a divert socket will be processed in user space! This could have huge security impacts.
• Processing packets and re-injecting them use lot of time (compared to the time required by the firewall to process them), this could lead to huge performance impacts.
• Altering the payload of some TCP packets can be dangerous. No big issue if the payload size remains the same but if it changes, the TCP session between the hosts will be desynchronized! (issue related to the sequence number).

If you always keep in mind those remarks, let’s see how divert sockets work. Let’s imagine a firewall between a private network and the Internet (see figure below). We can instruct the firewall to divert all outgoing packets on port TCP/80 to a process running on user space.

How to achieve this? At pf level, we configure the divers socket (via your pf.conf):

    pass out on $int from any to any port 80 divert $divert_port keep state

The process running in user space utilizes a special type of RAW socket called divert (IPPROTO_DIVERT) that allows you to receive and send like a regular socket. But here, the divert socket is bound to a port which is used by the firewall ($divert_port in the example above) to send packets. A basic example in C:

    printf("Creating a divert socket\n");
    fd=socket(AF_INET, SOCK_RAW, IPPROTO_DIVERT);
    if (fd==-1) {
       printf("Could not open a divert socket\n");
       exit(1);
    }
    bindPort.sin_family=AF_INET;
    bindPort.sin_port=8000;
    bindPort.sin_addr.s_addr=0;
    printf("Binding a socket\n");
    s=bind(fd, &bindPort, sizeof(struct sockaddr_in));

Once done, wait for incoming packets, process them and re-inject them (optional):

    sinlen=sizeof(struct sockaddr_in);
    printf("Waiting for some packets...\n");
    while(1) {
       n=recvfrom(fd, packet, BUFSIZE, 0, &sin, &sinlen);
       hdr=(struct iphdr*)packet;

       processPacket(packet);

       printf("Reinjecting packet\n");
       n=sendto(fd, packet, n ,0, &sin, sinlen);
    }

If you prefer to develop in Perl, there is a Net::Divert module available on the CPAN repository. Here is a little example:

    use Net::Divert;
    my $divsocket = Net::Divert->new('127.0.0.1',9999);
    $divsocket->getPackets(\&processPacket);

    sub processPacket {
       my ($packet,$tag) = @_;

       # ... Perform further processing ...

       # Re-inject the packet
       $divsocket->putPacket($packet,$tag);
    }

Those are simple example, I’m not a developer . What can you do with divert sockets? There are plenty of implementations:

• Data Leakage Prevention (DLP): Generate alerts when patterns are detected in the payload of inspected packets. In case of re-injection, hide sensitive date (SSN, CC, …) with “XXXXXX”.
• Quality of Service
• Statistics
• IDS
• URL filtering
• DNS answer rewriting
• …

Use your imagination! But, once again, take care of the security! Diverted packets will travel across different rings during the inspection!

Related information:

• Net::Divert Perl module
• Divert Socket Mini-HOWTO