Alerts

Microsoft October 2014 Patch Tuesday, (Tue, Oct 14th)

Latest Alerts - Tue, 10/14/2014 - 12:08

Microsoft only published 8 instead of the promised 9 bulletins. Also, of particular interest is MS14-060 which was pre-announced by iSight Partners. iSighthas seen this vulnerability exploited in some APT style attacks against NATO/US military interests and attributes these attacks to Russia. Attacks like this have happened with many Office vulnerabilities in the past, but it is unusual for a company to announce the respective attacks and CVE numbers ahead of Microsofts bulletin release. Note that we got a total of 3 already exploited vulnerabilities in this months release. Don">MS14-059 Vulnerability in ASP.NET MVC Could Allow Security Feature Bypass Microsoft Developer Tools

CVE-2014-4075 KB 2990942

Publicly disclosed,not
exploited.">MS14-060 Vulnerability in Windows OLE Could Allow Remote Code Execution(replaces">MS14-061 Vulnerability in Microsoft Word and Office Web Apps Could Allow Remote Code Execution">MS14-063 Vulnerability in FAT32 Disk Partition Driver Could Allow Elevation of Privilege">Critical: Anything that needs little to become interesting">Less Urt practices for servers such as not using outlook, MSIE, word etc. to do traditional office or lei\ sure work.

  • The rating is not a risk analysis as such. It is a rating of importance of the vulnerability and the perceived or even predicted threatatches.
  • ---
    Johannes B. Ullrich, Ph.D.
    STI|Twitter|LinkedIn

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

    Adobe October 2014 Bulletins for Flash Player and Coldfusion, (Tue, Oct 14th)

    Latest Alerts - Tue, 10/14/2014 - 10:55

    Adobe published two security bulletins today:

    APSB-22[1] : fixes 3 vulnerabilities in Adobe Flash Player as well as in Adobe Air. The vulnerabilities are rated with a priority of 1 for Flash Playerrunning onWindows and OS X , which means they have already been exploited in targeted attacks.

    APSB-23 [2] : another 3 vulnerabilities, but this time in Cold Fusion. The priority for these updates is 2which indicates that they have not yet been exploited in the wild.

    [1]http://helpx.adobe.com/security/products/flash-player/apsb14-22.html
    [2]http://helpx.adobe.com/security/products/coldfusion/apsb14-23.html

    ---
    Johannes B. Ullrich, Ph.D.
    STI|Twitter|LinkedIn

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

    ISC StormCast for Tuesday, October 14th 2014 http://isc.sans.edu/podcastdetail.html?id=4191, (Tue, Oct 14th)

    Latest Alerts - Mon, 10/13/2014 - 16:24
    (c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
    Categories: Alerts

    CSAM: Be Wary of False Beacons, (Mon, Oct 13th)

    Latest Alerts - Mon, 10/13/2014 - 06:03

    [This is a guest diary published on behalf of Chris Sanders]

    Hunting for evil in network traffic depends on the analysts ability to locate patterns and variances in oceans of data. This can be an overwhelming tasks and relies on fundamental knowledge of what is considered normal on your network as well as your experienced-based intuition. These dark waters are navigated by finding glimmers of light">and following them where they lead you by carefully investigating all of the data sources and intelligence in your reach. While hunting the adversary in this manner can yield treasure, following some of these distant lights can also land you in the rocks.

    One scenario that often puts analysts in murky waters occurs when they chase patterns of network traffic occurring over clearly visible intervals. This periodic activity often gets associated with beaconing, where analysts perceive the timing of the communication to mean that it may be the result of malicious code installed on a friendly system.

    As an example, consider the flow records shown here:

    " />
    Figure 1 (click on image for full size)

    If you look at the timestamps for each of these records, you will see that each communication sequence occurs almost exactly one minute from the previous. Along with this, the other characteristics of the communication appear to be similar. A consistent amount of data is being transferred from an internal host 172.16.16.137 to an external host 173.194.37.48 each time.

    So, whats going on here? Less experienced analysts might jump to the conclusion that the friendly device is compromised and that it is beaconing back out to some sort of attacker controlled command and control infrastructure. In reality, it doesn" />
    Figure 2 (click on image for full size)

    As analysts, we are taught to identify patterns and hone in on those as potential signs of compromise. While this isnt an entirely faulty concept, it should also be used with discretion. With dynamic content so prevalent on the modern Internet, it is incredibly common to encounter scenarios where devices communicate in a periodic nature. This includes platforms such as web-based e-mail clients, social networking websites, chat clients, and more.

    Ultimately, all network traffic is good unless you can prove its bad. If you do need to dig in further in scenarios like this, try to make the best use of your time by looking for information you can use to immediately eliminate the potential that the traffic is malicious. This might include some basic research about the potentially hostile host like we did here, immediately pivoting to full PCAP data to view the content of the traffic when possible, or by simply examining the friendly host to determine which process is responsible for the connection(s). The ability to be selective of what you choose to investigate and to quickly eliminate likely false positives is the sign of a mature analyst. The next time you are hunting through data looking for evil, be wary when your eyes are drawn towards beaconing">Blogs:">">http://www.chrissanders.org

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

    For or Against: Port Security for Network Access Control, (Mon, Oct 13th)

    Latest Alerts - Sun, 10/12/2014 - 20:49

    I had an interesting discussion tonight with fellow handler Manuel on the pros and cons on port security as it relates to Network Access Control. I thought it would be interesting to see where others in the security field stand on the issue. Is it worth the effort or not? Is it a valuable tool in Defense in Depth? Here are some of the For and Against arguments we discussed:

    For Arguments:

    • Stops others from being able to plug into your infrastructure, they would have to search to find a port that has not been configured correctly
    • Can audit logs to determine if empty ports are turned on or off
    • Can alert you more quickly to rogue devices being plugged into your infrastructure
    • Not a perfect solution but should be part of your defense in depth solution, its not meant to be a stand alone solution

    Against Arguments:

    • If you fake the MAC address to the host, you are in
    • Insider/outsider threat is great since physical security to equipment is not well controlled in many organizations
    • Have to take into account failover scenarios or you can DoS yourself
    • Hard to manage large number of switch ports to ensure they are configured correctly at all times

    So, is port security worth the effort or do many of you find its too time consuming and the benefits are not that great? If you using it and have tips for successful implementation, please share them so others can benefit. It is Cyber Security Awareness Month and this would be a good opportunity to help educate each other on issues you have encountered with port security or how it has helped protect your organization.

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

    ISC StormCast for Monday, October 13th 2014 http://isc.sans.edu/podcastdetail.html?id=4189, (Sun, Oct 12th)

    Latest Alerts - Sun, 10/12/2014 - 15:52
    (c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
    Categories: Alerts

    CSAM: Month of False Positives - Breach Emails?, (Fri, Oct 10th)

    Latest Alerts - Sat, 10/11/2014 - 05:32

    With all the high profile breaches pretty much every one of us has received a breach notification email in the recent past. But how many of you could tell if it was legitimate?

    Take this email from Target from early in 2014.">With all the Target Phishing ">around at the time many people questioned the legitimacy of this email.At first glance it looks pretty legitimate.

    With all the garbage email we receivemost of us have been diliigent that at a minimum we check two things:

    - links in the email point to where the link says it points and that where the linkpointslooks legitimate,

    - sender address, and reply-to, addressdoes not look spoofed

    In this case there is only one link in the email and it points to creditmonitoring.target.com, which is a page in the target.com website. What made people question the legitimacy was the from email address. It was sent from TargetNews@target.bfio.com. Clearly not a Target domain.

    It turns out this email is legitimate. bfi0.com is a part of Epsilon Interactive a marketingservice that Target uses for customer marketing. ">A: To make sure you continue to receive Target emails in your personal inbox (not bulk or junk folders), please take a moment to add Target.com">">This one from Fisher Pricealso looks, and is, legitimate. ">">From: "> ">">Subject: Important Request from">">Reply-To:">To ensure you receive our">">">In order to improve your">Online Store website experience, we have transitioned to a different technology platform. As part of the transition, existing password information has been removed from your account. Before you can login to your account on the new site, you will need to reset your password using the Forgot Password?">Thank you for your immediate attention to this matter and your continued interest in">">">Please note that this does not affect your password for">.com. No changes are needed for your">Questions? Please contact Customer Service at">">">">">As far as I know this email did not have anything to do with a breach, just anupgrading of their website security, butChris, who sent this to the ISC, indicated that it stank of Phishing. I must admit that something about this emailgave me the heebee jeebees at first, but at second glance this isone of the better ways of getting users to change credentials. There are no links in the email only a recommendation to use the websites Forgot Password">">What">

    -- Rick Wanner - rwanner at isc dot sans dot edu - http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)

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

    Microsoft Security Bulletin Advance Notification for October 2014, (Fri, Oct 10th)

    Latest Alerts - Fri, 10/10/2014 - 01:18

    Microsoft have announced the heads-up for this month security patches. With nine bulletins three are rated as critical, one as moderate and five as important.

    https://technet.microsoft.com/library/security/ms14-oct

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

    ISC StormCast for Friday, October 10th 2014 http://isc.sans.edu/podcastdetail.html?id=4187, (Fri, Oct 10th)

    Latest Alerts - Thu, 10/09/2014 - 16:14
    (c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
    Categories: Alerts

    CSAM: My servers started speaking IRC, and that is when I started to listen!, (Thu, Oct 9th)

    Latest Alerts - Thu, 10/09/2014 - 09:57

    Hassan submitted this story:

    While reviewing our IDS logs, we noticed an alert for IRC botnet traffic coming from multiple servers in a specific VLAN.

    Ouch! One thing I keep saying in our IDS Class: If your servers all for sudden start joining IRC channels, then they are either very bored, or very compromised. But lets see how it went for Hassan. Hassan had what every analyst wants: pcaps! So he looked at the full packet capture of the traffic:

    The traffic wasnt 100% IRC. But it looked suspect

    Further analysis showed that the traffic originated from servers that were currently in the process of being moved between hosts via vMotion. The content of the memory / disk being transferred">Using volatility we took a vaddump of the memory dump and searched the individual process dumps for the string pattern to identify the infected process.">we found out that this part of the memory belongs to the AV process :). Apparently part of its signatures expanded in the memory during the scan.

    Great work Hassan! This one was a good one and yes, anti-virus patterns will often contain malicious strings and can trigger an IDS if it spots these strings in transfer. The signatures as downloaded from the vendor are often encrypted, compressed or otherwise obfuscated, so your IDS usually doesnt recognize these patterns. But once loaded into memory on the host, the signatures are in the clear.

    ---
    Johannes B. Ullrich, Ph.D.
    STI|Twitter|LinkedIn

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

    ISC StormCast for Thursday, October 9th 2014 http://isc.sans.edu/podcastdetail.html?id=4185, (Thu, Oct 9th)

    Latest Alerts - Wed, 10/08/2014 - 17:11
    (c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
    Categories: Alerts

    CSAM Month of False Positives - Our ISP Says We're Hosting a BotNet!, (Wed, Oct 8th)

    Latest Alerts - Wed, 10/08/2014 - 07:17

    Its a note that many of us have received. If were unlucky, its a note that your (not-a-packet-expert) boss has received and weve had to explain it.">We recently received 1 complaint(s) regarding the article below. This issue appears to have originated from your domain (IP address: x.x.x.x).

    Please take the appropriate action with your customer or the account in question, enforcing your Acceptable Use Policy.

    Regards,
    ">
    Please include your original email to SOMEISP.com in any replies.
    ">-


    A note like this takes a fair amount of explanation when discussing it with your client (or manager), who usually isnt a packet guru. Usually the narrative goes something like this:

    While (maybe) its a good thing that an ISP is looking at traffic to find malicious patterns, unfortunately, in this case the ISP just plain gets it wrong. Their entire conclusion is based on the source port. Unfortuntately, the source port in most TCP communications is what is called an ephemeral port - its either the next free port available after 1024, or a random free port above 1024.

    Add to that, in outbound communications, most TCP sessions are run through a firewall that NAT each session ( NAT = Network Address Translation), so that each of these ephemeral ports is mapped to yet a different ephemeral port.

    As you can see, from the outside networks perspective, the source port could be just about anything. So if you are looking for a suspicious port, youll find it as a source port on any corporate firewall most days.

    OK, so should the abuse@ folks look at the port at the other end? Umm- sort-of. Say someone is sending you an email or browsing to your website - in this case, the ephemeral port is at their end, and the target port is at your end.

    Really, what you want to do is look at the ports at both ends - but not to make a final determination. You might use that method to narrow down your search, before you then look at the contents of the actual packets. An even better approach is to *start* by looking at the contents of the packets - but if youre an ISP that adds up to a lot of packets which needs a corresponding amount of CPU and disk to deal with it.

    If you are an organization who needs to get a handle on outbound traffic (which is just about every organization), consider implementing an IPS on the traffic to/from the inside interface of your firewall - at that location you can see the true IP addresses and ports of all traffic, both source and destination.

    Another great thing to look at implementing is a Netflow collector (or sFlow or jFlow or IPFIX, depending on your gear) - a tool like this helps you to slice and dice your network traffic statistics to get quick answers, or in many shops netflow graphical display is the most used feature, allowing a quick, visual way to identify odd traffic or trends.

    Also an egress filter goes a long way to containing problems - if you only allow permitted traffic and have a default deny policy for all mystery traffic, youll find that your problems are more likely to stay contained within your network, and if you are looking at your logs youll be alerted much earlier in the process.

    What youll find with proper monitoring like this (IPS, Netflow, egress filtering and log monitoring) is that very likely you *do* have infected machines here and there. For instance we did the log check thing last week at a client site and found 1 station trying to infect the neighbors with shellshock. The difference between your logs and the ISPs logs though is that your logs will properly identify the problem workstation, and the alerts in your logs will be a lot less likely to be a false positive.

    The sad thing that Ive found is that once you get a false positive note like this from an ISP, youre generally in for a few weeks of them before you can escalate to a support person who understands enough to know that theyre getting it wrong, and has the clout to fix the ISPs process.

    Please, use our comment form to let us know if youve gotten a note like this, and if it was a false positive or not.

    ===============
    Rob VandenBrink
    Metafore

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

    ISC StormCast for Wednesday, October 8th 2014 http://isc.sans.edu/podcastdetail.html?id=4183, (Wed, Oct 8th)

    Latest Alerts - Tue, 10/07/2014 - 16:39
    (c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
    Categories: Alerts

    CSAM: Scary ports and firewall remote administration, (Tue, Oct 7th)

    Latest Alerts - Tue, 10/07/2014 - 13:46

    Have you ever done a quick vulnerability check only to discover that someone found that vulnerability before you did and already had the system compromised?

    During the early stages of a vulnerability scan, nmap is your friend just to quickly confirm what you got. In this case, the big surprise was that the firewall responded on port 4444. Anybody whoever dabbled with pentestingmay be familiar with this port: Metasploit uses port 4444 by default for its remote shell. Other then that, it is typically not used by any well known service.

    At this point, with a possible compromised network firewall, there isnt much point in going much further. A quick connect with netcat oddly enough let to an HTTP error. Upon further investigation, it tuns out thatSophosfirewalls use port 4444 for https remote administration. Typically, ports like 8000,8080 or 8443are used, but then again, maybe Sophos wanted to hide their port, or just be different.

    ---
    Johannes B. Ullrich, Ph.D.
    STI|Twitter|LinkedIn

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

    Belkin Router Apocalypse: heartbeat.belkin.com outage taking routers down, (Tue, Oct 7th)

    Latest Alerts - Tue, 10/07/2014 - 13:30

    According ot various reports, many users of Belkin routers are havingproblems connecting to the internet as of last night. It appears that the router will occasionally ping">heartbeat.belkin.com to detect network connectivity, but the heartbeat host is not reachable for some (all?) users. Currently, the host responds to ICMP">As a workaround, you can add an entry to the routers host file pointing heartbeat.belkin.com to 127.0.0.1. This appears to remove the block. The block only affects the DNS server on the device. It will route just fine. You can still get hosts on your network to work as long as you set a DNS server manually, for example using Googles DNS server at 8.8.8.8. .

    For a statement from Belkin, seehttps://belkininternationalinc.statuspage.io

    In a tweet, Belkin also pointed to this page on its community forum:http://community.belkin.com/t5/Wireless/Belkin-Routers-Internet-Outage/m-p/5796#M1466

    ---
    Johannes B. Ullrich, Ph.D.
    STI|Twitter|LinkedIn

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

    Confusion over SSL and 1024 bit keys, (Tue, Oct 7th)

    Latest Alerts - Tue, 10/07/2014 - 04:35

    Yesterday and today, a post on reddit.org caused quite a bit of uncertainty about the security of 1024 bit RSA keys if used with OpenSSL. The past referred to a presentation given at a cryptography conference, stating that 1024 Bit SSL keys can be factored with moderate resources (20 minutes on a Laptop). It was suggested that this is at least in part due to a bug in OpenSSL, which according to the post doesnt pick the random keys from the entire space available.

    It looks more and more like the assertions made in the presentation are not true, or at least not as wide spread as claimed.

    However, this doesnt mean you should go back to using 1024 bit keys. 1024 bit keys are considered weak, and it is estimated that 1024 keys will be broken easily in the near future due to advances in computer technology, even if no major weakness in the RSA algorithm or its implementation are found. NIST recommended phasing out 1024 bit keys at the end of last year.

    So what should you do?

    - Stop creating new 1024 bit RSA keys. Browsers will start to consider them invalid and many other software components already do so or will soon follow the browsers lead (I dont think any major CA will sign 1024 bit keys at this point)
    - Inventory existing 1024 bit keys that you have, and consider replacing them.

    There may be some holdouts. Embedded systems (again) sometimes cant create keys larger then 1024 bits. In this case, you may need to look into other controls.

    With cryptograph in general, use the largest key size you can afford, for SSL, your options for RSA keys are typically 2048 and 4096 bits. If you can, got with 4096 bits.

    [1]https://www.reddit.com/r/crypto/comments/2i9qke/openssl_bug_allows_rsa_1024_key_factorization_in/

    ---
    Johannes B. Ullrich, Ph.D.
    STI|Twitter|LinkedIn

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

    ISC StormCast for Tuesday, October 7th 2014 http://isc.sans.edu/podcastdetail.html?id=4181, (Tue, Oct 7th)

    Latest Alerts - Mon, 10/06/2014 - 17:08
    (c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
    Categories: Alerts

    CSAM: Patch and get pw0ned (not OR)., (Mon, Oct 6th)

    Latest Alerts - Mon, 10/06/2014 - 11:55

    "Patch as fast as you can" appears to be yet another common security practice leading to network doom. Bricked machines can't be hacked easily, so this may help a bit with "security". But then again, how insecure do you want your machines to be in order to support the latest and greatest patching tools.

    Nice story from Lyalc:

    "Some years ago, vulnerability scanning a production environment for the first time found about half of the critical production servers in this payment environment had the Windows File protection feature disabled via a registry key."

    Ok. This would get me a bit scarred too. Windows File Protection (WFP) is a great feature to keep those Win2k and 2k3 systems a bit more secure, and make hacking them hard enough that some script kiddies may not bother. I like it, and wouldn't want it to be disabled all for sudden.

    "Needless to say, incident response processes kicked in very quickly. ?During initial analysis, it was observed that the affected servers had ?patches applied to a critical payment component, several weeks prior to the vulnerability scanning. ?This software, from a global vendor of payment products, is used by a large portion of the payment industry, making it a natural target for malware and rootkit purveyors."

    Ok. this would get me excited too (and excitement is never good in security. I like my security operations to be boring...). Payment systems, I think I heard of a couple cases where they got attacked. Yes, they appear to be patched. But what patch? How long were they vulnerable before the patch was applied? And well, defense in depth is for people who can't do incidents response as Lyalc?coninues:

    ...the site did not have FIM installed, nor had vulnerability scanning been undertaken previously. [FIM: Forefront Identity Manager]

    So what happened? How can this possibly be a false positive?

    Following this line of investigation identified that the patch package installer was disabling WFP, but neglecting to re-enable the feature, leaving the servers vulnerable to modifications of system files.

    Ah! The patch system.?

    Just a word about patches, in a week where we just got done with a good number of highly critical emergency patches for shellshock: Stop worrying about speed alone. You will lose. Think about shellshock and heartbleed: You can't possibly patch an enterprise fast enough. What you need instead is:

    • a well thought out patching process. How are we patching, how are we avoiding down systems, how do we make sure the patch got actually applied?
    • a comprehensive inventory. You can't secure (or patch) what you don't have
    • solid controls to detect attacks and exploited systems. You need network visibility to be able to detect attacks and more importantly, exploited systems.

    ?

    ---
    Johannes B. Ullrich, Ph.D.
    STI|Twitter|LinkedIn

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

    Shellshock: More details released about CVE-2014-6277 and CVE-2014-6278. Also: Does Windows have a shellshock problem?, (Mon, Oct 6th)

    Latest Alerts - Mon, 10/06/2014 - 09:12

    Michal Zalewski did publish more details about the two vulnerability he discovered in the aftermath of Shellshock. He used a fuzzer to discover both vulnerabilities, and now published PoC exploits for both. [1]

    To check if you are vulnerable, Michal points to this test string:

    foo='() { echo not patched; }' bash -c foo

    A quick test shows up-to date OS X, CentOS and Ubuntu as not vulnerable.

    The first one, CVE-2014-6277, is a more "traditional" use of uninitialized memory. In most cases, this will just cause a crash. However, it can also be exploited to achieve arbitrary code execution. At its core, this is again due to how functions are parsed in environment variables, so this would be exploitable via HTTP requests.

    The second one, CVE-2014-6278, is closer to the original shellshock bug. The PoC exploit posted by Michal is:

    HTTP_COOKIE='() { _; } >_[$($())] {echo hi mom; id;}' bash -c :

    Just like the first bug, the parser is confused as to where the function definition ends, and it executes the code in { }.

    Late last week, a blog post about a similar flaw in Windows suggested to some that the Windows shell is vulnerable as well [2]. The vulnerability is however slightly different. It is not passed to other shells spawned from the original one. Also, in Windows, it is even less likely then in Unix to have cgi-bin scripts call a shell directly. The only realistic exploit vector in Windows remain environments like cygwin that install bash on Windows.

    [1] http://lcamtuf.blogspot.com/2014/10/bash-bug-how-we-finally-cracked.html
    [2] http://thesecurityfactory.be/command-injection-windows.html

    ---
    Johannes B. Ullrich, Ph.D.
    STI|Twitter|LinkedIn

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

    Spoofed packets with Window Size 6667: Anybody else seeing this?, (Mon, Oct 6th)

    Latest Alerts - Mon, 10/06/2014 - 07:26

    Thanks to Tim for providing some packet captures. Anybody else seeing "weird" TCP packets? In particular we are interested if you see them OUTBOUND. We are looking for the likely broken tool that may generate these packets.

    Some of the packet properties:

    • Packet size of 60 bytes (IP Headers + TCP)
    • Protocol is always TCP
    • various TOS values
    • various (random?) IP IDs. But repeating for same source IP
    • various TTLs (possible that packets from different IPs actually originate from different host)
    • DF flag is set
    • some source IPs are clearly "odd", e.g. multicast?source IPs like 255.127.0.0
    • TCP source and dest port is 0
    • Sequence numbers sometimes repeat even if source IPs change (argument for likely spoofed sources)
    • overall malformed TCP headers (e.g. header size < 20, various bad flag combinations).
    • Window size of 6667 (maybe this was supposed to be the source or dest. port?)
    • The packets arrive at relatively high rate (couple packets/sec with breaks... )

    Quick tshark?output?of a sample with obfuscated target IP:

    85.133.23.50 -> x.y.z.14 TCP 74 [TCP Retransmission] 0?0 [SYN, RST, ACK, URG, ECN, CWR, NS, Reserved] Seq=0 Ack=1 Win=6667 Urg=0 Len=0
    85.133.23.50 -> x.y.z.14 TCP 74 [TCP Retransmission] 0?0 [SYN, RST, ACK, URG, ECN, CWR, NS, Reserved] Seq=0 Ack=1 Win=6667 Urg=0 Len=0
    192.99.37.41 -> x.y.z.119 TCP 74 [TCP Retransmission] 0?0 [FIN, SYN, RST, PSH, URG, CWR, NS, Reserved] Seq=0 Win=6667 Urg=0 Len=16
    192.99.37.41 -> x.y.z.119 TCP 74 [TCP Retransmission] 0?0 [FIN, SYN, RST, PSH, URG, CWR, NS, Reserved] Seq=0 Win=6667 Urg=0 Len=16
    192.99.37.41 -> x.y.z.119 TCP 74 [TCP Retransmission] 0?0 [FIN, SYN, RST, PSH, URG, CWR, NS, Reserved] Seq=0 Win=6667 Urg=0 Len=16
    192.99.37.41 -> x.y.z.119 TCP 74 [TCP Retransmission] 0?0 [FIN, SYN, RST, PSH, URG, CWR, NS, Reserved] Seq=0 Win=6667 Urg=0 Len=16
    192.95.30.185 -> x.y.z.24 TCP 74 0?0 [FIN, PSH, ACK, URG, ECN, Reserved] Seq=1 Ack=1 Win=6667, bogus TCP header length (0, must be at least 20)
    137.118.96.23 -> x.y.z.70 TCP 74 0?0 [FIN, SYN, RST, PSH, URG, ECN, CWR, NS, Reserved] Seq=0 Win=6667, bogus TCP header length (12, must be at least 20)

    Internet Protocol Version 4, Src: 137.118.96.23 (137.118.96.23), Dst: x.y.z.70 (x.y.z.70)
    Version: 4
    Header Length: 20 bytes
    Differentiated Services Field: 0x10 (DSCP 0x04: Unknown DSCP; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
    0001 00.. = Differentiated Services Codepoint: Unknown (0x04)
    .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
    Total Length: 60
    Identification: 0xa2c7 (41671)
    Flags: 0x02 (Don't Fragment)
    0... .... = Reserved bit: Not set
    .1.. .... = Don't fragment: Set
    ..0. .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 49
    Protocol: TCP (6)
    Header checksum: 0x0cde [validation disabled]
    [Good: False]
    [Bad: False]
    Source: 137.118.96.23 (137.118.96.23)
    Destination: x.y.z.70
    Transmission Control Protocol, Src Port: 0 (0), Dst Port: 0 (0), Seq: 0
    Source Port: 0 (0)
    Destination Port: 0 (0)
    [Stream index: 872]
    [TCP Segment Len: 28]
    Sequence number: 0?(relative sequence number)
    Header Length: 12 bytes (bogus, must be at least 20)

    09:16:46.687528 IP 137.118.96.23.0 > x.y.z.70.0: tcp 28 [bad hdr length 12 - too short, < 20]
    0x0000: 4510 003c a2c7 4000 3106 0cde 8976 6017 E..<..@.1....v`.
    0x0010: xxyy zz46 0000 0000 c0f1 59ce 0000 0000 .3.F......Y.....
    0x0020: 3bef 1a0b ff7f 0000 6cf6 2346 0000 0000 ;.......l.#F....
    0x0030: 0000 0000 0000 0000 a002 7d78..........}x

    ---
    Johannes B. Ullrich, Ph.D.
    STI|Twitter|LinkedIn

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