Latest Alerts

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

As we are running out of IPv4 address space, many networks, instead of embracing IPv6, stretch existing IPv4 space via multiple levels of NAT. NAT then uses reserved IP address space. However, there are more address ranges reserved then listed in RFC1918, and not all of them should be used in internal networks. Here is a (probably incomplete) list of address ranges that are reserved, and which once are usable inside your network behind a NAT gateway.

List of Reserved IPv4 Address ranges


Address Range
RFC
Suitable for Internal Network




0.0.0.0/8
RFC1122
no (any address)


10.0.0.0/8
RFC1918
yes


100.64.0.0/10
RFC6598
yes (with caution: If you are a carrier)


127.0.0.0/8
RFC1122
no (localhost)


169.254.0.0/16
RFC3927
yes (with caution: zero configuration)


172.16.0.0/12
RFC1918
yes


192.0.0.0/24
RFC5736
no (not used now, may be used later)


192.0.2.0/24
RFC5737
yes (with caution: for use in examples)


192.88.99.0/24
RFC3068
no (6-to-4 anycast)


192.168.0.0/16
RFC1918
yes


198.18.0.0/15
RFC2544
yes (with caution: for use in benchmark tests)


198.51.100.0/24
RFC5737
yes (with caution: test-net used in examples)


203.0.113.0/24
RFC5737
yes (with caution: test-net used in examples)


224.0.0.0/4
RFC3171
no (Multicast)


240.0.0.0/4
RFC1700
no (or unwise? reserved for future use)



Most interesting in this context is RFC6598 (100.64.0.0/10), which was recently assigned to provide ISPs with a range for NAT that is not going to conflict with their customers NAT networks. It has been a more and more common problem that NAT'ed networks once connected with each other via for example a VPN tunnel, have conflicting assignments.
Which networks did I forget? I will update the table for a couple days as comments come in.
------

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.

------

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.

------

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.

------

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.

(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.

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

We have noticed an increase in scanning activity to ports TCP/8909, TCP/6666, TCP/9415, TCP/27977 and UDP/7 and would love some packets if you have them.

TCP/8909 - No idea what it is a new one for me. A new one and starting to trend.
TCP/6666 - this is probably going to be IRC, but it would be nice to confirm and see what is being scanned for.
TCP/9415 - this used to be associated with open proxies, but again be good to get some packets to check.
TCP/27977 - My first thought was gaming port, but that is just a guess.
UDP/7 - echo, a blast from the past. maybe they are looking for misconfigured or old routers and *nix boxes.

If you have any packets to the above please submit them through the contact form or email them to handlers -at- sans.edu or directly to me markh.isc -at- gmail.com
Thanks in advance.

Mark H (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.

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

As many of the Internet Storm Center readers know, my full time job is working for Sourcefire, the makers of SNORT, ClamAV, Razorback, Daemonlogger, and all of our commercial products. Snort rules, ClamAV detection, etc. I often write about Snort related things here, since I know the SANS audience uses Snort heavily, and is even taught in the 503 course.
One of the areas that I've been looking at and following even more intently recently have been all the Exploit Kits. I refer to things like Incognito, Blackhole, Crimepack, and many more.
Let me give you a couple external references to go read in case you have no idea what I am talking about:
Brian Krebs has some blog posts here and hereabout some updates to it. But for a basic explanation of how the blackhole kit exploits you, the end user, I suggest this pdf here.
The Blackhole exploit kit in particular is very actively developed and changes rapidly to things that block its exploit methods. Trust me. As a person who follows all the particular versions of these exploit kits, they change just about weekly.
You can be exploited by various kit by simply going to a website where some injected code rests on the page (you'll never see it - this is what we call a drive by), receiving some spam (Linkedin, USPS, UPS, I've even seen fake Pizza Delivery emails delivering things like the Pheonix Exploit kit) that redirects you to a landing page, receiving spam with an html/htm email attachment.. The possibilities are essentially endless on how you can wind up on an exploit kit landing page.
Once on the landing page, there are lots of different ways that the exploit kit figures out how to take over your computer, but the basic point of the landing page is which piece of software didn't this user patch?. Vulnerabilities in browsers, java, even the delivery of a pdf to exploit a vulnerable version of Adobe Reader.
These kits are all over the place, and most likely, you are going to run into one of these (if you haven't already).
I basically have three pieces of advice for you.
1) Don't open spam, or click on links inside of spam, or generally just be careful of the sites you go to. If you are reading this webpage, you know there is a 'wild west' to the Internet. Be careful.
2) Patch. Everything. Java, browsers, OS, Adobe Reader, etc. Everything. I literally cannot stress the importance of this enough.
3) Run AV and if you are on a corporate network, run an IPS.
This is an evolving threat. Nothing is going to 100% protect you all the time, however, the more layers you have, hopefully the more insulated you are against the threat, and you can protect yourself and your users.
Good Luck!
-- Joel Esler | http://blog.joelesler.net | http://twitter.com/joelesler
(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.

Overview
The ISC Links page at https://isc.sans.edu/links.html is a categorized list of information links. You can get to the page by the top-right menu and choosing Tools-Links. The list lets you vote a link up or down and there's even a form to suggest new links! Results are not updated realtime. Voting and URL addition is subject to approval.
Features
Link List - https://isc.sans.edu/links.html#list

Links are listed down by most-to-least votes
Categories:Internet Status, Malware Information, Security Dashboards, Security Blogs, Vendor Security Advisories
Vote in favor or against a link
You may vote as many times as you wish, but only one vote per URL will count.

Add a new Site - https://isc.sans.edu/links.html#add

You must be logged in to submit links
Category: Choose an appropriate category for you link
URL:Paste in the url you wish to submit
Site Name: Enter a name for the URLyou are submitting
Click Submit to suggest the link for the page

Some hints:

Submit URLs that point to home pages / main pages, not to specific articles.
The page should be related to infosec, internet status or any of the other categories
If you submit a blog: It needs to have a few posts first.
We try to avoid linking directly to sites providing exploits.
Please let us know if we should add categories to the list.


Post suggestions or comments in the section below or send us any questions or comments in the contact form on https://isc.sans.edu/contact.html#contact-form
--

Adam Swanger, Web Developer (GWEB, GWAPT)

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

(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.

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

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

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