September 2008 Archives

Dave Lewis at Liquid Matrix has pointed out an article from Denver 9 News. Apparently, TSA employees no longer have to go through security when reporting to work -- they are allowed to take backpacks purses, and other personal items into secured areas without inspection.

From Denver 9 News:

The TSA says the new policy is part of a risk-based security screening process where there are multiple layers of security

"We have a finite amount of resources and we allocate those where we think the risk is greatest," said Harmon. "It's based on intelligence; it's based on knowledge of our people and our processes."

The TSA says its employees have background checks before they are hired. TSA policy says employees are supposed to report any other arrest, including an alcohol related arrest, within 24 hours or, due to circumstances beyond their control, as soon as possible after that. [From 9NEWS.com | Colorado's Online News Leader | Airport screeners bypassing security]

Most companies vet their employees as part of the hiring process as well -- the TSA isn't unique there. I certainly had to go through a background check before starting my current position. In my position, secured areas are electronic rather than physical, but the general principals still apply.

I don't have unfettered access to secure areas. There are still access controls, audits, and policies that manage my access. In short, the access rules are designed to minimize insider threats.

Yes, inside attacks are much rarer than external attacks, but the impact is far more severe when the attacks do occur. The insiders know exactly where the valuable targets are and how to exploit them.

Insider threat is real, and TSA has an easy win available to them to -- a policy decision to make employees go through existing security check points.

The Computer Security Group at the University of California Santa Barbara have done an in-depth look at the voting machines used by the State of California and have authored a proof of concept virus.

From UCSB:

In the Summer of 2007, the Security Group of UCSB participated in the Top-To-Bottom Review (TTBR) of the electronic voting systems used in California. This was a first-of-its-kind review, where the evaluators had unprecedented access to the systems' source code, hardware, and associated documentation.

* * *

In particular, we developed a virus-like software that can spread across the voting system, modifying the firmware of the voting machines. The modified firmware is able to steal votes even in the presence of a Voter-Verified Paper Audit Trail (VVPAT). [From UCSB: Evaluating the Security of Electronic Voting Systems]

There are currently three publications around this research. A report, a formal paper, and a video.

Here is the video (in two parts):

Apparently, NASA is sending unclean builds into orbit leading to a first -- a space worm.

From hungry-hackers.com:

SAN FRANCISCO: NASA confirmed that a computer virus sneaked aboard the International Space Station only to be tossed into quarantine on July 25 by security software.

A "worm type" virus was found on laptop computers that astronauts use to send and receive email from the station by relaying messages through a mission control center in Texas, according to NASA spokesman Kelly Humphries on Wednesday. [From Computer virus goes into orbit | Hacking Truths]

The Dark Visitor blog suggests that the worm is Chinese in origin:

The trojan is also referred to as the kavo.exe virus and is designed to gather information on ten online games:

ZhengTu
Wanmi Shijie or Perfect World
Dekaron Siwan Mojie
HuangYi Online
Rexue Jianghu
ROHAN
Seal Online
Maple Story
R2 (Reign of Revolution)
Talesweaver

* * *

Will check more into the origin of this malware later today but all indicators suggest that it could be Chinese. [From The Dark Visitor » Chinese hacker malware infects International Space Station?]

While it may be Chinese, I'm betting it isn't an intentional attack. Unless, of course, Chinese and Korean MMOGs are popular on the space station.

It's interesting that the Microsoft Secure Development Lifecycle is approaching XSS attacks in the same way desktop vulnerabilities are tackled.

In a sense, the SDL is metasecurity -- while still addressing direct security issues (individual attacks/vulnerability), the SDL also looks at the process by which applications are written and actually prevents future vulnerabilities from being created. And on the meta-meta-level, the SDL also examines the SDL.

I'm only quoting a small part of the article. Please read the whole thing and follow the links out -- there is a lot of very interesting work being done around XSS at Microsoft right now.

From Steve Lipner via the SDL Blog:

David's years of work researching XSS led him to come up with an approach that blocks many of the most common vulnerabilities to reflected attacks found on the web today. The solution is compatible with existing web pages (doesn't "break the web") and thus we were able to enable it by default for users of Internet Explorer 8. Because it's a client-side mitigation, it will help protect users from attacks even though the sites they visit may be vulnerable to XSS.

Our work on buffer overrun defenses follows a somewhat similar pattern - we started by prescribing coding techniques, banning the use of some APIs, and building tools that detect coding constructs that look like buffer overruns. [From The Security Development Lifecycle : SDL and the XSS Filter]

I've been on vacation and then spent time catching up at work, so it's been a couple of weeks since I've been posted regularly. I'm trying to catch up now, so here goes ...

This is an interesting post from CERT . What's most interesting about it is that it's a desktop version of an old web vulnerability where an attacker uploads a code file into an improperly secured directory and then executes it remotely. I'm sure nobody is writing web code like that any longer (right?), but the execution directory thing is apparently still a problem (though Vista fixes it as the source notes).

From the Cert Vulnerability Analysis Blog:

Hey, it's Will. Earlier this year, details about "carpet bombing" attacks were released. Apple addressed the issue by prompting users before downloading files, but recent news indicates that Google Chrome, which is based on Apple's WebKit code, is also vulnerable to the same type of attack. However, some people seem to be missing an aspect of the attack that affects all web browsers.

When loading a DLL, Microsoft Windows looks for the DLL in a certain sequence of directories. The first match for the file name wins. In most cases, Windows will first look for a DLL in the same location as the executable. This behavior is what allows the Apple Safari "carpet bombing" vulnerability to work. If an attacker can place code in a directory that gets searched before Windows finds the "real" DLL, the attacker's code will be executed. [From Vulnerability Analysis Blog: Carpet Bombing and Directory Poisoning]

After being away from things for a week on vacation, I gave a brief talk last night at the Seattle PHP Meetup. While I don't want to recount the takl as a whole, I did recommend several books to the developers attending. Here they are:

• OWASP Guide 2005: ($11.45, lulu.com) This freely redistributable book (you can download a copy for free here) is one of the standards. OWASP is a collaborative web security group and this is their outline for best practices.
• php|architect's Guide to PHP Security ($21.77, Amazon.com) While I don't think this book contains the best writing around, it is a good look at PHP-specific issues. And it includes lots of code examples (code examples are good).
• Secure Coding: Principals and Practices ($26.95, Amazon.com) This book looks at the entire development lifecycle from design to obsolecense from a security framework. There are lots of Secure Development Lifecycle frameworks. I chose this book because it looks more at the principals in general than at applying a specific framework.
  
• Web Application Hacker's Handbook:($30, Amazon.com) This is a fabulous book. While the other text deal with how to secure an application, this one will shop you how insecure code is actually exploited. I think it's important to understand both sides of code security so that we think about things in terms of actual security rather than just following best practices.