Reboot Wednesday: Yesterday's Patch Tuesday Aftermath

Published: 2013-09-11
Last Updated: 2013-09-11 21:22:02 UTC
by Johannes Ullrich (Version: 1)
8 comment(s)

We have a couple of issues people reported with yesterday's Microsoft patches. Let us know if you experienced any of these issues, and what workaround you applied to get things back to normal:

KB2868116: Takes very long to install. Just sit back and wait (30-45 Minutes). This patch improves the content of warning messages, so it is somewhat security relevant, but does not patch an actual vulnerability.

KB2817630: Causes Outlook to loose all folders. No workaround other then removing the patch. This was not a security patch.

We will add to this list as we confirm any other issues. So far, there are some reports of the system re-applying the same patch over and over, but there are just one or two users reporting this, and in some cases the patch that causes it isn't identified.



Johannes B. Ullrich, Ph.D.
SANS Technology Institute

Keywords: microsoft patches
8 comment(s)

In Defense of Biometrics

Published: 2013-09-11
Last Updated: 2013-09-11 19:44:30 UTC
by Johannes Ullrich (Version: 1)
6 comment(s)

There is a new iPhone and it comes with a finger print sensor! What better reason to talk a bit about biometric. In the good old days before Defcon and Wardriving, Biometrics had an ambiance of "high security". Remember the James Bond movie where they cut out a guy's eye to bypass a retina scanner? Those days are long gone. Now we have seen fingerprint and facial recognition systems being bypassed by simple printouts of the fingerprint or face, or rubber molds of fingerprints being used instead of the real thing.

So how meaningful is a fingerprint sensor these days? The right answer is of course: It depends. First on the quality of the sensor, secondly of the software used to analyze the acquired data, and finally the alternative authentication methods it replaces or suplements.

During enrollment, the sensor acquires a reference image of the fingerprint. This image is then analyzed, and certain parameters are extracted from the image. It is these parameters, not the original image, that will be used to compare later authentication attempts. Of course, no two images are quite alike. It may not be possible to identify all the parameters, or some additional characteristics may be discovered that were not visible in the reference scan. The result is that the software has to allow for some variability. For low quality sensors, this variability can be quite large, leaving you with only few distinct features. The result is the same as having a bad password: Many different users will end up with the same "fingerprint" as far as the sensor is concerned.

So what does this mean for the iPhone, or mobile device authentication in general? The problem with mobile device authentication has always been the fact that it is difficult for the user to enter complex passwords on a small keyboard. The result is that most users choose short numeric PINs. There have been a couple of other attempts, for example the Android "pattern" login and the use of cameras for facial recognition. The facial recognition usually suffers from bad sensor quality and from very variable lighting. The pattern login is a pretty neat idea, but I think it hasn't been tested sufficiently to figure out how much patterns users choose actually differ.

There is one thing Apple appears to have done right: The fingerprint data stays on the phone, and is not backed up to any cloud service. If this information got lost, an attacker could use it to reconstruct a duplicate of the finger, which in turn could be used for biometric identification even beyond the iPhone itself. 

As far as the quality of the image sensor and software: We will have to wait for it to be tested once the phone is released. It probably does not include more advanced feat rues like measuring the users body temperature or observing blood flow. But I hope it will be better then a 4 digit pin.

One easy improvement: Make it "real two factor" by allowing users to require a PIN/Password in addition to the fingerprint. Could they have done better then a fingerprint? There are a few different common biometric sensors: Facial recognition, Fingerprint, Weight/Height, retina scans and iris scans. Fingerprints are probably best considering the price of the sensor and the difficulty to acquire the data.

Finally: There is probably one real big vulnerability here. A stolen iPhone is likely covered in the user's fingerprints. It shouldn't be too hard for an attacker to lift a finger print off the phone itself to bypass the sensor.


Johannes B. Ullrich, Ph.D.
SANS Technology Institute

6 comment(s)

Getting Started with Rsyslog Filters

Published: 2013-09-11
Last Updated: 2013-09-11 12:07:05 UTC
by Alex Stanford (Version: 1)
2 comment(s)


This is a "guest diary" submitted by Tom Webb. We will gladly forward any responses or please use our comment/forum section to comment publically. Tom is currently enrolled in the SANS Masters Program.

Rsyslog has some very useful features when building a centralized syslog system. If you are not currently centralizing your logs or have not organized them in an efferent way for analysis, this post will get you started in the right direction.  

To understand how to create a filter, you must understand the basic breakdown of the message format. Below is a visual representation of a basic log. The rawmsg is the entire syslog line. If you use this in your filter, it will check the entire line for a match. The hostname field can match a name or an IP address. The programname field normally lists the application that created the log and the msg field is anything after the programname. 



Aug 14 02:38:01  SIFT-Workstation  rsyslogd:      rsyslogd's userid changed to 101


Client logs

To setup all logs for a Linux system to forward to your central log server simply change the /etc/rsyslog.conf file and replace the IP address of your syslog server with ( in following line:

*.* @

If you only want to forward a type of application logs to syslog, be more specific about what you want to send. If you do not need all the information in a log, filter out the noise. This will save disk space and speed up processing. In this example, we are only sending apache logs to the server. 

If $programname contains ‘apache’ then @

To send the logs via UDP use one ‘@’ sign and to send the logs via TCP use two ‘@@’ signs.

If $progrmname contains ‘apache’ then @@

Organizing Logs

Once you have several devices reporting to your syslog server, you will need to break the logs into different files to make analysis easier. Most often, you will want to group logs by application. Some of the common operators for filtering are contains, isequal, and startswith.

If you want rsyslog to stop process the line once you have a match, use & ~ on the next line. This prevents the line from being entered into multiple files (e.g. /var/log/my-log and /var/log/syslog).

To place all logs from one IP address into a single log, use the below example. It takes anything from the IP and adds it to the /var/log/mail.log. 

if $fromhost-ip == '' then /var/log/mail.log


For devices in a cluster, you will likely want both device logs in the same file. In the following example both IP and logs are placed into the /var/log/firewall.log. 

if ($fromhost-ip == '' or  $fromhost-ip == '') 

Use a partial IP match for lots of devices on a couple of subnets. In this example, anything that has a 10.20.0 address or 10.30.0 is placed into /var/log/load-balance.log. Rsyslog cannot use CIDR notation for subnets, but in most cases, this is a decent replacement.

if ($hostname contains '10.20.0' or $hostname contains '10.30.0') then/var/log/load.log

To create a log for all authentications, the rule below will take any message that contains ‘auth’ and place it into the /var/log/remote-auth.log file.

if $msg contains 'auth' then /var/log/remote-auth.log

A more complex filter to match both authentications and the word fail, use the below example.

If $msg contains ‘auth’ and $msg contains ‘fail’ then /var/log/remote-fail.log

Rsyslogs support very complex logic and syntax. For more information, visit the following links.


Tom Webb

Keywords: rsyslog syslog
2 comment(s)
ISC StormCast for Wednesday, September 11th 2013


Diary Archives