Feb

7

Norton Antivirus Inventor on Wasted Time in Security

February 7, 2008 | Comments Off on Norton Antivirus Inventor on Wasted Time in Security

Dark Reading is covering the Computer Forensics show in Washington DC, and has this  article on a presentation by Peter Tippett, the guy who invented what would become Norton Antivirus, exec at Verizon, and chief scientist at ISCA. Tippett’s point is that security departments need to be smarter about what they focus their time and effort on:

“You can’t always improve the security of something by doing it better,” Tippett said. “If we made seatbelts out of titanium instead of nylon, they’d be a lot stronger. But there’s no evidence to suggest that they’d really help improve passenger safety.”

Hallelujah, brother! I’m a pragmatist, and I believe that you have to carefully evaluate your level of security, because 100% secure is probably too expensive. There’s a definite point of diminishing returns for security, and it’s different for every application you’re going to build.

Now, I haven’t seen the complete  text of the presentation. Tippett cites a number of things that he thinks we should not be doing:

For example, today’s security industry focuses way too much time on vulnerability research, testing, and patching, Tippett suggested. “Only 3 percent of the vulnerabilities that are discovered are ever exploited,” he said. “Yet there is huge amount of attention given to vulnerability disclosure, patch management, and so forth.”

It’s rather short on things that he thinks we should be doing, unfortunately, citing only a single example. As a result, the article comes off as a bit of a “geez, we need to do this better” without any concrete recommendations as to how to go about improving. How is unfortunately what most folks need…

Feb

6

ActiveX Takes Another Beating

February 6, 2008 | Comments Off on ActiveX Takes Another Beating

Earlier in the week, Symantec reported that there were new flaws found in a number of Microsoft’s ActiveX controls, and the recommendation from SANS was to disable these controls due to these problems.

Today, Symantec is reporting today (via CSO Online) that they’re already seeing exploits in the wild using the Yahoo Jukebox control:

The attack, which was first observed in the last few hours, is not widespread at present. Symantec Security Response Director Oliver Friedrichs said Tuesday that the company had identified just three Web sites that were hosting the attack code, all of which seem to be linked to the same criminals. But he believes that more attacks are inevitable as the bad guys work the code into their malicious toolkits of software.

So it’s past the academic, “yes we should do that” stage, folks: either stop using IE, or get those controls disabled. You’ve been warned.

It’s easy to pick on IE: it’s a very common platform, and it’s wealth of features and tight integration with the operating system make it an attractive target. It’s also frequently a corporate standard, so there’s that built-in base of targets as well. I’ll only point out in passing that MS hasn’t made this problem any easier by disentangling the browser from the OS.

It’s unfortunate that many web application developers take the easier road, and make their web apps such that they’re only compatible with Internet Explorer. This just forces people who might want to use a different browser to use IE as well. With this approach, you then get all the vulnerabilities of each browser.

It’s seductive to get all that power, however, so we’re back to the old continuum, secure on one end, usable on the other. You want it to do whiz-bang things, that may mean that it’s less secure as a result, or takes us an inordinate amount of work to get it going.

Of course, if you need a web application because it’s critical to your business, and that web app relies on one of those insecure controls, then you’re in trouble.

Feb

5

Security as a Chore

February 5, 2008 | 1 Comment

This article from CompuWorld is on it’s surface about how the French bank Société Générale lost $7.3 Billion due to unauthorized and fradulent trades by a junior trader. It’s more than that, however, as the article does a good job talking about the conflicting interests inside a large organization.

There are those people in large businesses that, either because of temperament,  lack of understanding, or lack of time, simply don’t want to deal with computer security.  It’s easier to grant all access rather than figure out the right permissions for the job, to not remember to revoke the right permissions when someone moves from one area to another, and this results in a gradual, and inappropriate, accretion of permissions. Making sure people have the right permissions, that those permissions are kept up to date, and that they’re appropriately terminated is difficult, but the consequences of not doing so are , however, clear in this case.

I can understand, and even sympathize with these overwhelmed folks. They have lots to do, and worrying about security shouldn’t keep them from getting their “day job” done. It’s the reason we need to have a strong centralized authentication and authorization mechanism in place for enterprises like this, and to have policies and procedures in place to make it as easy as possible to get these things updated on a timely basis. Without them, your business stands to lose plenty.

Feb

4

The FBI Wants to Catalog You

February 4, 2008 | Comments Off on The FBI Wants to Catalog You

Found over on CNN, an alarming article on the latest plans the FBI has to catalog everything about you, more or less.

The FBI is gearing up to create a massive computer database of people’s physical characteristics, all part of an effort the bureau says to better identify criminals and terrorists.

It’s really there to track criminals and terrorists, the usual boogeymen. But wait, then we read later in the article:

You don’t have to be a criminal or a terrorist to be checked against the database. More than 55 percent of the checks the FBI runs involve criminal background checks for people applying for sensitive jobs in government or jobs working with vulnerable people such as children and the elderly, according to the FBI.

The FBI says it hasn’t been saving the fingerprints for those checks, but that may change.[…]

This sort of thing makes me really uncomfortable, and that’s coming from someone who’s fingerprints are already on file. Maybe I better explain that, I used to work for a defense contractor, so my fingerprints are on file for the background check. And I’m sure that rants like this won’t help.

I’m not 100% clear on exactly how this helps with terrorists. I mean, weren’t the 9/11 hijackers here legally? Didn’t they do everything possible to stay under the radar (except asking to learn how to land, I suppose)?

Do we then want to start compiling large files on people’s points of view, monitoring their conversations, reading their email, and associating it with their biometric information, such as iris scans and palm prints, even when they haven’t done anything illegal? I’m probably just being paranoid. [1][2][3][4] It’s not like we would maintain information on people even if they’re innocent. Unless they’re applying for sensitive jobs. Or just because we say so.

Somebody hand my my tinfoil hat.

Feb

4

Second Edition of O’Reilly’s Computer Security Basics

February 4, 2008 | Comments Off on Second Edition of O’Reilly’s Computer Security Basics

I’ve been a fan of O’Reilly’s computer books for years. Very seldom do I find that one of theirs is a dud. I don’t know how they do it.

A second edition of their Computer Security Basics has been released. It provides a good overview of the field, without getting into too much arcana. It’s a good starting point for those new to the field, and a good jumping off point to look to look for more in depth info.

Feb

4

How is this Heading off Botnets, Exactly?

February 4, 2008 | Comments Off on How is this Heading off Botnets, Exactly?

The CSO feed today had a link to an article about a local (at least to me!) company that is producing a device that automates the detection of network based attacks. The article was headlined “Startup Looks to Head Off Botnets.”

I  chased the link because I think botnets  are a tremendous threat. They put a huge amount of computing power, scattered across the globe, into the hands of a single nefarious individual. These things are responsible for most of the spam you’ re receiving, for internet extortion, for infecting other machines, and probably for tooth decay as well (I’m not 100% about that last point). Seriously, tho, these things are nasty.

So my curiosity was piqued when I read “heading off botnets”. But we’re talking here about the automated detection of attacks. I fail to see how this qualifies as addressing head-on the problem of botnets, and in fact it’s probably a while before we see if anything interesting comes of this.

The article does raise a good point, however, the days of manually generating signatures for attacks are probably near an end, and we do need a new approach for the problems.

Jan

30

CAPTCHA Cracked

January 30, 2008 | 1 Comment

I wrote earlier in the week about the possible use of something like CAPTCHA to combat Cross-site Request Forgery attacks, and as if by magic, we see the news breaking that CAPTCHA has apparently been cracked by a team of Russian hackers. For a quick recap, CAPTCHA generates images consisting of letters and numbers, then asks the (presumably human) user of a site to enter them in order to verify that it’s a human using the service, rather than a machine.

The argument I made was that you could use something like CAPTCHA to try to verify that requests for certain services (such as check-out, or changing user profile information) was requested by a real user, rather than a javascript program pretending to be human.

The wily Russian(s) in question claim the ability to decode CAPTCHA about 35% of the time, which is probably plenty for most sites. This would probably severely hamper, if not eliminate the usefulness of CAPTCHA as part of the CSRF solution.

Back to the drawing board…

Jan

29

This morning I chased a link over to Dark Reading, and found an interesting article on Cross-Site Request Forgery (CSRF). Some readers may be familiar with Cross-Site Scripting (XSS) attacks. XSS attacks occur when a script on one web page is used to steal session cookies, allowing an attacker to take over an authorized user’s session, for instance.

CSRF is a variation on the theme, where rather than trying to steal sessions or other sensitive information via XSS, the scrips in question simply make requests using the user’s completely valid session credentials. Here’s a human-readable scenario that discusses the technique.

Web browsers and the protocol that they use (HTTP, Hypertext Transfer Protocol) are stateless. This means that when I visit the front page of a popular online retailer, such as Amazon.com, then click on the “books” link, HTTP gives us Amazon.com no built-in mechanism to determine that the two requests came from the same user. It’s as though you were talking with someone by writing them a separate letter for each sentence, and without any sort of indication of who’d written any particular letter. The truth is that the folks that invented HTTP never imagined that it would be put to the types of stateful uses that it is today. Online commerce wasn’t really part of that thought process.

“But wait a minute…” I hear you say, “whizbang.com (fictitious example) does know! Because they can keep track of what’s in my shopping cart!”. So what’s going on here, how do web sites keep track of your conversation? How do they string together each of the clicks you make into a stateful conversation?

A couple of different mechanisms have evolved to do this. The most popular is the use of cookies to assign a unique session ID to each conversation. The server in question makes up a long, random string and sends it to the browser as a cookie. These session cookies are typically set to expire when you shut your browser down.

Cookies, for those unfamiliar with them, are sent from the web server to the browser, and then the browser returns them back to the server as part of each request it sends. Using session cookies to uniquely identify a conversation allows the web server to keep track of the actions you’ve performed using that same session cookie. It’s as though each letter that I send (the letters containing a sentence each, remember?) had the same secret code written in the upper-right hand corner.

There are a few other techniques around to keep track of a session other than cookies, the most popular being URL rewriting and hidden form fields, but cookies are by far the most dominant, so we won’t talk about those here.

So suppose you have an account at the Foo Bank, which is very popular because they offer free network attached storage hardware when you open an account, the modern day equivalent of the free toaster (clearly, this is a fictitious scenario, but it serves to illustrate the point). Because Foo Bank is so popular, I decide to target it. I put together a web site which includes a little javascript program. This program looks through your browser history and determines if you have logged in to Foo Bank as part of your current browser session.

You visit my web page, and my program is downloaded to your browser as part of my web page when you visit my site. The program looks through your history and determines that yes, indeed, you visited Foo Bank and then came to visit my site without shutting your browser down first.

This means that there’s a chance that the session cookie sent to you from Foo Bank is still around, and still valid. My javascript program can make requests to Foo Bank without even showing you a window (yes, they can do that, this is the foundation of AJAX technologies in fact), and determine whether you’re still considered logged in.

Lo and behold, you’re session cookie is still there, and Foo Bank hasn’t logged you out for inactivity. My javascript program can now make requests to Foo Bank using your session, doing whatever I programmed it to do (such as transfer a million dollars to my offshore bank account). I don’t even need my program to access your cookie, because the browser will send it for me automatically.

One of the particularly sinister aspects of this type of attack is that it looks so much like what the application is supposed to be doing, making it particularly difficult for Foo Bank to determine that you didn’t make the request, and for you to prove to Foo Bank that you didn’t make the request. The security term for this is non-repudiation, and CSRF compromises it in a big way.

What to Do

So what can be done about CSRF? One technique is to use “leashes” on a session, tying a session to a particular IP address, or a particular domain. This is an unsatisfying solution, because anyone who’s IP address changes frequently would be forced to re-authenticate when the address does change. Most home users are dynamically assigned IP addresses by the ISP using the DHCP protocol.

Corporate users, on the other hand, are frequently behind a firewall that performs NAT, or network address translation, making it appear that the entire corporate network is really just a few (sometimes only a single) IP address. So this leashing by IP address is unsatisfactory to both ends of the spectrum.

Another approach might be to require something like Captcha, and requiring the user to enter some form of input that allows us to determine if the request is coming from a machine or a person. This is probably a generally useful technique, although it would need to be restricted to interactions where you’re content to exclude machines as one side of the conversation. What do I mean by that?

Well, SOAP, a widely used protocol for Web Services, uses HTTP as a transport mechanism, and since both sides of that conversation are machines, we couldn’t use this technique for all HTTP requests if we want to use SOAP as well. If we restrict ourselves to securing only conversations where we expect one side to be a person, we might be okay.

It’d also be pretty annoying to users if every time they wanted to send information to a web server, they had to enter a Captcha string or the equivalent, so it would be important to use such a technique judiciously, perhaps only at review and check out.

The mechanics of any a particular technique used to address a CSRF vulnerability will therefore depend on the nature of the application you’re building, on an assessment of the risks involved, and on the customer’s tolerance for the contemplated solution. As with everything else related to computer security, it’s the same old continuum: easy to use on one end, secure on the other; you have to pick your point on the line based on an assessment of, and your tolerance of, the risks involved.

Jan

28

NRO’s Bird is Falling Down

January 28, 2008 | Comments Off on NRO’s Bird is Falling Down

I’ve seen the story of a US spy satellite currently in orbit which has “lost power and propulsion” and is set to come crashing down to Earth in the near future.  Some sources are reporting that it’s likely a photo reconnaissance satellite. Both the articles I read mentioned that there’s no way to control the bird now, that we don’t know where it’s coming down, and “it may contain hazardous substances” (as if falling from the sky wasn’t hazardous enough).

The thing I keep wondering is, if it’s so highly classified that we can’t tell you what type of satellite it is, or why and when it lost power, then who’s going to go and make sure nobody looks at it when it crashes (by picking up the pieces, maybe?), and when are they going to know where they’re going to?

Jan

25

IP Addresses as Personal Data

January 25, 2008 | Comments Off on IP Addresses as Personal Data

There’s an interesting article over at the Washington Post, found via Slashdot, in which we find that the EU is proposing that IP addresses be treated as personal data.

Scharr [Germany’s data protection commissioner] told a European Parliament hearing on online data protection that when someone is identified by an IP, or Internet protocol, address, “then it has to be regarded as personal data.”

I’ve long been a fan of the way the Europe treats personal information. Here in the US, it seems that any information a business collects about me is the property of the business. This includes things like my address, my birthday, my phone numbers, etc.

In Europe, personal information is treated as the property of the person, rather than the business, and the restrictions on what can be done with the information, and how it must be protected are rather more stringent.

It’s going to be a real challenge to treat IP addresses in this category. For one thing, as the article points out, these addresses can (and do) change when addresses are dynamically assigned via DHCP, rather than statically bound to a person.

It’s also going to be a real change of business practices for anyone using IP addresses to track purchases, or otherwise snoop on an internet user. What, for instance, will this mean for your average web site, who’s web server logs are full of these IP addresses, recording where requests came from and what was requested? How will we balance the right of the individual or business providing a web site to manage their services, with the rights of the EU individual to have their IP address secured as personal information?

It’s too soon to see what this means yet, but on the face of it, it looks like the stated goal of the EU is going to be technologically very difficult to achieve.

« go back — keep looking »

Blogroll

WP Themes