Latest Alerts

Syndicate content SANS Internet Storm Center, InfoCON: green
Updated: 9 min 47 sec ago

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

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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

ISC StormCast for Monday, October 6th 2014 http://isc.sans.edu/podcastdetail.html?id=4179, (Mon, Oct 6th)

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

Detecting irregular programs and services installed in your network, (Sun, Oct 5th)

Sun, 10/05/2014 - 09:34

When the corporate network becomes target, auditing for security policy compliance can be challenging if you don't have a software controlling irregular usage of administrator privilege granted and being used to install unauthorized software or to change configuration by installing services that could cause an interruption in network service. Examples of this possible issues are additional DHCP Servers (IPv4 and IPv6), Dropbox, Spotify or ARP scanning devices.

We can use nmap to detect all protocols that sends broadcast packets and are supported by packetdecoders.lua:

  • Ether
    • ARP requests (IPv4)
    • CDP - Cisco Discovery Protocol
    • EIGRP - Cisco Enhanced Interior Gateway Routing Protocol
    • OSPF - Open Shortest Path First
  • UDP
    • DHCP
    • Netbios
    • SSDP
    • HSRP
    • DropBox
    • Logitech SqueezeBox Discovery
    • Multicast DNS/Bonjour/ZeroConf
    • Spotify

The following example shows how to use nmap with the broadcast listener script and we can see the result of a device with dropbox installed, a device sending ARP request (a router in this case) and a device sending DHCPv6 requests:

You can run this program periodically to track common security issues in your network, just in case your IPS could be missing something ;)

Manuel Humberto Santander Pelaez
SANS Internet Storm Center - Handler
Twitter:@manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org

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

Testing for opened ports with firewalk technique, (Sat, Oct 4th)

Sun, 10/05/2014 - 09:33

There is an interesting way of knowing what kind of filters are placed in the gateway of a specific host. It is called firewalk and it is based on IP TTL expiration. The algorithm goes as follows:

  • The entire route is determined using any of the traceroute techniques available
  • A packet is sent with the TTL equal to the distance to the target
  • If the packet times out, it is resent with the TTL equal to the distance to the target minus one.
  • If an ICMP type 11 code 0 (Time-to-Live exceeded) is received, the packet was forwarded and so the port is not blocked.
  • If no response is received, the port is blocked on the gateway.

Let?s see this with a real example. Consider the following network diagram:

Firewalking happens with the following steps:

  1. Traceroute packets are sent to determine the gateway with decremental TTL:

....

2. An ICMP Time Exceeded message is received from the default gateway for the TTL=2 and TTL=1 packet, which means there are two gateways between origin and destination and TTL=3 is the distance to the destination

3. Several packets are sent with TTL=3 to the destination varying the destination port. The sequence goes as follows: A first packet is sent with TTL=3. If a timeout occurs, a second packet is sent with TTL=1. If an ICMP type 11 code 0 (Time-to-live exceeded) is received, the gateway is forwarding the packet.

Let?s see the first packet to port 1 and TTL=3:

Timeout occurs, so same packet is sent with TTL=2:

ICMP type 11 code 0 is sent from the gateway routing the destination host, which means the packet was forwarded and the port is opened:

How can we use this technique? Nmap has a firewalk script that can be used. For this example, the following command should be issued:

nmap --script=firewalk --traceroute 172.16.2.165

Manuel Humberto Santander Pelaez
SANS Internet Storm Center - Handler
Twitter:@manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org

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