CSAM: Patch and get pw0ned (not OR).
"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.
?
Shellshock: More details released about CVE-2014-6277 and CVE-2014-6278. Also: Does Windows have a shellshock problem?
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
Spoofed packets with Window Size 6667: Anybody else seeing this?
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
Comments