Always beware of conference wireless...

ZDNet UK is running an article about some attackers providing counterfeit wireless access to attendees. According to the story, the crackers strolled around the conference with access points running on their laptops and advertising well-known SSIDs (like tmobile). When a victim associated with the access point, the software generated
randomly-mutated malware (to bypass antivirus scanners) and attempted to download it onto the client.

None of these features are new, but the combination is. This is a very nasty (and probably quite effective) use of existing off-the-shelf technology.

Schneier on "Hacking the Papal Election"

This is how you think about everything in your life if you're in the security field. Check out Bruce Schneier's analysis on Hacking the Papal Election.

Insight on this month's "Scan of the Month"

Richard Bejtlich (analyst, author and blogger extraordinaire) has a good point in his latest blog entry. The Honeynet Project's Scan of the Month collects a whole lot of data, but how much time will it take a good analyst to complete the challenge? Properly applied NSM certainly would make this sort of thing much easier. Go sguil!

DoD goes l33t

Wired News is running an article, titled U.S. Military's Elite Hacker Crew, about the Joint Functional Component Command for Network Warfare (JFCCNW). Although everyone has pretty much assumed that our military has had this Information Warfare capability for some time, the existence of l33t gov't h4x0rs has recently been confirmed. Not much other detail is available, but this is a start.

Five Mistakes of Incident Response

InfosecWriters has a short but sweet paper by Anton Chuvakin, entitled Five Mistakes of Incident Response. It's a quick, easy read that I wholeheartedly recommend. In fact, I would have added a mistake #0: Panicking. Keeping your cool is always the most important thing in Incident Response. Still, this paper is a great summary of the other top five mistakes to avoid.

Detecting attacks in RFC3514-compliant traffic

Those of you who run RFC3514-compliant networks might be interested in this snort rule I wrote. It has an unusually good detection rate, with very low false positive and false negative rates. So far it's working well for me, so I thought I'd share it:

alert ip any any -> any any (msg:"RFC 3514 Attack Traffic Detected"; fragbits:R; classtype:misc-attack; sid:35140; rev:1;)

PITAC report misses the point entirely

The President's Information Technology Advisory Committee has just released their report on Federal support of basic computer/network security research in this country. As you can probably guess from the title, Cyber Security: A Crisis of Prioritization, the report concludes that the government needs to invest in more support for basic security research if it wants to get the technology and the trained professionals it needs to implement a long-term strategy for securing its information assets.

The report is well worth reading, but by focusing on the research angle, it misses a much more important point for the short- and medium-term security of government systems: The US government often does not provide civilian agencies with adequate funding, personnel or training to carry out appropriate security plans. The entire system is predicated upon the assumption that if a mandate comes down, it will be implemented regardless of operational issues such as cost, suitability to the existing computing environment or available manpower.

Until the government stops trying to simply decree security and starts to really get serious about providing agencies with the ability to implement the decrees, we're not going to see much overall improvement in security posture no matter how much research we do.

33% of IRS Workers Vulnerable to Social Engineers

The Washington Post has an AP story today stating that "more than one third" of the 100 IRS employees tested by the auditors gave up their login information in response to a simple phone call from a fake technician.

Apparently this was a big increase over the last test 4 years ago, when 71% of those called cooperated, but I think it'd take a lot of guts to try to spin this as an improvement.

NSA Recommends Suite B Encryption Algorithms

The National Security Agency employs some of the US's (and probably the world's) best cryptographers, so when they talk codes & ciphers, people listen. I didn't notice this bit of news when it first happened, but last month the NSA recommended a suite of cryptographic algorithms known as Suite B for use in encrypting sensitive but unclassified data.

The biggest news here is that the NSA is finally recommending a set of algorithms that includes public key cryptography, Elliptic Curve Cryptography (ECC) in this case. Suite B also includes several other algorithms, such as an ECC variant of the Diffie-Hellman key exchange protocol and non-public key schemes, like AES and SHA. Some of the components of Suite B are public standards, but apparently the core ECC technology itself is licensed from Ontario, CA based Certicom. Good news for them, certainly, but I'm not entirely sure what this means for those of us in the Open Source world. You can read their official press release here.

On a final note, these articles raised a question in my mind that I haven't seen anyone else ask yet... What was in Suite A, and why wasn't it approved instead?

Global DNS Cache Poisoning?

SANS's Internet Storm Center is tracking a possible global DNS cache poisoning attempt for several high profile web sites like Google, eBay and Weather.com. Read their preliminary diary entry here, and let them know if you're seeing the same thing.

Remotely identifying computers via clock skew

ZDNet Australia is reporting that a University of California doctoral student has developed a technique for telling different computers apart over the network by detecting their clock skew. According to this article, the technique works behind NAT devices and over long periods of time, even if devices move around a lot.

I need to read the research paper in order to decide whether I believe this or not, but it sounds plausible. Unfortunately, the paper is not yet available.

UPDATE [2005-03-04 12:42]: The paper is indeed available, and can be found here.

Good take on RHEL's SELinux

Andy Oram has an interesting article on his blog about how his approach to RedHat's targetting SELinux policies changed once he really thought about their intended deployment model. I won't give away the ending, but you can read it for yourself.

SHA-1 Broken?

Bruce Schneier's latest blog entry mentions an as-yet uncirculated paper that claims to show how to drastically reduce the number of operations needed to find a hash collision. If I read this correctly, Schneier has read the paper himself, but has not yet been able to verify the results. But it's obvious he's taking this very seriously, and that's good enough for me.

Howard on Safer CRT

Microsoft's Michael Howard (co-author of Writing Secure Code and maintainer of a great Windows-oriented security blog has started writing a series of articles about the new security-enhanced C runtime library that will start shipping in the next beta version of Visual Studio. This won't automagically turn Windows into a security powerhouse, but this looks like a very promising step. I can't wait to hear more.

Wireless hacking presentation: "All Your Layer Are Belong To Us"

Among the presentations at ImmunitySec's recent Security Shindig 3 this exciting presentation about exploiting Windows Wireless Zero-Configuration behavior to an attacker's benefit. My favorite quote is "You can be 0wned while watching a DVD on a plane!"

Seriously, this is an interesting presentation. I would have loved to have been there for the demo of KARMA, the tool they wrote that automates these attacks. Don't know if it's available for download anywhere.

How manufacturers protect themselves from online lowballers

Ok, I know this isn't exactly about information security, but here's a cool article describing in some detail how major manufacturers protect themselves online black marketeers. This obviously isn't 100% effective, but it's kinda neat, in a King Canute sort of way.

InfosecBooks.Com

I just wanted to put in a little plug here for my other blog, InfosecBooks.Com. I read security books, then I let you know what I think about them. If that sounds good to you, drop by sometime.

Detecting TOR on your network

I've written about the TOR anonymizing TCP proxy before, and in general I think it's quite a useful tool. There are a lot of situations where you might legitimately want to obfuscate your true online identity and/or prevent your ISP from keeping track of what you access over the Internet. TOR is really good for these sorts of things, and is a cool project, to boot.

There are some situations, though, in which using TOR (or any other similar service) is not appropriate. One such situation is when your Acceptable Use Policy forbids it, as is probably the case for many people using their employer's LAN. If you're a network administrator and you need to monitor TOR usage, you can try the following Snort rule I cooked up:

alert tcp any any -> $HOME_NET any (msg: "TOR 1.0 Proxy Connection Attempt"; content: "TOR"; content: "<identity>"; within:30; classtype:policy-violation; resp:rst_all; sid:5000030; rev:1;)

This should alert you any time the TOR proxy attempts to create a connection to the rest of the TOR network. As written, this rule also makes use of Snort's "flexible response" feature to try to shut down the connections as they are established. This isn't entirely effective, but it seems to work about 80% of the time for me, which at least makes TOR really annoying to use. If you prefer not to take action, delete the part that says "resp:rst_all;".

More on the T-Mobile/Secret Service connection

This story sheds a little more light on how the T-Mobile hacker was able to access Secret Service documents. It seems that one of their agents made a habit of forwarding files to his T-Mobile email device so he could access them while traveling.

The article downplays the problem and makes it sound like it wasn't a big deal. The handheld contained "very limited investigative material" and "no government investigations were compromised." However, the article also quotes court records as stating that the files contained "highly sensitive information pertaining to ongoing ... criminal cases." This is apparent contradiction seems to indicate that someone in the USSS is either willfully over- or under-stating the case.

The agent in question, by the way, says he was cleared of any wrongdoing in an internal USSS investigation. He has since voluntarily resigned to work in the private sector.

T-Mobile pwn3d & Shame on the US Secret Service

The Register has a shocking story about a major security breach at T-Mobile. Apparently they learned in July 2004 that an intruder had wormed his way into their customer database and had easy access to a wide variety of information, including names, addresses, dates of birth, social security numbers, web usernames and passwords, email and cameraphone snapshots.

Ok, so shame on T-Mobile for keeping this quiet so long, but the more shocking part is that the US Secret Service fell vicitim to this. Here's a paragraph from the article:


On 28 July the informant gave [the Secret Service] proof that their own sensitive documents were circulating in the underground marketplace they were striving to destroy. He had obtained a log of an IRC chat session in which a hacker named "Myth" copy-and-pasted excerpts of an internal Secret Service memorandum report, and a Mutual Legal Assistance Treaty from the Russian Federation. Both documents are described in the Secret Service affidavit as "highly sensitive information pertaining to ongoing USSS criminal cases".


What the heck is the Secret Service doing sending "sensitive documents" over T-Mobile, anyway? Shouldn't a law enforcement agency so heavily involved in computer crime investigation know better than this?