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 doesn't 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 doesn't 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 browser's lead (I don't 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 can't 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.


Johannes B. Ullrich, Ph.D.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Among other items, the XProtect list now includes several iWorm variants.
Andrew Cunningham

In case you missed it over the weekend, MacRumors reports that Apple has updated OS X's built-in XProtect malware definitions list to include the Mac.BackDoor.iWorm malware we reported on late last week. The iWorm malware allegedly managed to infect more than 17,000 Macs worldwide, and it was apparently using a (now closed) Minecraftserverlists board on reddit to distribute the IP addresses of control servers to infected Macs.

XProtect was first introduced to OS X in Snow Leopard in response to the MacDefender malware that managed to infect some OS X systems back in 2011. While the complete list is only 40 items long as of this writing, OS X silently checks for XProtect updates daily, and Apple also uses the list to mandate the usage of up-to-date versions of Java and Flash. While XProtect doesn't do anything to clean existing infections, it can prevent new ones by telling users explicitly that they're attempting to install known malware.

Dr. Web, the antivirus vendor that first reported the existence of both the malware and the botnet, recommends that you buy its products to scan for and delete malware that may already be on your computer—researchers at antivirus companies can get the word out about new vulnerabilities, but they don't do it out of the goodness of their hearts. Developer Jacob Salmela has some instructions that can help you delete the malware manually.

Read on Ars Technica | Comments


Security firm Check Point Software Technologies used a flaw it discovered in the Perl programming language to hack into the popular Bugzilla bug-tracking system and add four users to the administrator group, giving them power to see the details of undisclosed vulnerabilities.

The bold demonstration, detailed in a private bug report made public on Monday, took advantage of a new class of flaws discovered by Check Point in the Perl programming language, allowing the organization to craft specific strings of text that essentially fooled Bugzilla's user database. Check Point created administrator accounts for mozilla.com, mozilla.org, bugzilla.org, and bugzilla.bugs in the system.

"This is not an SQL injection attack, this is something rather new," Shahar Tal, security research team leader at Check Point, told Ars. "This is part of research that we have been working on for a couple of months on a specific Perl issue. Bugzilla is a good example and sample, but it is not the only project that we were able to find vulnerabilities in."

Read 8 remaining paragraphs | Comments

HTTP File Server 'ParserLib.pas' Remote Command Execution Vulnerability

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Cisco ASA Software CVE-2014-3398 Information Disclosure Vulnerability

The US Food and Drug Administration released guidance last week in which it suggested that medical-device manufacturers consider the dangers of hacking in the design of their products, while not requiring countermeasures.

The nine-page document informs companies of the agency's "current thinking" on the topic of cybersecurity. In it, the FDA recommended that companies assess any dangers on the intentional or unintentional misuse of a device in their design stage. In addition, medical devices and systems should detect and log attacks and allow technicians to react to such attacks, whether through patching a vulnerability or other action.

"The need for effective cybersecurity to assure medical device functionality and safety has become more important with the increasing use of wireless, Internet- and network-connected devices, and the frequent electronic exchange of medical device-related health information," the agency stated, adding that "manufacturers should address cybersecurity during the design and development of the medical device, as this can result in more robust and efficient mitigation of patient risks."

Read 6 remaining paragraphs | Comments


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.

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

A security researcher claims to have uncovered a botnet being built by Romanian hackers using the “Shellshock” exploit against servers on a number of high-profile domains, including servers at Yahoo and the utility software developer WinZip. Jonathan Hall, president and senior engineer of technology consulting firm Future South Technologies published a lengthy explanation of the exploits and his communications with the exploited on his company’s website this weekend and said that Yahoo had acknowledged finding traces of the botnet on two of its servers.

Hall found the botnet, he said, by tracking down the source of requests that probed one of his servers for vulnerable CGI server scripts that could be exploited using the Shellshock bash vulnerability. That security flaw allows an attacker to use those vulnerable server scripts to pass commands on to the local operating system,  potentially allowing the attacker take remote control of the server. Hall traced the probes back to a server at WinZip.com. He then used his own exploit of the bash bug to check the processes running on the WinZip server and identified a Perl script running there named ha.pl.

After extracting the contents of the script, Hall discovered that it was an Internet Relay Chat (IRC) bot similar to ones used to perform distributed denial of service attacks on IRC servers. However, as he examined it more closely, he found that it “appeared to focus more on shell interaction than DDoS capabilities,” he wrote. According to Hall, it takes remote control of the server, while using its IRC code to report back to an IRC channel (called, creatively, #bash). The code was also heavily commented in Romanian.

Read 6 remaining paragraphs | Comments


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
  • 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... )

output?of a sample with obfuscated target IP: -> 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 -> 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 -> 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 -> 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 -> 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 -> 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 -> 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) -> 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: (, 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: (
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 > x.y.z.70.0: tcp 28 [bad hdr length 12 - too short, < 20]
0x0000: 4510 003c a2c7 4000 3106 0cde 8976 6017 E..< [email protected]`.
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.
LinuxSecurity.com: Security Report Summary
LinuxSecurity.com: Multiple parsing flaws in Bash could allow remote attackers to inject code or cause a Denial of Service condition.
LinuxSecurity.com: Security Report Summary
LinuxSecurity.com: Security Report Summary
LinuxSecurity.com: Security Report Summary
Perl 'Email::Address' Module CVE-2014-4720 Denial of Service Vulnerability
[SECURITY] [DSA 3046-1] mediawiki security update
[SECURITY] [DSA 3045-1] qemu security update
[SECURITY] [DSA 3044-1] qemu-kvm security update
[SECURITY] [DSA 3042-1] exuberant-ctags security update

Naked Security

Security incidents are up - and pricier! - but infosec budgets are dwindling
Naked Security
The number of security incidents is rising, as are associated costs to clean them up. Global corporate security budgets, meanwhile, seem to be hiding in the closet, just hoping it all goes away. The news of this depressing state of affairs comes ...

and more »
Internet Storm Center Infocon Status