Apache patch out for "byte range" DoS vulnerability http://www.apache.org/dist/httpd/Announcement2.2.html

Cisco Security Advisory - Apache HTTPd DoS

Published: 2011-08-30
Last Updated: 2011-08-30 16:27:12 UTC
by Scott Fendley (Version: 1)
0 comment(s)

Earlier today, Cisco released a security advisory concerning the Apache HTTPd DoS vulnerability discussed last week (see here).

Cisco is continuing to evaluate the web services embedded in a number of their devices including their Wireless Control System, some of their Video Surveillance and Video Communication Services, and multiple lines of switches which may contain this vulnerability.

In most of these cases, there are workarounds or other forms of mitigation available (such as restricting the IPs or Hosts which can access the service on affected devices).  More information is available at  http://www.cisco.com/warp/public/707/cisco-sa-20110830-apache.shtml

Scott Fendley ISC Handler

0 comment(s)

DigiNotar SSL Breach

Published: 2011-08-30
Last Updated: 2011-08-30 14:56:16 UTC
by Johannes Ullrich (Version: 1)
9 comment(s)

You probably heard about the breach of the DigiNotar SSL certificate authority by now. In the process, a fraudulent certificate was issued for *.google.com and there is some evidence that the certificate was used to intercept traffic from Iran.

The reason we haven't really written about this so far is that we are somewhat struggling with the advice we should give you.

First of all: The SSL "race to the bottom" CA model is broken. Fraudulent certificates have been issues before, even without breaching a CA's systems.

But what can you do to replace or re-enforce SSL? Lots go over some of the options:

One possibility is to remove the DigiNotar CA from the list of trusted CAs. The problem with this approach is that now legitimate certificates, signed by DigiNotar, will no longer validate. The last thing you want to do IMHO is to get users accustomed to bypassing these warnings. I am not sure how popular DigiNotar is, so maybe it is an option in this case.

Certificate revocation lists are supposed to solve this problem. But they are not always reliable. However, for high profile breaches like this one, expect a browser patch that adds the certificate to a blocklist. Apply the patch as it becomes available.

Use DNSSEC. DNSSEC provides an alternative means to validate that you are connecting to the correct site. It is not perfect either, but somewhat complimentary to SSL and the two together provide some meaningful protect. Sadly, it is not up to you to enable DNSSEC on most sites you connect to.

There are a number of browser plugins that implement  reputation systems. I am not sure how well they work. They are pretty new. One that gained some traction is Convergence, which will compare the certificate you received with certificates others received from the same site. How well this works (in particular: false positives...) will yet need to be shown.

 

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

Keywords: ssl
9 comment(s)

A Packet Challenge: Help us identify this traffic

Published: 2011-08-30
Last Updated: 2011-08-30 13:32:28 UTC
by Johannes Ullrich (Version: 1)
3 comment(s)

Paul wrote in with some "stray packets" he detected on his home firewall against UDP port 10119. The packet appear to come from "all over" and don't look spoofed (various TTLs and IP IDs). All packets have "normal" source ports, and the TTLs suggest that they are all Windows hosts. He is seeing about a dozen packets / minute. So not a DoS, but annoying enough to notice.

Paul uses a dynamic IP address, so the obvious assumption is that this is some for of P2P afterglow from a prior user of this IP address. The question is: What kind of P2P? Is anybody able to identify it? Below you will see a quick excerpt of the traffic (source IP, source port, TTL, IP ID and the payload) 

tshark -r 10119.pcap -T fields -e ip.src -e ip.ttl -e ip.id -e data
70.171.209.146  3382    113     0xb692  0000000900000000000000000002f000139c19140000000000
14.198.249.36   2195    109     0x614b  0000000900000000000000000002f0000271e5db0000000000
83.20.76.167    21926   111     0x3f58  0000000900000000000000000002f0000137e7980000000000
74.136.209.108  53251   107     0x419e  0000000900000000000000000002f00001ffb15e0000000000
70.72.59.104    59754   116     0x433a  0000000900000000000000000002f000030f02ae0000000000
46.249.134.251  8741    111     0x2a03  0000000900000000000000000002f0000121f80e0000000000
72.189.39.53    60320   112     0x0ee8  0000000900000000000000000002f000356a1fa80000000000
76.23.146.138   56123   107     0x4859  0000000900000000000000000002f00006eb13260000000000
195.132.68.50   49312   108     0x050f  0000000900000000000000000002f0000109c9e80000000000
67.169.138.216  53355   111     0x6aed  0000000900000000000000000002f000034692cd0000000000
174.62.200.217  55644   109     0x35bc  0000000900000000000000000002f000099db30b0000000000
174.58.91.106   60308   110     0x729f  0000000900000000000000000002f000096ee2350000000000
188.193.225.7   51967   99      0x4d14  0000000900000000000000000002f00001163b7f0000000000





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

Keywords: p2p packets
3 comment(s)

Comments


Diary Archives