Entries Tagged "vulnerabilities"

Page 43 of 50

Remote-Control Airplane Software

Does anyone other than me see a problem with this?

Some 30 European businesses and research institutes are working to create software that would make it possible from a distance to regain control of an aircraft from hijackers, according to the German news magazine.

The system “which could only be controlled from the ground would conduct the aircraft posing a problem to the nearest airport whether it liked it or not,” according to extracts from next Monday’s Der Spiegel released Saturday.

“A hijacker would have no chance of reaching his goal,” it said.

Unless his goal were, um, hijacking the aircraft.

It seems to me that by designing remote-control software for airplanes, you open the possibility for someone to hijack the plane without even being on board. Sure, there are going to be computer-security controls protecting this thing, but we all know how well that sort of thing has worked in the past.

The system would be designed in such a way that even a computer hacker on board could not get round it.

But what about computer hackers on the ground?

I’m not saying this is a bad idea; it might be a good idea. But this security countermeasure opens up an entirely new vulnerability, and I hope that someone is studying that new vulnerability.

Posted on July 28, 2006 at 2:09 PM • View Comments

Hacked MySpace Server Infects a Million Computers with Malware

According to The Washington Post:

An online banner advertisement that ran on MySpace.com and other sites over the past week used a Windows security flaw to infect more than a million users with spyware when people merely browsed the sites with unpatched versions of Windows….

Clever attack.

EDITED TO ADD (7/27): It wasn’t MySpace that was hacked, but a server belonging to the third-party advertising service that MySpace uses. The ad probably appeared on other websites as well, but MySpace seems to have been the biggest one.

EDITED TO ADD (8/5): Ed Felten comments.

Posted on July 24, 2006 at 6:46 AM • View Comments

WiFi Driver Attack

In this attack, you can seize control of someone’s computer using his WiFi interface, even if he’s not connected to a network.

The two researchers used an open-source 802.11 hacking tool called LORCON (Loss of Radio Connectivity) to throw an extremely large number of wireless packets at different wireless cards. Hackers use this technique, called fuzzing, to see if they can cause programs to fail, or perhaps even run unauthorized software when they are bombarded with unexpected data.

Using tools like LORCON, Maynor and Ellch were able to discover many examples of wireless device driver flaws, including one that allowed them to take over a laptop by exploiting a bug in an 802.11 wireless driver. They also examined other networking technologies including Bluetooth, Ev-Do (EVolution-Data Only), and HSDPA (High Speed Downlink Packet Access).

The two researchers declined to disclose the specific details of their attack before the August 2 presentation, but they described it in dramatic terms.

“This would be the digital equivalent of a drive-by shooting,” said Maynor. An attacker could exploit this flaw by simply sitting in a public space and waiting for the right type of machine to come into range.

The victim would not even need to connect to a network for the attack to work.

No details yet. The researchers are presenting their results at BlackHat on August 2.

Posted on July 6, 2006 at 1:52 PM • View Comments

Brennan Center Report on Security of Voting Systems

I have been participating in the Brennan Center’s Task Force on Voting Security. Last week we released a report on the security of voting systems.

From the Executive Summary:

In 2005, the Brennan Center convened a Task Force of internationally renowned government, academic, and private-sector scientists, voting machine experts and security professionals to conduct the nation’s first systematic analysis of security vulnerabilities in the three most commonly purchased electronic voting systems. The Task Force spent more than a year conducting its analysis and drafting this report. During this time, the methodology, analysis, and text were extensively peer reviewed by the National Institute of Standards and Technology (“NIST”).

[…]

The Task Force examined security threats to the technologies used in Direct Recording Electronic voting systems (“DREs”), DREs with a voter verified auditable paper trail (“DREs w/ VVPT”) and Precinct Count Optical Scan (“PCOS”) systems. The analysis assumes that appropriate physical security and accounting procedures are all in place.

[…]

Three fundamental points emerge from the threat analysis in the Security Report:

  • All three voting systems have significant security and reliability vulnerabilities, which pose a real danger to the integrity of national, state, and local elections.
  • The most troubling vulnerabilities of each system can be substantially remedied if proper countermeasures are implemented at the state and local level.
  • Few jurisdictions have implemented any of the key countermeasures that could make the least difficult attacks against voting systems much more difficult to execute successfully.

[…]

There are a number of steps that jurisdictions can take to address the vulnerabilities identified in the Security Report and make their voting systems significantly more secure. We recommend adoption of the following security measures:

  1. Conduct automatic routine audits comparing voter verified paper records to the electronic record following every election. A voter verified paper record accompanied by a solid automatic routine audit of those records can go a long way toward making the least difficult attacks much more difficult.
  2. Perform “parallel testing” (selection of voting machines at random and testing them as realistically as possible on Election Day.) For paperless DREs, in particular, parallel testing will help jurisdictions detect software-based attacks, as well as subtle software bugs that may not be discovered during inspection and other testing.
  3. Ban use of voting machines with wireless components. All three voting systems are more vulnerable to attack if they have wireless components.
  4. Use a transparent and random selection process for all auditing procedures. For any auditing to be effective (and to ensure that the public is confident in
    such procedures), jurisdictions must develop and implement transparent and random selection procedures.

  5. Ensure decentralized programming and voting system administration. Where a single entity, such as a vendor or state or national consultant, performs key tasks for multiple jurisdictions, attacks against statewide elections become easier.
  6. Institute clear and effective procedures for addressing evidence of fraud or error. Both automatic routine audits and parallel testing are of questionable security value without effective procedures for action where evidence of machine malfunction and/or fraud is discovered. Detection of fraud without an appropriate response will not prevent attacks from succeeding.

    The report is long, but I think it’s worth reading. If you’re short on time, though, at least read the Executive Summary.

    The report has generated some press. Unfortunately, the news articles recycle some of the lame points that Diebold continues to make in the face of this kind of analysis:

    Voting machine vendors have dismissed many of the concerns, saying they are theoretical and do not reflect the real-life experience of running elections, such as how machines are kept in a secure environment.

    “It just isn’t the piece of equipment,” said David Bear, a spokesman for Diebold Election Systems, one of the country’s largest vendors. “It’s all the elements of an election environment that make for a secure election.”

    “This report is based on speculation rather than an examination of the record. To date, voting systems have not been successfully attacked in a live election,” said Bob Cohen, a spokesman for the Election Technology Council, a voting machine vendors’ trade group. “The purported vulnerabilities presented in this study, while interesting in theory, would be extremely difficult to exploit.”

    I wish The Washington Post found someone to point out that there have been many, many irregularities with electronic voting machines over the years, and the lack of convincing evidence of fraud is exactly the problem with their no-audit-possible systems. Or that the “it’s all theoretical” argument is the same on that software vendors used to use to discredit security vulnerabilities before the full-disclosure movement forced them to admit that their software had problems.

    Posted on July 5, 2006 at 6:12 AM • View Comments

    Getting a Personal Unlock Code for Your O2 Cell Phone

    O2 is a UK cell phone network. The company gives you the option of setting up a PIN on your phone. The idea is that if someone steals your phone, they can’t make calls. If they type the PIN incorrectly three times, the phone is blocked. To deal with the problems of phone owners mistyping their PIN—or forgetting it—they can contact O2 and get a Personal Unlock Code (PUK). Presumably, the operator goes through some authentication steps to ensure that the person calling is actually the legitimate owner of the phone.

    So far, so good.

    But O2 has decided to automate the PUK process. Now anyone on the Internet can visit this website, type in a valid mobile telephone number, and get a valid PUK to reset the PIN—without any authentication whatsoever.

    Oops.

    EDITED TO ADD (7/4): A representitive from O2 sent me the following:

    “Yes, it does seem there is a security risk by O2 supplying such a service, but in fact we believe this risk is very small. The risk is when a customer’s phone is lost or stolen. There are two scenarios in that event:

    “Scenario 1 – The phone is powered off. A PIN number would be required at next power on. Although the PUK code will indeed allow you to reset the PIN, you need to know the telephone number of the SIM in order to get it – there is no way to determine the telephone number from the SIM or handset itself. Should the telephone number be known the risk is then same as scenario 2.

    “Scenario 2 – The phone remains powered on: Here, the thief can use the phone in any case without having to acquire PUK.

    “In both scenarios we have taken the view that the principle security measure is for the customer to report the loss/theft as quickly as possible, so that we can remotely disable both the SIM and also the handset (so that it cannot be used with any other SIM).”

    Posted on July 3, 2006 at 2:26 PM •

    Load ActiveX Controls on Vista Without Administrator Privileges

    This seems like a bad idea to me:

    Microsoft is adding a brand-new feature to Windows Vista to allow businesses to load ActiveX controls on systems running without admin privileges.

    The new feature, called ActiveX Installer Service, will be fitted into the next public release of Vista to provide a way for enterprises to cope with the UAC (User Account Control) security mechanism.

    UAC, formerly known as LUA (Limited User Account), is enabled by default in Vista to separate Standard User privileges from those that require admin rights to harden the operating system against malware and malicious hacker attacks.

    However, because UAC will block the installation of ActiveX controls on Standard User systems, enterprise applications that use the technology will encounter breakages. ActiveX controls are objects used to enhance a user’s interaction with an application.

    Posted on July 3, 2006 at 8:31 AM • View Comments

    Hacking Computers Over USB

    I’ve previously written about the risks of small portable computing devices; how more and more data can be stored on them, and then lost or stolen. But there’s another risk: if an attacker can convince you to plug his USB device into your computer, he can take it over.

    Plug an iPod or USB stick into a PC running Windows and the device can literally take over the machine and search for confidential documents, copy them back to the iPod or USB’s internal storage, and hide them as “deleted” files. Alternatively, the device can simply plant spyware, or even compromise the operating system. Two features that make this possible are the Windows AutoRun facility and the ability of peripherals to use something called direct memory access (DMA). The first attack vector you can and should plug; the second vector is the result of a design flaw that’s likely to be with us for many years to come.

    The article has the details, but basically you can configure a file on your USB device to automatically run when it’s plugged into a computer. That file can, of course, do anything you want it to.

    Recently I’ve been seeing more and more written about this attack. The Spring 2006 issue of 2600 Magazine, for example, contains a short article called “iPod Sneakiness” (unfortunately, not on line). The author suggests that you can innocently ask someone at an Internet cafe if you can plug your iPod into his computer to power it up—and then steal his passwords and critical files.

    And here’s an article about someone who used this trick in a penetration test:

    We figured we would try something different by baiting the same employees that were on high alert. We gathered all the worthless vendor giveaway thumb drives collected over the years and imprinted them with our own special piece of software. I had one of my guys write a Trojan that, when run, would collect passwords, logins and machine-specific information from the user’s computer, and then email the findings back to us.

    The next hurdle we had was getting the USB drives in the hands of the credit union’s internal users. I made my way to the credit union at about 6 a.m. to make sure no employees saw us. I then proceeded to scatter the drives in the parking lot, smoking areas, and other areas employees frequented.

    Once I seeded the USB drives, I decided to grab some coffee and watch the employees show up for work. Surveillance of the facility was worth the time involved. It was really amusing to watch the reaction of the employees who found a USB drive. You know they plugged them into their computers the minute they got to their desks.

    I immediately called my guy that wrote the Trojan and asked if anything was received at his end. Slowly but surely info was being mailed back to him. I would have loved to be on the inside of the building watching as people started plugging the USB drives in, scouring through the planted image files, then unknowingly running our piece of software.

    There is a defense. From the first article:

    AutoRun is just a bad idea. People putting CD-ROMs or USB drives into their computers usually want to see what’s on the media, not have programs automatically run. Fortunately you can turn AutoRun off. A simple manual approach is to hold down the “Shift” key when a disk or USB storage device is inserted into the computer. A better way is to disable the feature entirely by editing the Windows Registry. There are many instructions for doing this online (just search for “disable autorun”) or you can download and use Microsoft’s TweakUI program, which is part of the Windows XP PowerToys download. With Windows XP you can also disable AutoRun for CDs by right-clicking on the CD drive icon in the Windows explorer, choosing the AutoPlay tab, and then selecting “Take no action” for each kind of disk that’s listed. Unfortunately, disabling AutoPlay for CDs won’t always disable AutoPlay for USB devices, so the registry hack is the safest course of action.

    In the 1990s, the Macintosh operating system had this feature, which was removed after a virus made use of it in 1998. Microsoft needs to remove this feature as well.

    EDITED TO ADD (6/12): In the penetration test, they didn’t use AutoRun.

    Posted on June 8, 2006 at 1:34 PM • View Comments

    1 … 41 42 43 44 45 … 50

    Sidebar photo of Bruce Schneier by Joe MacInnis.