April 04, 2007 | Comments: (0)
Wireless Security: How much is enough?
The first couple of wireless routers I set up for my home and office networks, several years ago, came wide open: that is, they were preset at the factory to a common SSID with broadcast enabled, no encryption, and no MAC authentication. The point was that they'd work out of the box for a non-technical user.
That might be fine if you want your neighbors and any passers-by to be able to use your Internet connection, as long as you have all the computers on your network secured, and you don't care about the legal consequences of others doing things on the Internet that could only be traced back to your router. It's not really fine, though, because the courts have not been kind to the owners of open wireless routers that have been used for illegal purposes, such as transmitting child pornography.
I initially set my own routers to use WEP encryption with a pre-shared pass phrase, which was the best they could do; later, after applying patches to the routers's firmware, I switched them to the more secure WPA encryption scheme with a pre-shared pass phrase, since by then WEP had been cracked. If I had a bigger network, I would have used 802.1x authentication instead of a pre-shared key.
Recently, Verizon upgraded my home wireless router to an Actiontec MI424WR. I was pleased to note that it came preconfigured to have some security: it came with WEP encryption turned on, and the preconfigured randomized SSID and WEP key printed on a label underneath the router. It also came pre-configured for medium firewall security.
Of course, I reconfigured the router to use my usual WPA encryption scheme with a pre-shared pass phrase. I also changed the supplied random SSID to my own SSID, so that computers I had already authorized to use my home network would still have access.
Should I be limiting access to specific MAC addresses? Should I turn off SSID broadcasting? Are there other measures that make practical sense? Or have I already done enough to secure my wireless networks?
Posted by Martin Heller on April 4, 2007 06:00 AM
March 26, 2007 | Comments: (0)
Dave Methvin, Rob Cheng and I founded PC Pitstop in 1999. From the beginning, it was a classic Windows DNA site: we wove together an ActiveX control, quite a bit of client-side JavaScript, ASP server code also written in JavaScript, and a SQL Server database. The idea was to quickly and automatically diagnose most common PC ailments.
If I remember correctly, we started out supporting Windows 95 and Windows 98, then added Windows NT and Windows 2000. Over the years we kept updating the site to do more and to support new systems as they were released. I stopped working on it full time after the dot-com bust and terrorist attacks of 2001, which together ruined the market for banner advertising. I continued to consult for the site on and off, and became more active again last summer.
Because PC Pitstop tests tens of thousands of computers every month, we have a pretty good idea about industry trends. We try to anticipate them a little when we think they'll need new code for proper support, but we also find out rather quickly when there are breaking changes from new hardware or new systems.
Last week I finally bit the bullet and started trying to fix the tests that didn't work properly on Windows Vista. There were 8 problems that we were able to identify when people came to the site with Internet Explorer 7 in the default Protected Mode on Windows Vista:
- The CPU Load was not tested
- Running Programs only listed one: IE
- All outgoing pings were lost
- Disk fragmentation was not tested on C:
- Disk speed was not tested on C:
- No CD or DVD drives were detected
- Could not obtain monitor information
- Got incorrect results for the size of the junk files
I tracked down the C++ code in the ActiveX control that does each of these tests, and realized that some of the failing tests were trying to do things that require Administrator privilege on Windows Vista, but that others were doing things that only require normal privilege. IE didn't even have normal privilege, however, because it was running in Protected Mode, which flags itself as a low integrity process.
The whole point of Protected Mode is that sites can't use it to install malware without your permission: if they try, you'll get an elevation prompt that you'll find it hard to ignore. The whole point of PC Pitstop is that we're the good guys, trying to detect suboptimal system settings, low performance, and malware that is already on your computer.
I did three experiments. I verified that all 8 issues happen in Protected Mode. I determined that three problems go away, two completely and one partially, with IE's Protected Mode off. And finally I determined that all tests run correctly when IE is run with Administrator privilege.
I looked at alternative ways to execute the tests that might work with Protected Mode enabled, because I really wanted the site to work that way. I found a way to detect CD and DVD drives using WMI, but the information returned isn't as complete as we get by using the low-level SCSI and ASPI interfaces, so I think that's just a back-up plan. I found a simple way to fix the disk speed problem that I think will be fine on most systems, which involves putting the test file into the temporary directory if the temp directory is on the drive being tested.
There were so many issues that I couldn't fix, however, that I came to a sad realization: PC Pitstop will only run properly on Windows Vista if the browser has Administrative privilege. Like the janitor in your building, we can't clean up after you unless we have the keys to the office.
Posted by Martin Heller on March 26, 2007 06:00 AM
March 09, 2007 | Comments: (0)
Vista User Account Control and the Linux Superuser
I have found most of the "Get a Mac" ads on television irritating and misleading, but two of the most recent ones were spot on: the one where the PC, played by the author and comedian John Hodgman, appears in a surgical gown, and the one where he is accompanied by a security guard in shades.
The surgical gown is of course a take-off on the need to add RAM and a graphics card to old, cheap PCs if you want them to run Windows Vista. It's true, at least for old, cheap PCs: Vista won't really run decently with less than 512 MB of RAM, and needs 1 GB of RAM and a GPU to display the Aero interface. I'll go into Aero another time: today I want to talk about security.
The security guard in shades who questions every decision is an apt metaphor for Windows Vista User Account Control, and I think it's quite funny. An even funnier metaphor for Windows Vista is the "new wife" of this blog post by "Chalain." The way that User Account Control dims the rest of the screen to get your attention for a permission question (see the image at left) is truly weird and drastic; I have to assume that the decision to do this was based on Microsoft's user experience laboratory research.
But let's put it into context. As generally recommended, I run as a standard user on my Linux installations, and only invoke administrative privilege, become the superuser, and take root when necessary. At first, I was annoyed that I needed to supply the administrator password to change the screen resolution on Linux, because I was used to making this sort of global system change at will on my Windows installations. Eventually, I got used to elevating my privilege only at need: it's the right thing to do if you care about security.
So, when I was researching the way to determine the shadow storage size on Windows Vista for my February 23rd entry, I wasn't too surprised when I got an error message about needing to elevate my privilege after I tried to run vssadmin from a standard command shell. What a Linux system would have done right there would be to ask me for the administrator password. What I would have done to avoid the question on a Linux system would be to use the su or sudo command to elevate privilege before running the system command that needed the privilege.
What was the first thing I tried in my attempt to create an elevated privilege command shell on Windows Vista? su, of course. It didn't work. I eventually discovered the two methods I told you about on the 23rd.
Now I wonder, why isn't there an su command on Windows Vista? What would it take to write one? Has somebody already done it?
I know there was an su command in the old Hamilton C Shell, but it was written for Windows NT conventions. I would guess that it wouldn't be very useful for Windows Vista, unless Nicki Hamilton has updated it in the last year.
Do I have to write an su command for Windows Vista myself? I am the only one who thinks it would be a good thing to have?
Posted by Martin Heller on March 9, 2007 06:00 AM
January 08, 2007 | Comments: (0)
Subverting AJAX: Prototype Highjacking
One of the most interesting parts of the JavaScript language is the prototype property, which underpins the language's object-oriented inheritance. In JavaScript, functions are a specialized kind of object; every function (and indeed every JavaScript object) has a prototype property that refers to a predefined prototype object, which comes into play when the function is used as a constructor with the new operator.
Prototypes are not limited to user-defined classes. Even built-in JavaScript classes have prototype properties, and you can assign values to them.
This is extremely powerful. It is also extremely dangerous. Using prototyping, an attacker can hijack standard functions in a way that breaks security without causing any error message. Browsers try to prohibit this by dropping the prototype property for some of their internal functions, but there's a way around that protection.
At the 23rd Chaos Communication Congress, held at the end of December in Berlin, Stefano Di Paola and Giorgio Fedon gave a talk called Subverting AJAX (PDF), in which they explained exactly how to do this. Coupled with a cross-site scripting attack and a cleverly crafted phishing email, such an attack could turn an AJAX application into a keylogger with a man-in-the-middle attack strategy. Consider the following diagram, from Di Paola and Fedon's paper:
What's happening here is that the attacker has hijacked the browser's XMLHttpRequest object, and wrapped it with his own keylogging logic. How hard is this to do? Not very hard at all. The key code would be:
var xmlreqc=XMLHttpRequest;
XMLHttpRequest = function() {
this.xml = new xmlreqc();
return this;
}
This is fairly subtle, but it's devastating. XMLHttpRequest has been redefined to be a wrapper for itself. Any time a new instance of XMLHttpRequest is intended to be created in subsequent code, the wrapper method will be created instead. It now doesn't matter that the original XMLHttpRequest function didn't have a prototype property: the new one does.
Once the attacker has prototypes at his disposal, he can redefine key methods. For example, he can redefine the send method to sniff and/or modify the content, as shown in the figure above and the following code:
XMLHttpRequest.prototype.send = function (pay){
// Hijacked .send
sniff("Hijacked: "+pay); //log the original message
pay=HijackRequest(pay); //change the message
return this.xml.send(pay); //send it on
}
The classic response to this kind of exploit would be "disable JavaScript in your browser." Unfortunately, AJAX applications inherently require JavaScript, and most people really like the improved user experience of AJAX applications compared to conventional Web applications.
I don't have a good solution, other than constant vigilance on the part of every author and user of AJAX applications. We're back to "Don't talk to strangers," kids. In the words of the original CERT bulletin about cross-site scripting,
"users can gain some protection by being selective about how they initially visit a Web site. Typing addresses directly into the browser (or using securely stored local bookmarks) is likely to be the safest way of connecting to a site."
(Thanks and a tip of the hat to Roy M. Silvernail, who alerted me to this exploit.)
Posted by Martin Heller on January 8, 2007 10:24 AM
TOP STORIES
ADDITIONAL RESOURCES
- Remote Access: Maintain Security and Decrease the Burden on IT
- Beyond AntiVirus: Symantec Endpoint Protection
- What Every Enterprise Needs to Know About VDI
- Monitor the core and troubleshoot the access layer
- Disaster Recovery in Minutes
- Protecting Microsoft(R) Applications
