Out and About: Detroit’s BSides

Archive for the ‘Security’ Category

Egpyt’s Mubarak fined for Internet cut-off

Posted by Wolf Goerlich

Interesting.

In February, President Hosni Mubarak disconnected the Egyptian people from the wider Internet at the peak of the protests.

In March, Libyan leader Muammar Gaddafi followed suit. Libya, too, went dark on the ‘net.

Both Egypt and Libya came back online. But lest we think this is a third-world government thinking, note the US congress was debating the “Internet kill switch” bill during this time.

Hopefully clearer heads will prevail. That seems to be the case in Egypt, anyways, as today news broke that the government is fining Mubarak for the Internet cut.

Dropbox – risks and remediation

Posted by Wolf Goerlich

Dropbox is a cloud service that presents storage as a local computer drive. Michael Galligan introduced me to the service about a year ago, when he redid the SimWitty branding. You install the Dropbox app, the folder appears, you copy files to the folder, and they synchronize with anyone else who has access to your Dropbox folders.

There are some real risks with transferring files using someone else’s system, of course. There is the chance of local attacks on your Dropbox (see: Dropbox authentication: insecure by design). More likely, there is a chance of a security incident at Dropbox’s systems, thus allowing a malicious insider or attacker to gain access to the documents. A big collection of documents presents an attractive target.

What to do? Dropbox released some guidance this week. Using the tried-and-true Truecrypt software, you can encrypt your Dropbox folder. This restricts access to only those who have access to your decryption key. It is a good option for those who want the ease of the cloud with some assurances as to the safety of the data.

Cord Blood Registry breach – encryption controls and media controls

Posted by Wolf Goerlich

Backup Files Put Database Information At Risk
Cord Blood Registry breach a cautionary tale in the need for encryption, key management, and secure physical transport of database back-up media.

Kelly explains that step No. 1 to keep this database information secure is implementing strong encryption practices and key management. J. Wolfgang Goerlich, a network security manager at a financial services firm, concurs. He says the risk of misplaced backup information is at the top of his list of worries.

“Encryption is the No. 1 control to prevent scenarios such as the Cord Blood Registry breach. Encryption does require time for configuration and ongoing maintenance, but it has a very low fixed cost,” Goerlich says. “In the Cord Blood Registry scenario, three areas that should have been encrypted: the laptop hard drive, the database backup file, and the LTO4 backup tapes. If encrypted, the stolen media would be all but useless. The personal information of 300,000 people would be unreadable and unrecognizable.”

He also believes organizations need to do a better job instituting tape media procedural controls as well. “These ensure that the storage tapes are transported in a manner that is physically secure. From the initial reports, it looks like Cord Blood Registry did not have these in place,” he says. “A solid procedure would prevent transporting sensitive backup tapes using an employee’s vehicle and prevent leaving those tapes unattended in a parking lot.”

Miss the basics, miss the boat – Core Blood Registry

Posted by Wolf Goerlich

“The Cord Blood Registry earlier this week began notifying some 300,000 registrants that their personal data might be at risk. (…) a report on the Office of Inadequate Security website indicates that the breach was the result of the theft of data backup tapes from an employee’s car.”

— darkreading.com

The breach is a good reminder of the basics. If it moves, encrypt it. If it rests, encrypt it. If you are moving tapes, have basic media controls in place to keep unsecured tapes from sitting in someone’s car. Miss the basics, miss the boat.

Bypassing IDS/NSM detection

Posted by Wolf Goerlich

There are a number of ways an attacker can circumvent the protection of network security monitoring. He can use evasion techniques to avoid detection, or use diversion techniques to distract the defender. Here are a couple methods.

Protocol misuse. NetFlow and layer 1/2/3 statistics track hardware addresses, IP addresses, and TCP/UDP ports. Application layer detail is generally not analyzed and tracked. Any packet sent over port 80 will be assumed an HTTP packet, anything over port 53 a DNS packet, and so on. An attacker can send information over alternate ports to mask their activities. Alternatively, some protocols can be directly misused to carry out an attacker’s aims. For example, see the OzymanDNS app that tunnels SSH and transfers files over the standard DNS protocol. When application layer tracking is not enabled, an attacker has a blind spot that they can use.

Kaminsky, D. (2004, July 29). Release!, from Dan Kaminsky’s Blog: http://dankaminsky.com/2004/07/29/51/

Payload obfuscation. An attacker can also create a blind spot by obfuscating (or disguising) their application layer traffic. If application layer analysis is enabled, it may be utilizing pattern matching for application layer analysis. The attacker has to modify the packet or its payload enough to no longer match the pattern. Perhaps the simplest method is fragmentation, where the IP packet is broken into fragments. Any one fragment will not match the pattern detection. When the fragments get to the host computer, the host re-assembles the packet. The attacker’s payload is then delivered undetected.

Schiffman, M. (2010, February 15). A Brief History of Malware Obfuscation, from Cisco:http://blogs.cisco.com/security/a_brief_history_of_malware_obfuscation_part_1_of_2/

Timm, K. (2002, May 05). IDS Evasion Techniques and Tactics, from Symantec: http://www.symantec.com/connect/articles/ids-evasion-techniques-and-tactics

Denial of Service. A solid NSM solution is one that performs application layer analysis, checks for fragmentation, and negates common obfuscation techniques. An attacker then has options. Think of the smash and grab crimes, where the criminal gets in, gets what they can, and gets out quickly. The equivalent is the attacker who triggers the NSM in one area to create a distraction while they attack in another area. For example, an attacker launches a Denial of Service attack on a network link unrelated to their real target. Alternatively, the DoS targets the NSM infrastructure itself. If the attack is a quick raid of the victim’s network, such methods may pay off.

In sum, attackers can hide in the blind spots, cover their tracks, or make diversions.

DNS Intel with Dig in Cygwin

Posted by Wolf Goerlich

Dig, short for domain information groper, is a simple command line utility often used for network reconnaissance.

Dig can be installed under Net -> bind (update: bind-utils) in Cygwin. Dig will use the default DNS settings (check ipconfig /all.) Once installed, if you want to hardcode the dig to a specific DNS server, launch Cygwin and create a resolv.conf file.

$ cat > /etc/resolv.conf
nameserver <your IPv4 address here>

Ctrl-Z and you are good to go. Dig can then be used for intel on a particular domain. For example, the website, mail servers, and DNS name servers.

$ dig www.jwgoerlich.us
$ dig www.jwgoerlich.us MX
$ dig www.jwgoerlich.us NS

Another option is attempting to do a zone transfer, either full (AXFR) or incremental (IXFR).

$ dig www.jwgoerlich.us AXFR
$ dig www.jwgoerlich.us IXFR

Transfers will create a full copy of all the records in the DNS domain. Typically, this command is used simply to validate that zone transfers have been disabled.

That is dig in Cygwin, in a nutshell.

Internet kill switches

Posted by Wolf Goerlich

January 27: the day the Internet died.

Protests have been ongoing this week in Egypt. There has been a significant amount of press coverage on the political situation. The riots began on the January 25 and then, on January 27, President Hosni Mubarak unplugged Egypt from the Internet.

The reasons given for going dark are that the rioters were using the Web and Internet to coordinate. This makes sense, as we have seen Twitter and other social media sites used in recent unrests. The main concern for InfoSec is the precedence that Mubarak has set.

Will other countries, faced with similar situations, choose to unplug? It seems likely. For example, at the same time Egypt was unplugged, the U.S. re-introduced the “Internet kill switch” bill. (Read the bill at Thomas or see Wired’s kill switch coverage.) Of course, killing the Internet will have economic repercussions.

And that’s what I am thinking about today. Should the Internet be disabled, how would my firm continue to do business? How would we send and receive communications? In terms of InfoSec and engineering, what mitigations could be deployed for this risk?

J Wolfgang Goerlich

 

How did they do it? Both Ars Technica and Wired have articles on the technical aspects of unplugging. How are people coping? The old standby is modem dialup, although some are calling others to post information, or faxing information out to the Internet. Wired also posted a Wiki on how to communicate if your government shuts off your Internet.

Netflows Simplified (Part 2)

Posted by Wolf Goerlich

There are two drivers for NetFlow might not be immediately obvious.

The first is that NetFlow requires significantly less throughput than full packet capture. For example, see this discussion on how much bandwidth is needed to capture all the packets in a typical business. Let’s say 100 Gbps span port for typical SMB (100-1000 employee) company. NetFlow takes <5% of the bandwidth that full packet capture requires. So you could get by with five 1 Gbps span ports, which is a huge cost savings on the switching side.

The second driver is statistical analysis. Let’s assume you did not want the complexity of five 1 Gbps mirror ports (and the corresponding grunt work on the NSM to avoid duplicate entries.) If you only want 1 Gbps port, you have two options. The first option is to watch one-fifth of your servers. This poses a problem if your infected computer(s) are in the four-fifths of the LAN you are ignoring. The second option is to statistically select 1 in 5 packets from the stream. Your NSM will now have full coverage on the network, greatly improving your chance at identifying infections.

Netflows Simplified (Part 1)

Posted by Wolf Goerlich

For any given office computer at any given time, numerous network communications are ongoing. There may be Kerberos authentication and ticketing occurring between the computer and the domain controller. Streaming audio from, say, Pandora leaves many packets. ARP and DNS packets will be interspersed with application layer packets for files and websites. In sum, there are many thousands of packets to work through.

Like separating spaghetti strands from a bowl of pasta, separating packets into sessions allows us to separate and study the communication from end-to-end. Session data presents the packets for a single communication. That is, for a source host, a destination host, and a given application layer protocol. The InfoSec analyst can then follow the packet trail thru the session to see what transpired and how.

Now there are two ways to read a session: in detail and in summary. The detail of a session includes all the bytes of the packets. This is available from a switch mirror port. The summary of a session includes the packet headers (IP, UDP, TCP). There are a few ways to get this information, including the Cisco NetFlow protocol. NetFlow can be all of all packets or of statistically relevant packets (sampled NetFlow).

Picture all network traffic for a given office computer as a big bowl of pasta. Pull out individual strands to get your session data. Keep statistics on the strands to get your NetFlow.