Entries Tagged "patching"

Page 8 of 13

FTC Investigating Android Patching Practices

It’s a known truth that most Android vulnerabilities don’t get patched. It’s not Google’s fault. It releases the patches, but the phone carriers don’t push them down to their smartphone users.

Now the Federal Communications Commission and the Federal Trade Commission are investigating, sending letters to major carriers and device makers.

I think this is a good thing. This is a long-existing market failure, and a place where we need government regulation to make us all more secure.

Posted on May 11, 2016 at 2:37 PM • View Comments

Credential Stealing as an Attack Vector

Traditional computer security concerns itself with vulnerabilities. We employ antivirus software to detect malware that exploits vulnerabilities. We have automatic patching systems to fix vulnerabilities. We debate whether the FBI should be permitted to introduce vulnerabilities in our software so it can get access to systems with a warrant. This is all important, but what’s missing is a recognition that software vulnerabilities aren’t the most common attack vector: credential stealing is.

The most common way hackers of all stripes, from criminals to hacktivists to foreign governments, break into networks is by stealing and using a valid credential. Basically, they steal passwords, set up man-in-the-middle attacks to piggy-back on legitimate logins, or engage in cleverer attacks to masquerade as authorized users. It’s a more effective avenue of attack in many ways: it doesn’t involve finding a zero-day or unpatched vulnerability, there’s less chance of discovery, and it gives the attacker more flexibility in technique.

Rob Joyce, the head of the NSA’s Tailored Access Operations (TAO) group—basically the country’s chief hacker—gave a rare public talk at a conference in January. In essence, he said that zero-day vulnerabilities are overrated, and credential stealing is how he gets into networks: “A lot of people think that nation states are running their operations on zero days, but it’s not that common. For big corporate networks, persistence and focus will get you in without a zero day; there are so many more vectors that are easier, less risky, and more productive.”

This is true for us, and it’s also true for those attacking us. It’s how the Chinese hackers breached the Office of Personnel Management in 2015. The 2014 criminal attack against Target Corporation started when hackers stole the login credentials of the company’s HVAC vendor. Iranian hackers stole US login credentials. And the hacktivist that broke into the cyber-arms manufacturer Hacking Team and published pretty much every proprietary document from that company used stolen credentials.

As Joyce said, stealing a valid credential and using it to access a network is easier, less risky, and ultimately more productive than using an existing vulnerability, even a zero-day.

Our notions of defense need to adapt to this change. First, organizations need to beef up their authentication systems. There are lots of tricks that help here: two-factor authentication, one-time passwords, physical tokens, smartphone-based authentication, and so on. None of these is foolproof, but they all make credential stealing harder.

Second, organizations need to invest in breach detection and—most importantly—incident response. Credential-stealing attacks tend to bypass traditional IT security software. But attacks are complex and multi-step. Being able to detect them in process, and to respond quickly and effectively enough to kick attackers out and restore security, is essential to resilient network security today.

Vulnerabilities are still critical. Fixing vulnerabilities is still vital for security, and introducing new vulnerabilities into existing systems is still a disaster. But strong authentication and robust incident response are also critical. And an organization that skimps on these will find itself unable to keep its networks secure.

This essay originally appeared on Xconomy.

EDITED TO ADD (5/23): Portuguese translation.

Posted on May 4, 2016 at 6:51 AM • View Comments

Security Vulnerabilities in Wireless Keyboards

Many wireless keyboards have a security vulnerability that allow someone to hack the computer using the keyboard-computer link. (Technical details here.)

An attacker can launch the attack from up to 100 meters away. The attacker is able to take control of the target computer, without physically being in front of it, and type arbitrary text or send scripted commands. It is therefore possible to perform rapidly malicious activities without being detected.

The MouseJack exploit centers around injecting unencrypted keystrokes into a target computer. Mouse movements are usually sent unencrypted, and keystrokes are often encrypted (to prevent eavesdropping what is being typed). However the MouseJack vulnerability takes advantage of affected receiver dongles, and their associated software, allowing unencrypted keystrokes transmitted by an attacker to be passed on to the computer’s operating system as if the victim had legitimately typed them.

Affected devices are starting to patch. Here’s Logitech:

Logitech said that it has developed a firmware update, which is available for download. It is the only one among the affected vendors to respond so for with a patch.

“Logitech’s Unifying technology was launched in 2007 and has been used by millions of our consumers since. To our knowledge, we have never been contacted by any consumer with such an issue,” Asif Ahsan, Senior Director, Engineering, Logitech. “We have nonetheless taken Bastille Security’s work seriously and developed a firmware fix. If any of our customers have concerns, and would like to ensure that this potential vulnerability is eliminated…They should also ensure their Logitech Options software is up to date.”

Posted on March 3, 2016 at 6:29 AM • View Comments

Security Risks of Unpatched Android Software

A lot has been written about the security vulnerability resulting from outdated and unpatched Android software. The basic problem is that while Google regularly updates the Android software, phone manufacturers don’t regularly push updates out to Android users.

New research tries to quantify the risk:

We are presenting a paper at SPSM next week that shows that, on average over the last four years, 87% of Android devices are vulnerable to attack by malicious apps. This is because manufacturers have not provided regular security updates. Some manufacturers are much better than others however, and our study shows that devices built by LG and Motorola, as well as those devices shipped under the Google Nexus brand are much better than most. Users, corporate buyers and regulators can find further details on manufacturer performance at AndroidVulnerabilities.org.

Posted on October 21, 2015 at 6:22 AM • View Comments

Vulnerabilities in Brink's Smart Safe

Brink’s sells an Internet-enabled smart safe called the CompuSafe Galileo. Despite being sold as a more secure safe, it’s wildly insecure:

Vulnerabilities found in CompuSafe Galileo safes, smart safes made by the ever-reliable Brinks company that are used by retailers, restaurants, and convenience stores, would allow a rogue employee or anyone else with physical access to them to command their doors to open and relinquish their cash….

The hack has the makings of the perfect crime, because a thief could also erase any evidence that the theft occurred simply by altering data in a back-end database where the smartsafe logs how much money is inside and who accessed it.

Nothing about these vulnerabilities is a surprise to anyone who works in computer security:

But the safes have an external USB port on the side of the touchscreens that allows service technicians to troubleshoot and obtain a backup of the database. This, unfortunately, creates an easy entrypoint for thieves to take complete, administrative control of the devices.

“Once you’re able to plug into that USB port, you’re able to access lots of things that you shouldn’t normally be able to access,” Petro told WIRED. “There is a full operating system…that you’re able to…fully take over…and make [the safe] do whatever you want it to do.”

The researchers created a malicious script that, once inserted into a safe on a USB stick, lets a thief automatically open the safe doors by emulating certain mouse and keyboard actions and bypassing standard application controls. “You plug in this little gizmo, wait about 60 seconds, and the door just pops open,” says Petro.

If it sounds like the people who designed this e-safe ignored all of the things we’ve learned about computer security in the last few decades, you’re right. And that’s the problem with Internet-of-Things security: it’s often designed by people who don’t know computer or Internet security.

They also haven’t learned the lessons of full disclosure or rapid patching:

They notified Brinks about the vulnerabilities more than a year ago, but say the company appears to have done nothing to resolve the issues. Although Brinks could disable driver software associated with the USB port to prevent someone from controlling the safes in this way, or lock down the system and database so it’s not running in administrative mode and the database can’t be changed, but so far the company appears to have done none of these.

.

Again, this all sounds familiar. The computer industry learned its lessons over a decade ago. Before then they ignored security vulnerabilities, threatened researchers, and generally behaved very badly. I expect the same things to happen with Internet-of-Things companies.

Posted on August 3, 2015 at 1:27 PM • View Comments

Stagefright Vulnerability in Android Phones

The Stagefright vulnerability for Android phones is a bad one. It’s exploitable via a text message (details depend on auto downloading of the particular phone), it runs at an elevated privilege (again, the severity depends on the particular phone—on some phones it’s full privilege), and it’s trivial to weaponize. Imagine a worm that infects a phone and then immediately sends a copy of itself to everyone on that phone’s contact list.

The worst part of this is that it’s an Android exploit, so most phones won’t be patched anytime soon—if ever. (The people who discovered the bug alerted Google in April. Google has sent patches to its phone manufacturer partners, but most of them have not sent the patch to Android phone users.)

Posted on July 28, 2015 at 6:37 AM • View Comments

Research on Patch Deployment

New research indicates that it’s very hard to completely patch systems against vulnerabilities:

It turns out that it may not be that easy to patch vulnerabilities completely. Using WINE, we analyzed the patch deployment process for 1,593 vulnerabilities from 10 Windows client applications, on 8.4 million hosts worldwide [Oakland 2015]. We found that a host may be affected by multiple instances of the same vulnerability, because the vulnerable program is installed in several directories or because the vulnerability is in a shared library distributed with several applications. For example, CVE-2011-0611 affected both the Adobe Flash Player and Adobe Reader (Reader includes a library for playing .swf objects embedded in a PDF). Because updates for the two products were distributed using different channels, the vulnerable host population decreased at different rates, as illustrated in the figure on the left. For Reader patching started 9 days after disclosure (after patch for CVE-2011-0611 was bundled with another patch in a new Reader release), and the update reached 50% of the vulnerable hosts after 152 days.

For Flash patching started earlier, 3 days after disclosure, but the patching rate soon dropped (a second patching wave, suggested by the inflection in the curve after 43 days, eventually subsided as well). Perhaps for this reason, CVE-2011-0611 was frequently targeted by exploits in 2011, using both the .swf and PDF vectors.

Paper.

Posted on May 20, 2015 at 2:15 PM • View Comments

An Incredibly Insecure Voting Machine

Wow:

The weak passwords—which are hard-coded and can’t be changed—were only one item on a long list of critical defects uncovered by the review. The Wi-Fi network the machines use is encrypted with wired equivalent privacy, an algorithm so weak that it takes as little as 10 minutes for attackers to break a network’s encryption key. The shortcomings of WEP have been so well-known that it was banished in 2004 by the IEEE, the world’s largest association of technical professionals. What’s more, the WINVote runs a version of Windows XP Embedded that hasn’t received a security patch since 2004, making it vulnerable to scores of known exploits that completely hijack the underlying machine. Making matters worse, the machine uses no firewall and exposes several important Internet ports.

It’s the AVS WinVote touchscreen Direct Recording Electronic (DRE). The Virginia Information Technology Agency (VITA) investigated the machine, and found that you could hack this machine from across the street with a smart phone:

So how would someone use these vulnerabilities to change an election?

  1. Take your laptop to a polling place, and sit outside in the parking lot.
  2. Use a free sniffer to capture the traffic, and use that to figure out the WEP password (which VITA did for us).
  3. Connect to the voting machine over WiFi.
  4. If asked for a password, the administrator password is “admin” (VITA provided that).
  5. Download the Microsoft Access database using Windows Explorer.
  6. Use a free tool to extract the hardwired key (“shoup”), which VITA also did for us.
  7. Use Microsoft Access to add, delete, or change any of the votes in the database.
  8. Upload the modified copy of the Microsoft Access database back to the voting machine.
  9. Wait for the election results to be published.

Note that none of the above steps, with the possible exception of figuring out the WEP password, require any technical expertise. In fact, they’re pretty much things that the average office worker does on a daily basis.

More.

Posted on April 23, 2015 at 7:19 AM • View Comments

1 … 6 7 8 9 10 … 13

Sidebar photo of Bruce Schneier by Joe MacInnis.