Recently in Security Category

Summer is here and with it are a variety of hacker conferences. We’ve got Defcon, Black Hat, and my favorite The Last HOPE (Hackers on Planet Earth, run by 2600).

Defcon is the longest running of the conferences, having been in Vegas since 1993, and having long been an interesting mix of the Hacker community and Law Enforcement. It’s three days of intense learning, hacking contests, games, all sorts of hacking related stuff, and that’s just the advertised events. I’ve heard a lot of stories of people going to Def Con and seeing things like cell-phone scanning going on behind closed doors. And it’s only $120 for the conference. Cheap as shit. I’m going to have to try to go next year.

Black Hat bills itself at “The World’s Premiere Techincal Security Conference”, and I’ll be honest there are some pretty intense sessions. Like the FasTrak system I discussed last week. My big problem with Black Hat is that it’s gotten to be too damn commercial, or maybe it always sort of was. It costs a few thousand to go, and that’s before Vegas hotel rates. Plus, they actually kicked out reporters for allegedly hacking. At a hacking conference. This would never happen at a real hackers conference. Might as well go to RSA, if you’re looking for such a watered down hacker environment.

Which brings me to HOPE. I talked about The Last HOPE a while back, expressing my dismay at possibly missing the last HOPE conference ever. Luckily, the owners of the Hotel Pennsylvania have been convinced not to raze the hotel, and The Next HOPE has been scheduled for 2010. My only complaint is that they didn’t make the obvious Star Wars joke.

Even better though, is that 2600 has made the audio of all the talks from The Last HOPE available for free download. I’m working my way through them, all 2.4 GiB (my ISP is going to be so pissed). But you can easily just pick and choose. When the video comes available, I’ll have to buy some of my favorite sessions.

This is why I love HOPE and Def Con. They’re more open than anything else, they exist to share knowledge, and they try to do it at as low a cost as possible. They’re about teaching and they’re about knowledge. I encourage everyone to download the talks from The Last HOPE. You’re bound to learn something, and that’s ultimately the whole point.

        <p>The <a href="http://www.blackhat.com/">Blackhat</a> conference was running this week, and a large number of interesting security issues were raised (even if <a href="http://www.fiercecio.com/story/black-hat-presentation-apple-cancelled-last-minute/2008-08-05">Apple wouldn&#8217;t let their devs talk</a>), but one that I found interesting was the discussion of the FasTrak system. FasTrak is a automated Toll paying system used California&#8217;s large cities that have toll booths on their major motorways. Researcher <a href="http://www.root.org/~nate/">Nate Lawson of Root Labs</a> discovered that the FastTrak, which I suspect is very similar to New York City&#8217;s FastPass system, uses no Authentication, and simply replies with it&#8217;s RFID signal to anyone who scan it.</p>

Anyone who’s read Cory Doctorow’s Little Brother will find this familiar. Especially when matched with the next step. Unauthenticated over-the-air upgrading. That’s right, you can change the value of the chip without actually handling the chip. Awesome.

So, what’s this mean? Well, the unauthenticated read allows anyone with a reasonably powerful RFID reader to track anyone with a FasTrak in their car from any location. In Little Brother, the Department of Homeland Security (DHS) uses this system to track people all over the streets of San Francisco. And as bad as it would be for the Government to do something that broad, this system allows anyone who wants to track individual vehicles easily throughout California.

And the unauthenticated update? This makes it trivial to travel for free, as you can easily steal a valid FasTrak code, and re-flash your own FasTrak and travel on someone elses dime. This allows people who have interest in masking their movements to change their FasTrak codes frequently, so that they can not be tracked via FasTrak. Really want to create mayhem? Do what Marcus and the other Little Brothers did, and start just randomly flashing people’s FasTraks.

RFID is an inherently untrusted protocol. It gladly responds to anyone who asks for it’s code, and by default it doesn’t have any method to authenticate even for writes. Over-the-air writes are a dangerous idea in the first place. If someone really needs to recode their pass, they should have no problem taking it somewhere to be safely re-written over a wire, preferably using encryption to verify that the new code was authorized. Over-the-air reads, a fantastically useful thing, should require a strong challenge. This is much harder, though it could be implemented using something like a simple counter and encryption so that the signal is encrypted and can only be decrypted by the software with the other half of the key. It’s harder, and it’s more expensive, but it’s far far safer.

In addition to FasTrak falling apart, the Mifare cards created by NXP Semiconductors, and used for London’s transit among many other systems, has been found to have similar exploits. Bruce Schneier already has a fantastic write up on this on his blog, particularly NXP’s attempt to suppress the researchers who uncovered the flaws.

Security is hard, really hard. It constantly needs to be fixed and updated, but there are certain things that should be so obviously wrong, like RFID update over-the-air, that I can’t believe people base entire businesses on obviously flawed systems. Still, consumers have a right to know, and researchers have a right to research. Plus, by the time the researchers have figured it out and published, there is always a good chance that someone else has already figured it out to, and has been exploiting it for their own gain.

There has been a debate ensuing on Debian Planet since last week about Firefox 3’s new behavior for what it views as invalid SSL certificates. Having upgraded to Ubuntu 8.04 back in February, I’ve been using Firefox 3 since it hit rc1, so I can definitely relate to the problems that people are having. I completely agree with the sentiment of those who view the new behavior as a necessary evil. Unsigned SSL Certificates are a potentially huge security risk. Unfortunately, they’re common as spit and most people just click right past them because they’re getting in the way of the user doing what they want.

Firefox’s new approach is pretty heavy handed. So much so, in fact, that it appears you can’t work around it without some non-trivial changes to Gekco. This probably wouldn’t be so bad, except that most users have absolutely no idea what to do when confronted with this:

I know that my wife didn’t when the wireless network of the hotel we stayed at following our wedding redirected us to a site with an Invalid SSL Certificate. Hell, it threw me for a loop the first time I saw it. Other people have, of course, reported similar experiences.

In reality, I blame the insane cost of SSL Certificates. Partially, this is due to the standard for SSL security in web browsers is an all-or-nothing deal. You’re either signed by a Certificate Authority (CA) in the browsers certificate file, or you’re not. Because of this, CA’s have no incentive to change the way that they offer Certificates, you pay through the nose for a ‘valid’ one, or your don’t and use a self-signed ‘invalid’ one. The absolute cheapest you can get a Web-enabled certificate from Thawte, is $150/year, and in that case they only identify the domain, not the user. Want your company identified for better security? That’ll be an extra $100/year. Not that most users will notice. Want the fancy Green Address bar (at least in newer browsers)? Be prepared to spend a whopping $800/year.

Actually, I fully support this sort of pricing model (though I think that $150/year for a domain-only SSL certificate is ridiculous), but we need better mechanisms to communicate how much the key should be trusted. The Extended Validation Certificate (EV) is a huge step forward in this, but it’s still not very fine-grained, especially when many sites who need, or require like Microsoft Office SharePoint Server, encryption simply can’t justify that sort of expenditure for a signed SSL certificate.

Admittedly, organizations can create their own CA’s for internal use, and sign certificates all they want. This becomes impractical at some point, however, because you need to make sure that every user in your organization has the CA certificate installed. Washington State University has a CA certificate, that I suspect is installed in almost every departmental computer on campus, but most organizations simply don’t use it. This is likely due, in part, to the number of off-campus users, and the freedom which we provide users to bring their own hardware. My Eee PC spends quite a bit of time on the WSU network, but I don’t have the WSU CA certificate. Still, I would prefer that a lot of these self-signed sites were using the WSU certificate, as then I could install that cert and have them just work. As it stands, I have no reason to really even consider that course of action.

What we really need, is for the web to be tied into a true Web of Trust. I choose the Root CAs I want to honor, but signing their key with my own, and I can assign trust to other user’s signatures, so that I can opt to trust them simply because someone I trust trusts them. Since most Trust applications allow you to specify differing levels of trust, this is practically built into the encryption scheme. And I can explicitly set my trust on the Firefox key, so that I accept keys that Firefox trusts, and amazingly, my situation doesn’t really change much.

Of course, the above paragraph is a pipe-dream. The majority of encryption software is too difficult for the average user to use, and most users simply don’t care to learn. But as I’m a huge advocate for large-scale public-key encryption, I’m going to keep dreaming. In the meantime, we need a trusted Root CA who sells discounted certificates so that non-commercial entities who want (or need, which isn’t always the same thing), can have valid one’s without inconveniencing their users significantly.

There is the other side of this, that perhaps Firefox is trying to annoy users, to force web developers to do what they feel is right. Microsoft did the same thing with the UAC in Vista, after all. However, if this is the case, Mozilla has made an enormous mistake. For Windows Vista, redesigning the application just a little bit, can get rid of those annoying UAC boxes, and actually result in a net-increase in application security. Requiring signed certificates makes the web more secure, without a doubt, but the cost involved for many organizations seems prohibitive, especially for Open Source projects that feel that they’re doing their users a favor by encrypting logins to web-based systems.

I’m glad the Mozilla is trying to do something, but I agree with those who feel that they’ve gone too far. I’d be happy if, on the first alert screen, there was a button that allowed me to trivially accept the key on a temporary basis, while still requiring the full process to add the key permanently. And Ideally, I wouldn’t have to click on the “Or you can add an exception…” link to see the actualy options.

Michael Timothy Arnold, an US Citizen who was recently arrested when a search of his laptop as he reentered the country from the Philippines turned up several images of child pornography. He was able to get the lower courts to honor a motion to suppress, arguing that the search was unlawful. Part of his argument was that the in depth search of his laptop was triggered by the discovery of legal pornography in a cursory search of the system. The existence of any pornography on a digital system should not serve as probably cause for an in-depth search, but the laws regarding border searches are somewhat messy.

In a 9th Circuit Court of Appeals judgement on the case, the court accounts on several cases dating from as far back as the early 1970s which account for the powers that Border Control Agents have to conduct searches. In the 1973 case United States v. Ramsey (431 U.S. 606, 616), it was decided that “searches made at the border… are reasonable simply by virtue of the fact that they occur at the border….” This particular interpretation of the Law does bother me at a pretty fundamental level, but it is the accepted case law, and as such, is important context for the analysis of the this decision. At least the Courts have acknowledged, in 1982’s United States v. Ross (456 U.S. 798, 823), that you have the same expectation of privacy at the borders whether your luggage is a handkerchief on a stick or a locked attaché case.

In fact, Case Law to date has basically held that Border Control Agents have rights to intrude “beyond the body’s surface,” without probable cause. However, the Supreme Court has left open the possibility that “some searches of property are so destructive that they require particularized suspicion.” And such lies the basis of Mr. Arnold’s defense.

His claim, is that the laptop and its contents are more analogous to the contents of the owner’s home (due to the amount of data it can store), or the users own brain (since it holds ideas, conversations, and data regarding habits). The home claim is completely false, in my opinion. Yes, the laptop can store an amazing amount of data, but it is clearly a portable closed container, more analogous to the locked attaché case mentioned above than a home. In my non-legal opinion, is that under current law, the Border Agents were completely legitimized in the initial search. Whether or not the existence of the easily found pornographic images should have triggered a full search is another issue, but the search was, under current interpretations of the law completely justified. The 9th Circuit agrees.

As a response, the Electronic Frontier Foundation (EFF) with the Association of Corporate Travel Executives (ACTE) filed a brief of amice curiae with the 9th Circuit, trying to get Mr. Arnold another appellate hearing. Given the nature of the case, one of privacy at border crossings, it makes perfect sense that these associations are filing as amice. The basis of the brief is that the searching of the laptop, by definition, is a direct search into personal information, which is different than flipping through the pages of a diary which is an ‘incidental’ revelation of personal information. They base their argument against viewing a laptop as a traditional closed container, against the fact that the device cannot be used to smuggle physical contraband into the country.

However, digital images of child pornography are still illegal. If you were to carry a stash of printed documents detailing a terrorist plot, that would be reason for detainment and serviceable evidence in court. The data on the laptop is little different than the data on paper, it is merely a different representation of such data. And while such searches may require reasonable suspicion under the 4th Amendment, more than three decades of decisions hold that the 4th Amendment simply doesn’t apply to Border Searches.

The Digital Age has changed things. Most people are not aware of their digital footprint, the claims in Argument B1 of the amicus brief only go to show how little people think of their privacy in the digital age. Most people only think of the ease at which data can be copied when they’re creating those copies themselves, not when considering how easily someone in control of a system for even a short period of time can copy all the data which is contained within it. I agree with the EFF’s claim that copying that data does constitute a ‘seizure’, because while the government has not necessarily denied me access to it, they have taken a copy that I did not expressly authorize them to take.

Just because a laptop can contain an enormous amount of personal data, does not make it inherently unique from other containers. I could fill a shipping crate with personal, confidential information, and I would not have any reasonable expectation that customs wouldn’t go through it. What needs to be analyzed to determine the legality of the search is the inherent nature of the container, and not of the it’s potential contents. A laptop does not, by strict definition, contain large volumes of personal information. It usually does, but it doesn’t always. A notebook that I always carry with me can contain a lot of information that I may feel is somewhat private, but it is not special or unique from my Eee PC. The best argument that the EFF uses in the entire brief is that the existence of data on the laptop only proves that the machine was used for such activities, not that the person in question was responsible for that activity.

I agree with the EFFs goal here, I really, really do. I just think that claiming that 4th Amendment rights are being violated in a circumstance where the courts have long held that the 4th Amendment doesn’t apply is foolish. As long as the border search doctrine is held, as it relates to US Citizens at least, there is no method to correct this problem. We should be lobbying Congress, not the Courts, to ensure that measures are taken to ensure that the 4th Amendment is made to apply, at least in some degree, to searches of US Citizens.

Acknowledging that, under the current rule of law, things are unlikely to improve, Bruce Schneier has offered his advice, that we need to be more proactive in ensuring that we don’t take confidential or incriminating data across the borders. This can be accomplished several ways. By making sure that the system is clean before you cross the border, and by transferring anything you don’t want taken over a secure link back into the country. For business, this is easy. Set up a VPN, and make available ‘travel’ laptops to people who need to travel, which contains only the software they require to do their work. Any data that is required for work is taken via the VPN, and secure erasure tools are used to remove the data from the laptop. For the personal user, similar actions can be taken, by taking advantage of services that allow the storage of data (and the secure retrieval) on the Internet.

The law needs to change. It is highly unlikely that the 9th Circuit Court is going to overturn 30 years of case law, so we need to be approaching this battle from a different angle. I can see no reason myself why the 4th Amendment shouldn’t apply to US Citizens entering the country. Once I’ve proved my citizenship, I should be afforded all the rights that that citizenship guarantees me. Unfortunately, until the law is changed, I don’t see that happening.

Hackers On Planet Earth, 2600 Magazine’s periodic Hacker conference is preparing for it’s final gathering. Luckily, this isn’t because 2600 doesn’t want to run the conference anymore, but rather the historic home of HOPE, New York’s Hotel Pennsylvania, was slated for demolition, to be replaced by an office high-rise. Luckily, the 89-year-old hotel still has some friends, who don’t intend to let the developers tear down this historic structure without a fight.

Though I’ve been to New York on multiple occasions, I’m not familiar with the Hotel Pennsylvania, so I can’t really make any comments about the significance of the place. However, it is distressing how often we tear down older buildings. If the Hotel truly has structural issues, that’s one thing, but it doesn’t sound like that is the case. Due to the potential destruction of the Hotel, 2600 has chosen to name this year’s HOPE as The Last HOPE, indicating that if the Hotel Pennsylvania is destroyed, any new conferences will not carry on that same name. That is, of course, if they can find another venue they can afford.

Hackers On Planet Earth is a conference aimed at the True Hackers, people for whom technology is a passion. People for whom the desire to dig deep into the guts of technology and figure out how it works. It’s this tendency to dig into the inner workings of systems that has helped get the word so vilified, particularly as companies have tried to commoditize their technology. Ultimately, though, it’s the Hackers who tend to drive technology to the next level, the people who push technology and develop new technologies just for the sake of the technology. Many of these are people who have become socially active, after years of persecution because of their misunderstood love of technology.

Not that some Hackers haven’t broken laws. Stolen information, trespassed in computer systems, and (inadvertently or otherwise) caused denials-of-service. However, the response has often been blown way out of proportion by a media, and a populace who doesn’t understand the technology that now pervades their lives. In this week’s TWiT, Randall Schwartz (author of O’Reilley’s Learning Perl, among others) comments that in the state of Oregon the law is written such that it’s basically illegal to use a Computer for anything. Of course the laws are intended to only be used against “bad” people, but that’s kind of distressing when one takes into account the average person’s desire to provide “bad” with the same definition as “different”.

HOPE this year has some really interesting sessions. Steven Levy, author of Hackers: Heroes of the Computer Revolution, is giving the Keynote. The nametags will have RFID tags, and giant screens will be present to indicate who is going where and with whom they’re socializing. Capture the Flag games, a Hackerspace Village, Segway Racing, and more. All of it promises to be an excellent time for those people who love to get their hands dirty on the guts of technology. Speakers will be covering topics from building an IDS, Botnets, Phishing, and a lot more.

I desperately want to go this year. I wanted to go last year, but it didn’t work out. This year, may well be my last chance. Had it not been for the wedding so recently, I’d be in a much better position financially to kip off to New York City for a few days, and attend. As it stands, I’m going to try to see what I can do to make this happen. With any luck, I’ll be seeing folks as HOPE.

Scott McPherson, CIO to Florida’s House of Representatives and former CIO of Florida’s Department of Corrections, has a new post on Computer World, where he addresses the continued need for data integration for law enforcement in this country. While I am generally against the comprising of privacy for gains in security, I believe that most of what Mr. McPherson is talking about are perfectly reasonable changes that we should be calling upon the government to finance, as they are our best chance at true security, and for the most part require virtually no sacrifices on our part.

To sell his point McPherson tells the story of Mohammad Atta, one of the 9/11 hijackers, and his run-ins with the law shortly before that infamous attack. Basically, he’d been cited, failed to appear in court, got a warrant issued in his name. got pulled over again, and because he was in the next county received another citation because the officer had no way to find out about the warrant which was filed in a neighboring county. If Atta had been pulled over in a neighboring state, I think we’d like the officer to know about outstanding warrants, but the next county? Certainly an arrest should have been made.

Had Atta been arrested, strong evidence of the plot may have been discovered that would have potentially allowed the entire plot to be foiled. Of course, further communication problems within the Intelligence Community (namely the CIA and the FBI) likely would have served as a further detriment to anything actually begin caught, but that is for another post, at another time.

So what would this require? A fairly basic, standardized architecture of services which would allow queries to be made by officers, even if they were in the field, which would return any relevant information. What does that require? A standard method of communication, which luckily the Department of Justice has created. And companies are already working on solutions in this space. ANalyze Soft did a presentation at Boise Code Camp this year about their project that is providing consitent data integration for the Idaho Dept. of Corrections. McPherson has wonderful things to say about Appriss’ JusticeXchange products, including how much it helped the Florida DoC track repeat offenders and probation violations. Using JusticeXChange, corrections officers can be notified if an absent parolee gets arrested across the state or across the county, and take action on the issue before the parolee ever sees a Judge.

Most people don’t commit crimes. We just don’t. But there is a lot of evidence to suggest that the people who do tend to commit more than one. Perhaps laws or policies will become necessary that limit how long infractions show up on criminal records like this, particularly as that information becomes more easily shared. However, the benefits to sharing this data are enormous, and we need to be funding these sorts of projects. Small towns don’t need riot gear, nearly as bad as they need good means to communicate crime data with other policing agencies across the nation.

Interesting, but more frightening, was the discussion on Hank Asher’s MATRIX system. Now, Hank Asher is a big name in the Data Mining industry, earning quite a fortune by examining personal information for patterns. He chose, in 1999, to turn this focus toward law enforcement, which is where MATRIX was born. MATRIX analyzed criminal and other governmental records (Licensing, etc) looking for ‘anomalous’ behaviors that could potentially be related to terrorist activity. Incidentally this is fairly similar to what Visa and the other Credit card providers do to try to find fraudulent activity on your credit card.

It is unclear whether or not MATRIX was tapped into commercial data, though it almost certainly could have been. The [ACLU did a lot of research on MATRIX[(http://www.aclu.org/Privacy/Privacy.cfm?ID=14240&c=130) trying to determine what information it was pulling it. Ultimately, these probes led to MATRIX losing it’s funding becuase of it’s similarities to DARPAs Total Information Awareness project, which sought to perform an amazing amount of discovery on hundreds of millions of Americans, the vast majority of which were not engaged in anything resembling terrorist activity. Congress ended up killing TIA, and MATRIX followed, due to it’s similarities in functions.

So, how do I feel about MATRIX, and technologies like it? In general, I think it almost certainly going to be too broad in scope. I don’t really need anything keeping track of my purchasing habits, correlating that data with my phone records and browsing habits. These are the reasons I’m generally against data mining. Visa isn’t watching my transaction history for my own good, I can always report fraud myself, they’re doing it so that they can better target their ads at people like me, or to sell advertising information to others. The sort of data mining the first part of this post was okay. It was tracking criminals engaged in criminal activity. It wasn’t even tracking criminals on everything else we’re doing.

Associating data across many, many databases can be a very, very powerful tool, but I disagree with Mr. McPherson that just because people are data mining means that we need to just suck it up and deal, as he basically says in the comments. Large scale data-mining like MATRIX had the possibility to prevent terrorist attacks, Asher demonstrated that after the fact with the 9/11 attackers. However, is the potential loss of liberty, and additional harassment that could come to honest American’s who happened to have fit the profile MATRIX was looking for worth it? I’m not convinced.

Per Enrico Zini, the Italian Tax Men and Women decided it would be a wonderful idea to post every single Italian’s reported Income, allegedly with their name and address as well! Apparently the site was having connection issues due to the flood of people trying to verify this after the Reuters story, but for the Italians, it looks like the best we can hope for is that the people trying to see it were just curious, and weren’t making any plans for that data.

At least that data has been taken down now, but the Minister of the department tried to somehow blame his decision on Americans. Admittedly, our government has made some pretty gross violations of personal privacy in the last seven years, and some of that was people clamoring for those liberties to be taken in the name of safety. Still, nothing that has happened in the US has been anywhere near this level of disclosure. In this country, it’s bad form to even ask what a person earns. Apparently, in Italy, for at least a few hours, you could simply go look. Companies must have loved dealing with the fallout from that.

Enrico’s comments about the plaintext CAPTCHA were pretty amusing. Typically, when trying to meet accessibility requirements, most people use an Audio CAPTCHA. I’m not even sure why they tried to obfuscate the text using extra <span> tags, since any screenreader would need to be able to read the text in order for it to be “accessible”, so clearly the text is already machine-readable. Periodic exercises in futility seem to be common in both IT and Government worldwide, I suppose.

The fact that the Italian Government would provide a functional road map to identity thieves, kidnappers, burglars, and other detestable portions of society is appalling. The closest thing to this level of purposeful information disclosure I can think of in the US is the Social Security Death Index, which at least has a reasonable reason behind it. It allows people to verify an SSN as not belonging to a dead person before allowing it’s use. Unfortunately, many lenders don’t even bother checking. At least they haven’t, perhaps that’s about to change.

We are forced to give a lot of personal information to the government and companies all the time. Had an Italian Corporation done this with their customer files, than that company would be facing enormous civil and likely governmental fines and other punishments. The Director who approved this disclosure deserves, at the very least, to lose his position in a disgraceful manner. He violated the trust of every single Italian, who implicitly trusted their government to treat their tax information confidentially. Hopefully, the Italian people take action.

Neosmart Technologies recently posted a diatribe about Windows Vista’s UAC subsystem, and how it basically forced them to rewrite their iReboot application. iReboot is an interesting Windows application which allows you to set the bootloader to load whichever OS you want on the next reboot, rather than waiting for the system to reboot, and quickly interrupting the bootloader to override it’s default selection. Thinking back to the days when I still dual-booted and the increasing popularity of the Intel-based Macintoshes, I can definitely see why this application has begun to catch on.

However, after reading this editorial by the author of iReboot, regarding the challenges he faced making the application work correctly on Vista. In short, he had to split the application into two parts: a System-level Service which does the modification of the Boot Loader, and a user-mode application which the user uses to send commands to the service. Seems pretty reasonable to me, and Unix systems have done this for decades. The Windows Kernel has always used a similar communication mechanism as well.

His basic argument is that the application must be installed as an Administrator, so therefore it should be able to start as an Administrator without any problems. However, Vista’s UAC wants to verify with the user every time the app starts up to verify that the application is allowed to do what it’s trying to do. Now, ignoring the annoyance factor of UAC, which Microsoft evidently did on purpose, it is perfectly reasonable for Vista to do this. What Mr. Al-Qudsi seems to completely fail to understand about Application Security, is that the Operating System decides who has what permissions on the user level not the application level. It is up to the user to, if necessary, elevate the permissions of an application to accomplish a system-level administration task.

If iReboot was allowed to elevate it’s privileges automatically, than any application ran by that user could elevate it’s privileges as well. In the comments, someone mentioned that perhaps a “RunElevated” registry key could be added, but that seems to me to be terribly prone to abuse. Some applications need to be installed with Admin Privileges but shouldn’t require those privileges to run, but with this registry key, ISVs could easily bypass the built-in security model in Vista.

Ultimately, it comes down to a security trade-off. By making the portion of the application which does elevated privelege attacks separate, it becomes easier to ensure that the application does what it is said to do, plus it is easier to test those code-paths and ensure proper behavior. It ensures that the inputs to the elevated code are better defined through an exposed interface, and encourages stronger design from the outset. It is a bit harder for the programmer, as their code now depends on Inter-Process Communication libraries and potential threading issues. At the end of the day, it reduces risk. it reduces the access of an unprivileged user to privileged code, it reduces the necessity for a user to have unnecessary access, and it better encapsulates the roles each part of the software plays.

As a former Administrator of a Windows 2003 and XP-based network, it was constantly frustrating for me to realize the number of tasks that my users struggled to complete because they simply had user permissions, how quite a few pieces of software would fail to run correctly due to the reduced permissions set of most users. In many ways, ISVs like Neosmart are responsible for the traditionally poor state of security on the Windows platform, due to their refusal to implement their software correctly, and their complaints regarding what they need to do for Vista compatibility.

Even in my current office, our helpdesk people struggle daily with legacy software that doesn’t work right (or at all) on Vista because the developers depended on bad behavior in XP and older OSes, and they’ve refused to correct their software in a timely manner. Vista isn’t going away. Windows 7 may be coming sooner than anyone expected, but it will build upon the Vista core, rather than stepping back to XP. There has been a paradigm shift at Microsoft, and this time it was definitely for the better. ISVs need to get on board, or prepare to made irrelevant.

Matt Dowd, a researcher with IBM’s Internet Security Systems group, recently discovered an interesting exploit in Adobe’s Flash plugin. The exploit is an interesting modification of a standard null-pointer attack, that reveals some pointed problems with the software design that frankly anyone could have made.

The basis of the exploit is simple. With a specially crafted SWF file, an attacker can execute arbitrary code and take control of a system. Due to the way the plugin is compiled, the same exploit works on both IE and Firefox, and even Windows Vista, which supports a compilation flag which would protect against this error, is susceptible to this bug.

The nature of the bug is the ability to rewrite a specially selected patch of memory, due to the failure of proper error checking. Unfortunately, this particular error checking failure is an incredibly common on in C programming. However, Mr Dowd’s analysis of the exploit, which includes plenty of assembly dumps and code interpretations to explain exactly what is going on in the ActionScript VM to allow this exploit to occur.

The nature of the exploit comes from setting the SceneCount variable in the DefineSceneAndFrameLabelData structure to a negative value. In truth, the structure definition (taken from the file format specification) does define this field as a 32-bit unsigned integer, exactly as it should be. However, the analysis shows that in the function that begins to process this structure, makes a ‘jump if greater than zero’ call, which assumes that the argument is a signed integer, so any integer 0x80000000 or greater would pass the check since the value is less than zero and should be invalid.

No too much later, a call to malloc is made, which fails due to the invalid data, however, there is never a check to make sure that the return address from malloc is correct. What his means, is that the user is now free to overwrite any block of memory greater than 0x80000000. Due to the nature of the VM, there were some restrictions on the data that could be overwritten. The target memory area has a huge number of functions that could lead to the plugin (and thus the browser) to crashing. In addition, the overwrite is based on a specific address formula, making the selection of the location to overwrite that much more difficult.

Despite all this, it was still possible to exploit in order to get control of the system. Luckily, Adobe has already patched this hole, but if you haven’t updated your Flash player in the last week, I suggest you do so post-haste.

Autocomplete. It’s a convenient evil common and popular among today’s browsers. The ability for Autocomplete to store certain bits of form data for return visits can be greatly convenient when filling out a variety of forms on the Internet today. However, in order for Autocomplete to work, the data in question must be saved somewhere, and that somewhere needs to be accessible in the browser. The claim on many is that on Mac OS X, Safari stores it’s autocomplete data in the Key Ring, which is saved to disk using strong encryption (though the keyring password is always in memory, and susceptible to certain types of DMA attacks). Internet Explorer and Firefox are not designed to integrate tightly with such software, so while they may obfuscate their representations of saved data, the data is still easy to recover.

And this is the inherent evil in Autocomplete. The feature can and will save immense amounts of personally identifiable information, from usernames and passwords, to addresses, credit card numbers, etc. Credit Cards are, of course, the issue where most people get up in arms about Autocomplete.

At some point, the browser developers decided that, if a field wasn’t supposed to utilize autocomplete, that it was the responsibility of web developers to tell them when fields were supposed to not utilize the Autocomplete feature. Some people argue that it is important that the web developer do this, for the instance where the user is inputting ‘protected’ information into a public terminal, which, unfortunately, rarely have autocomplete disabled. Frankly, if it’s a public terminal, you shouldn’t be putting any information you care about keeping confidential into it. What part of public do people fail to understand?

This issue was initially raised on SomethingAwful.com, where a forums user requested that the site stop offering to helpfully fill in his credit card information in the forums store. The near immediate response from the (non-technical) lead of the forums? That we’ll gladly disable our psychic ability to guess your credit card number. Even without fragmaster’s comment, an argument ensued about whether or not this was the responsibility of the site. My argument is that sites legal responsibility to protect user data extends only as far as the data-link used to connect the client to the server.

The very nature of the web demands this, as the very nature of the web is such that we, as web developers, have no control over the client that is being used to connect to our system. Attempts to limit which client browsers connectivity can be thwarted with relative ease. It is our responsibility to ensure that we’re not serving up confidential information to the wrong people; to ensure that the data in our possession is properly secured, and that the links on which that data travels are properly secured as well.

The PCI Data Security Standard, a Credit-Card industry think-tank, requires that stored cardholder data is to be secured in a reasonable fashion, utilizing encryption and access restrictions and implementing a data retention/disposal policy regarding cardholder data. The PCI DSS is not a law, however, so while not following it’s guidelines can cause the merchant providers to revoke ability to use their service, there are different sets of laws (and legal requirements) regarding data breaches.

The question becomes who is liable for the security of this data. I argue that it is the cardholder who is ultimately responsible for who they provide their card information to. Once that card information has been provided, it is the responsibility of the storing party to secure it. As a web-developer, I am not responsible for the security of your browser. I am responsible for securing my databases. I am responsible for protecting the SSL Certificate that we use to communicate. I am responsible for any content served to you from my servers. But, I am not responsible for your decision for ensuring that your browser or operating system are secure.

If an attacker is able to access your autocomplete files, then they can very likely implement another form of attack that completely circumvents the issue of autocomplete all together, be it by sniffing traffic for web forms with credit card numbers, or logging keystrokes, or any other mechanism. As a web developer, I can’t be held liable if your credit card number is intercepted due to malware installed on your machine, and in the case of Autocomplete, the browser is behaving in a malware-like manner. If it is any software-vendor’s responsibility to ensure the security of any data subject to autocomplete, it is the browser vendors responsibility.

Admittedly, Internet Explorer, Firefox, and Safari all three support an extension to the <input> and <form> tags, which can disable autocomplete. However, this is a non-standard extension, which causes failed validations, and frankly, disguises the risk inherent in autocomplete. A more standards-compliant mechanism to support this would be using Javascript to set the autocomplete variable to “false”, like the in following:

// Disables autocomplete on the Google search box
document.forms[0].q.autocomplete = "false";

Alternatively, register an “onfocus” event with the input field can accomplish the same thing. For browsers that don’t support the option, nothing happens, and for browsers that do, this is a standards-compliant means to disable autocomplete for the given field.

It’s a relatively easy thing to do, adding only a small amount of bandwidth to each pageload, on pages that aren’t accessed as frequently as many other pages. So, why do I feel it’s such a waste? Because it makes people feel that an inherently insecure feature is more safe than it really is. Plus, my responsibility to protect their data should extend no further than my ability to control their data extends. Users can choose to override this option, a users credit card number might be stolen by someone looking over their shoulder as they enter it in, someone could be watching the desktop through a VNC-like service.

This has not, to the best of my knowledge, been tested in court. Many organizations are going to cover their own asses by simply adding code to disable this, which may not be wholly unreasonable to do, though I’d suggest going the Javascript route, for compatibilities sake.

The question of who is responsible if a credit card is stolen from autocomplete data is a complicated one. Is it the Application Vendor? I feel that it obviously is not, since the autocomplete is a feature of the browser, not the application. Is it the browser vendor? Probably not, they do ask the user if they want autocomplete, though they do make it easy for the user to zip by and enable it without thinking too hard about it. So, who’s left? The person who owns the computer from which the compromised data was recovered from? If it’s a public terminal, whoever configured it should never have allowed autocomplete to be active. However, the person still expressed an implicit trust to the owner of the system when they put their credit card information into it. On a public terminal this is always dangerous. Using a computer owned by someone else always implies that you trust that person enough that they won’t misuse it.

Users need to be aware of the risks. Using autocomplete has the risk of revealing personal, confidential information. It is up to the user to ensure that they only entrust the data to people whom they feel are trustworthy. Once the seller has secured their database and provided encryption for all communication channels over which the card number will travel, then the merchant has done all that they can, and any autocomplete magic that they might attempt is doing nothing more than masking a real risk, or disabling a feature that some users might actually want.