Vulnerability Pipes

------

Johannes B. Ullrich, Ph.D.

SANS Technology Institute

Twitter (c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This is a clarification to Dan's diary from yesterday. We are interested to hear, if anybody else is seeing DNS replies from RFC1918 non-routable IP addresses, in particular from 10.0.0.0/8. So far, we only have one report, and we are trying to figure out if this is something wide spread, or something unique to this user.
This reader first noticed the problem when the firewall reported more dropped packets from 10.x addresses. Two example queries that caused the problem are A queries for 25280.ftp.download.akadns.net and adfarm.mplx.akadns.net. The reader receives two responses: One normal response from the IP address the query was sent to, and a second response from the 10.x address. As a result, the problem would go unnoticed even if the 10.x response is dropped. Both responses provide the same answer, so this may not be an attack, but more of a misconfiguration.
As a side note, initially the DNS protocol specifically allowed for replies to arrive from an IP address different then the one the query was sent to:
Some name servers send their responses from different addresses than the one used to receive the query. That is, a resolver cannot rely that a response will come from the same address which it sent the corresponding query to. This name server bug is typically encountered in UNIX systems. (RFC1035)
However, later in RFC2181, this requirement was removed:
Most, if not all, DNS clients, expect the address from which a replyis received to be the same address as that to which the queryeliciting the reply was sent. This is true for servers acting asclients for the purposes of recursive query resolution, as well assimple resolver clients. The address, along with the identifier (ID)in the reply is used for disambiguating replies, and filtering spurious responses. This may, or may not, have been intended whenthe DNS was designed, but is now a fact of life. (RFC2181)
But we are NOT looking for responses that are coming from the wrong source, but duplicate responses. Once from the correct and once from the incorrect address.
Here an example stray packet submitted by the reader (slightly modified for privacy reasons and to better fit the screen)


Internet Protocol Version 4, Src: 10.17.x.y, Dst: ---removed---
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00
Total Length: 84
Identification: 0x2a7e (10878)
Flags: 0x00
Fragment offset: 0
Time to live: 59
Protocol: UDP (17)
Header checksum: correct
User Datagram Protocol, Src Port: domain (53), Dst Port: antidotemgrsvr (2247)

Domain Name System (response)
Transaction ID: 0xb326
Flags: 0x8400 (Standard query response, No error)
1... .... .... .... = Response: Message is a response
.000 0... .... .... = Opcode: Standard query (0)
.... .1.. .... .... = Authoritative: Server is an authority for domain
.... ..0. .... .... = Truncated: Message is not truncated
.... ...0 .... .... = Recursion desired: Don't do query recursively
.... .... 0... .... = Recursion available: Server can't do recursive queries
.... .... .0.. .... = Z: reserved (0)
.... .... ..0. .... = Answer not authenticated
.... .... ...0 .... = Non-authenticated data: Unacceptable
.... .... .... 0000 = Reply code: No error (0)

Questions: 1
Answer RRs: 1
Authority RRs: 0
Additional RRs: 0

Queries

ads.adsonar.akadns.net: type A, class IN
Name: ads.adsonar.akadns.net
Type: A (Host address)
Class: IN (0x0001)

Answers

ads.adsonar.akadns.net: type A, class IN, addr 207.200.74.25
Name: ads.adsonar.akadns.net
Type: A (Host address)
Class: IN (0x0001)
Time to live: 5 minutes
Data length: 4
Addr: 207.200.74.25 (207.200.74.25)


http://www.faqs.org/rfcs/rfc1035.html

http://www.faqs.org/rfcs/rfc2181.html
------

Johannes B. Ullrich, Ph.D.

SANS Technology Institute

Twitter (c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reader Bob wrote in reportingseeing increasingly frequent incoming DNS replies on UDP 53, with valid DNS answers, but coming from source addresses in the 10.x.x.x/8 range. The responses appear to be from the Internet Roots to DNS servers that are querying the root.

Anyone else see this kind of behavior?




Over the past week another couple of readers have written in reporting issues accessing the ISC web page. The SANS NOC reports thatRFC-1323timestamps were getting scrubbed by our firewall to prevent information disclosure, but the checksum wasn't being updated. The packet wassubsequently dropped by the end device.

This appears to be impacting users using Bluecoat web proxies. We will have more to post on this topic throughout the day.




RFC1323 describes TCP extensions used to improve performance over high delay networks and high speed networks

These include Scaled Window Options, Round Trip Time Measurement (RTTM), and protection against Wrapped Sequence Numbers (PAWS)

Scaled window options are implemented by bit shifting the 16bit window field into a 32 bit field by adding an option indicating how many placeholders to shift (or multiply by) to get the real window size. Recall the window size is how many bytes a node can buffer before it needs the transmitter to slow down.

TCPDump displays this option as WS=6 for a factor of 6 in the TCP options

Wireshark displays this option as for example: Window Scale: 7 (Multiply by 128)

Round Trip Time Measurement (RTTM), or TCP option 8 contains a Timestamp value or TSval set by the sender with its sending time, a 32 bit value, and Timestamp Echo Reply (TSecr) which is only valid if the accompanying ACK TCP flag is set. This 32 bit value echos a time stamp value set by the other or remote host in a TCP session. These values are tracked over time to estimate and adapt to changing traffic conditions.
PAWS provide a simple mechanism to reject old duplicate segments that might corrupt an open TCP connection. It uses the same timestamps in RTTM, The basic idea is that a segment can be discarded as an old duplicate if it is received with a timestamp less than some timestamp recently received on this connection.
Here is what Bluecoat has to say on the topic:https://kb.bluecoat.com/index?page=contentid=FAQ1006

PAWS is looking for the timestamp to be advancing and is used to keep as much data in transit as possible between communicating hosts.



The risk to data transport in this case is if two hosts or their intermediaries cant negotiate a common method of communicating with or without these options. This can happen with firewalls, as in our case, or incompatible endpoints. It is interesting to note that Windows implemented these options in Windows 2000, but did not enable them by default until Windows 2008.
Dan

SANS Internet Storm Center Handler
Update:

----------------------------------------------------------

Some References I used to look into this today:

The RFC: http://www.ietf.org/rfc/rfc1323.txt

http://www.networksorcery.com/enp/protocol/tcp/option008.htm

http://packetlife.net/blog/2010/aug/4/tcp-windows-and-window-scaling/

http://www.ecr6.ohio-state.edu/window-scaling.html

technet.microsoft.com/en-us/library/bb726965.aspx

technet.microsoft.com/en-us/library/bb878127.aspx

This is by no means an exhaustive article on this topic, it is just a beginning, I will look to other handlers to fill in the gaps as well as look into it more as time goes on.

Another discussion that is pertinent is IP options versus TCP options. Staying in IPV4 land for this discussion

As the names state IP options and padding are in the Internet Protocol header of a packet, they are the last 32 bits in the Internet protocol (v4) header and TCP options are contained within the TCP header.
Using the following page as a reference:http://www.networksorcery.com/enp/protocol/ip.htm#Options.IP options deliver a handful of IP features that in general are not used. Most IPv4 headers begin with version (4 in this case) and the IHL the header length in 32 bit words or 5 as the minimum and default. If options are set then that number varies depending on the options set. For the most part these options are not used, IP options include features like source routing which could permit undesirable results. Each option is described in detail on the reference page above.
TCP options are more central to the operation of the protocol the IP options are. IP options add optional features, where as TCP options make the protocol work. A list of TCP options is available here:http://www.networksorcery.com/enp/protocol/tcp.htm#OptionsOption 8 contains the windows scaling discussed above. Other options include Selective Acknowledgement (opts 4 and 5) and Option 3 Window Scale Factor (discussed above and in RFC1323. These options extend and enhance the TCP protocol operation.
In conclusion, both TCP and IP offer different options which can enhance the protocols. Understanding them can impact operability and availability of a network.

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reader Bob wrote in reportingseeing increasingly frequent incoming DNS replies on UDP 53, with valid DNS answers, but coming from source addresses in the 10.x.x.x/8 range. The responses appear to be from the Internet Roots to DNS servers that are querying the root.

Anyone else see this kind of behavior?




Over the past week another couple of readers have written in reporting issues accessing the ISC web page. The SANS NOC reports thatRFC-1323timestamps were getting scrubbed by our firewall to prevent information disclosure, but the checksum wasn't being updated. The packet wassubsequently dropped by the end device.

This appears to be impacting users using Bluecoat web proxies. We will have more to post on this topic throughout the day.




RFC1323 describes TCP extensions used to improve performance over high delay networks and high speed networks

These include Scaled Window Options, Round Trip Time Measurement (RTTM), and protection against Wrapped Sequence Numbers (PAWS)

Scaled window options are implemented by bit shifting the 16bit window field into a 32 bit field by adding an option indicating how many placeholders to shift (or multiply by) to get the real window size. Recall the window size is how many bytes a node can buffer before it needs the transmitter to slow down.

TCPDump displays this option as WS=6 for a factor of 6 in the TCP options

Wireshark displays this option as for example: Window Scale: 7 (Multiply by 128)

Round Trip Time Measurement (RTTM), or TCP option 8 contains a Timestamp value or TSval set by the sender with its sending time, a 32 bit value, and Timestamp Echo Reply (TSecr) which is only valid if the accompanying ACK TCP flag is set. This 32 bit value echos a time stamp value set by the other or remote host in a TCP session. These values are tracked over time to estimate and adapt to changing traffic conditions.
PAWS provide a simple mechanism to reject old duplicate segments that might corrupt an open TCP connection. It uses the same timestamps in RTTM, The basic idea is that a segment can be discarded as an old duplicate if it is received with a timestamp less than some timestamp recently received on this connection.
Here is what Bluecoat has to say on the topic:https://kb.bluecoat.com/index?page=contentid=FAQ1006

PAWS is looking for the timestamp to be advancing and is used to keep as much data in transit as possible between communicating hosts.



The risk to data transport in this case is if two hosts or their intermediaries cant negotiate a common method of communicating with or without these options. This can happen with firewalls, as in our case, or incompatible endpoints. It is interesting to note that Windows implemented these options in Windows 2000, but did not enable them by default until Windows 2008.
Dan

SANS Internet Storm Center Handler
Update:

----------------------------------------------------------

Some References I used to look into this today:

The RFC: http://www.ietf.org/rfc/rfc1323.txt

http://www.networksorcery.com/enp/protocol/tcp/option008.htm

http://packetlife.net/blog/2010/aug/4/tcp-windows-and-window-scaling/

http://www.ecr6.ohio-state.edu/window-scaling.html

technet.microsoft.com/en-us/library/bb726965.aspx

technet.microsoft.com/en-us/library/bb878127.aspx

This is by no means an exhaustive article on this topic, it is just a beginning, I will look to other handlers to fill in the gaps as well as look into it more as time goes on.

Another discussion that is pertinent is IP options versus TCP options. Staying in IPV4 land for this discussion

As the names state IP options and padding are in the Internet Protocol header of a packet, they are the last 32 bits in the Internet protocol (v4) header and TCP options are contained within the TCP header.
Using the following page as a reference:http://www.networksorcery.com/enp/protocol/ip.htm#Options.IP options deliver a handful of IP features that in general are not used. Most IPv4 headers begin with version (4 in this case) and the IHL the header length in 32 bit words or 5 as the minimum and default. If options are set then that number varies depending on the options set. For the most part these options are not used, IP options include features like source routing which could permit undesirable results. Each option is described in detail on the reference page above.
TCP options are more central to the operation of the protocol the IP options are. IP options add optional features, where as TCP options make the protocol work. A list of TCP options is available here:http://www.networksorcery.com/enp/protocol/tcp.htm#OptionsOption 8 contains the windows scaling discussed above. Other options include Selective Acknowledgement (opts 4 and 5) and Option 3 Window Scale Factor (discussed above and in RFC1323. These options extend and enhance the TCP protocol operation.
In conclusion, both TCP and IP offer different options which can enhance the protocols. Understanding them can impact operability and availability of a network.

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Im often curious what other security folks do to keep their machine safe when they go to IT conferences. I often see what looks like standard office machines being used and wonder if any precautions have been taken.So heres what I do and Id love to find out what other measure you take.
Im about to spend a few days a large security conference, so Im just putting the finishing touches to laptop Im taking with me. As I dont have any real needs beyond email, typing notes and web browsing, its a simple job of installing a clean OS and a couple of must have applications*. In keeping with Joels previous Diary, it took the duration of some reality TV show to install all the various patches for these apps to be up to date.


Now this is where I then go through my normal additional hardening steps. This OS happens to be Windows 7, so I disable a bunch of services, kill IPV6 services, gleefully disable hibernation and add in a gaggle firewall rules (or should that be an annoyance of firewall rules?).


The last thing I do make a record of clean state of the computer. This is the part Im assuming most companies have if they have managed operating environments (MOE) or standard operating environments (SOE) as this is such an easy thing to do andprovides a trusted baseline for the security teams to compare against.


In Windows theres a bunch of ways to ask the computer whats running, what services and software is installed, but I like PowerShell so heres a quick and dirty way to get the info and save it to a file.


From a PowerShell prompt:
#Installed Software

gp HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* |Select DisplayName, DisplayVersion, Publisher, InstallDate, HelpLink, UninstallString | out-file c:build\base.txt

#Running processes

Get-Process | sort company | format-Table ProcessName -groupby company | out-file append c:build\base.txt

#Services installed

Get-service * | out-file append c:build\base.txt


This gives me three pieces providing a baseline** of the system.


Im now ready to skip from vendor booth to vendor booth, keen to look at their product case studies conveniently on handy novelty USB devices, while surfing the web on freely provided Wifi doing on-line banking, checking todays nuclear launch codes and wondering why I keep seeing Loading Please Wait when clicking on links in emails from people Ive never heard of. - Although this is an attempt at humour (note attempt) having a baseline of the clean machine allows me to identify the more obvious signs of something bad happening to my system.
If I do feel a disturbance in the force or the laptop does something odd, I can re-run my simple PowerShell commands (with a different output name) and look for changes.


#Comparing in PowerShell

Compare-Object -referenceobject $(Get-Content c:build\ base.txt) -differenceobject $(Get-Content c:build\new.txt)
That gives me a quick indication if some has changed on my systems (barring root kits) and if I need to worry about.
Let me know what you do or don't do when taking your system to a conference.

* I cant say Im a big fan of live CD/DVD/USB, I see their uses, but they get out of date, especially the browsers, far too quickly.


**If you want to get more fancy with the base snapshot, its pretty easy to script that out to include registry keys, firewall rules and even files in directories with cryptographic hash.

Chris Mohan--- Internet Storm Center Handler on Duty

Im mentoring SANS Hacker Guard 464 class in Sydney on the 7th of August - SysAdmins, this is for you! https://www.sans.org/mentor/class/sec464-sydney-aug-2012-mohan

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Adobe released updates to three security vulnerabilities yesterday, where they address critical vulnerabilities that exists in older versions of the Adobe CS suite products. As Adobe states We are in the process of resolving the vulnerabilities addressed in these Security Bulletins in Adobe Illustrator CS5.x, Adobe Photoshop CS5.x (12.x) and Adobe Flash Professional CS5.x, and will update the respective Security Bulletins once the patches are available.



The update released by Adobe can be found here, and the individual vulnerabilities are listed below



Adobe Illustrator CS5.5

Adobe Photoshop CS5

Adobe Flash Professional CS5.5.1



These vulnerabilities are all of the critical nature, which if exploited could lead to a compromise of the system, without user interaction. This vulnerability exists for both the Mac and Windows versions of the software. So be on the lookout for more updates for older version of the Adobe CS suite.

tony d0t carothers -gmail (c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

I am a Mac user. Which means my daily browser is Safari. This has been the case for a number of years, until version 5.1.4 was released in mid March. Since that time I have experienced excessive memory consumption upwards of 1GB as cost of using Safari. Prior to that release, no noticeable hit to my resources was observed.



I updated my Mac book yesterday and noticed an improvement today. We'll have to see how long that lasts. It's been less than 24 hours, so it really is too early to tell.
After all that blather is stated, an interesting feature can be noted on this most recent release of Safari. Out of date Adobe Flash Players will be auto-disabled. [1] Use the link below to get a little more info on it. There is not much more, but it explains how to re-enable an out of date Flash player.



If you are unsure what plugin versions you have in your browser, then you can mosey over to google and look for a popular browsercheck website. I would try out the link provided by a vendor that begins with a Q. It is a slick tool that I've used to check on my browser plugin versions.



Feel free to leave us a comment or remark about your Safari travels and experience with this new feature.


-Kevin

--

ISC Handler on Duty


[1]http://support.apple.com/kb/HT5271?viewlocale=en_USlocale=en_US (c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

[security bulletin] HPSBMU02775 SSRT100853 rev.1 - HP Performance Insight for Networks Running on HP-UX, Linux, Solaris, and Windows, Remote SQL Injection, Cross Site Scripting (XSS), Privilege Elevation