The web hosting development site GitHub reset a number of users’ passwords and revoked a slew of user security authorizations this week following a wave of brute-force attacks.
According to a blog entry by GitHub’s Security Manager Shawn Davenport yesterday, the incident involved login attempts from almost 40,000 distinct IP addresses and was a slow, concerted effort to break into user accounts using multiple passwords.
It’s not known exactly how many accounts were compromised but users with weak passwords and even in some cases those with stronger passwords had their passwords reset and all of their tokens, OAuth authorizations and SSH keys revoked. Affected users were sent an email yesterday requesting they create a stronger password, examine their account for “suspicious activity” and urging them to set up two-factor authentication.
Companies such as Apple, Dropbox, Twitter and Evernote have all added two-factor authentication schemes wherein users enter a numerical code along with a username and password to their products over the past year or so to bolster security.
GitHub claims it’s looking into the attack but in the meantime is working on instituting even more acute rate-limiting measures to curb brute force attacks going forward.
“In addition, you will no longer be able to login to GitHub.com with commonly-used weak passwords,” Davenport notes.
Davenport also took the opportunity to remind GitHub users that the site runs a Security History page for each of its users that logs important events. Launched in October, the feature lets users see a list of active sessions with the ability to remotely revoke them.
Attackers are accessing routers running on the border gateway protocol (BGP) and injecting additional hops that redirect large blocks of Internet traffic to locations where it can be monitored and even manipulated before being sent to its intended destination.
Internet intelligence company Renesys has detected close to 1,500 IP address blocks that have been hijacked on more than 60 days this year, a disturbing trend that indicates attackers could finally have an increased interest in weaknesses inherent in core Internet infrastructure.
It is unknown how the attackers are accessing the affected routers, whether they have physical access or whether the router is exposed to the Internet, but that’s the easy part. The route injection is merely a few tweaks to the router’s configuration.
“It’s actually making a BGP-speaking router do exactly what it is intended to do. All you’re doing is changing the configuration on the router,” said Renesys CTO and cofounder Jim Cowie. “A normal border router would have normal configuration entries for all the networks you have access to—all your customers. This just adds extra lines to a configuration. They can announce these routes to my peers and let them know I can reach this even though it’s fiction. As long as you have access to a border router at an important service provider and you’ve chosen the right place to do this, there’s no software [malware] required.”
The hard part is knowing where to insert the route injection attack, Cowie said, adding that some of the victims Renesys has observed—and contacted—include financial services organizations, voice over IP providers, government agencies and other large enterprises. Attacks take place at the level of the BGP route where blocks of IP addresses, in some cases targeting specific organizations, are misdirected.
“On one hand, we’ve seen people hijacking blocks of addresses that belong to DSL pools, groups of customers not very specific somewhere in the country. And we’ve seen networks hijacked that belong to very specific organizations; they’re not a big pool of generic users, but somebody’s business,” Cowie said.
Cowie said the attackers are using the routing system much in the same way a network engineer would.
“There is some sophistication in the choice of place where you inject these routes from,” Cowie said. “You want to be able to evade whatever filters people have in place to prevent the spread of bad routing. And you want to hijack a place that has influential status who are going to propoagate to the people whose traffic you want. Most of sophistication in the attack is in the choice of the point where you actually do route injection.”
The attackers, meanwhile, can pull of this type of redirection and traffic inspection without much in terms of latency to either end of the web request. Also, unlike traditional man-in-the middle attacks where the bad guy is within physical proximity of the victim, here the attacker could just as easily be halfway around the world. And should the traffic in question be unencrypted, plenty of sensitive business or personal data would be at risk.
“[The attacker is] getting one side of conversation only,” Cowie said. “If they were to hijack the addresses belonging to the webserver, you’re seeing users requests—all the pages they want. If they hijack the IP addresses belonging to the desktop, then they’re seeing all the content flowing back from webservers toward those desktops. Hopefully by this point everyone is using encryption.”
Renesys provided two examples of redirection attacks. The first took place every day in February with a new set of victims in the U.S., South Korea, Germany, the Czech Republic, Lithuania, Libya and Iran, being redirected daily to an ISP in Belarus.
“We recorded a significant number of live traces to these hijacked networks while the attack was underway, showing traffic detouring to Belarus before continuing to its originally intended destination,” the company said on its blog. The hop starting in Guadalajara, Mexico and ending in Washington, D.C., included hops through London, Moscow and Minsk before it’s handed off to Belarus, all because of a false route injected at Level3, the ISP formerly known as Global Crossing. The traffic was likely examined and then returned on a “clean path” to its destination—all of this happening in the blink of an eye.
In the second example, a provider in Iceland began announcing routes for 597 IP networks owned by a large U.S. VoIP provider; normally the Icelandic provider Opin Kerfi announces only three IP networks, Renesys said. The company monitored 17 events routing traffic through Iceland.
“We have active measurements that verify that during the period when BGP routes were hijacked in each case, traffic redirection was taking place through Belarusian and Icelandic routers. These facts are not in doubt; they are well-supported by the data,” the blog said. “What’s not known is the exact mechanism, motivation, or actors.”
Since this isn’t a vulnerability that can be patched, mitigations are limited to either cryptographically signing routes, or following a best practice known as BGP 38, where ISPs put filters in place to prevent spoofing and route injection, Cowie said. Both are expensive and may not be economically feasible to ISPs unless all are required to do so. Also, in particular with crypto signing of routes, if the trust is derived from the government or a single organization, they would have control over segments of Internet traffic which could introduce another set of surveillance issues.
“The tempo [of route injection attacks] has picked up over the course of this year, so my guess is this is more common knowledge among groups who can do this,” Cowie said. “It’s hard to say whether it’s one group, or two groups, three groups. Maybe they know each other, we don’t know. It’s really pretty unknowable.”
Graphic courtesy of Renesys.
NEW YORK–If Bill Cheswick had his way, the future of computing and computer security would look a lot like the distant past, with trusted platforms, small programs, applications that can’t affect the operating system and resistance to user mistakes.
Cheswick, a former Bell Labs computer scientist and longtime speaker on security topics, echoed what many people in the security field have been saying for years now: The current way that we’re thinking about and deploying software and security isn’t working well enough and needs to be rethought. This is a familiar refrain for anyone who’s been paying attention to the direction of the security community of late, but Cheswick said that the solution to the current problem set doesn’t involve adding successively thicker layers of security onto existing platforms. Rather, he envisions a reboot of the computing ecosystem itself.
“I think we can build an affordable computing platform that can’t be compromised by user error not involving a screwdriver,” Cheswick said in a keynote talk at the OWASP AppSec USA conference here Wednesday. “You couldn’t compromise the apps, you couldn’t affect the OS, you couldn’t own the machine. It’s not about user education. It’s bad engineering to rely on grandma. There shouldn’t be anything she can do to affect the system.”
The ideal compute platform would include trusted hardware, trusted firmware, a sandbox and a trusted operating system, Cheswick said. The stack he described is not a novel concept. Older platforms, going back several decades, relied on this architecture, he said, and it’s been proven to be reliable and secure. The problem is that the current software and security ecosystems have evolved to a point where implementing something like that would be expensive, at least at the beginning. However, Cheswick believes that it would be worth the start-up costs and effort in order to spread the benefits to the widest possible user base.
Detecting intrusions and compromises of software and devices is the main goal of much of the security software in use today, but Cheswick maintains that model needs some tweaking.
“We’ve already lost once the evil software is on the machine,” he said.
Preventing attackers from getting their mitts on a target machine in the first place should be the goal, he said, and one that Cheswick believes can be achieved through the separation of the core components of the computing platform from the pieces the user needs to touch.
“I want a system where the OS can’t be changed or subverted regardless of the app that’s run or the user’s action. The apps can’t taint the OS or other apps,” he said. “Random Web software can run in a sandbox and it can have arbitrary amounts of evil and it won’t do any harm. And we need ubiquitous end-to-end crypto. I want my kernel to be cast in adamantium before it goes onto the machine. I don’t want it to change once it loads.”
Some of the features that Cheswick described have been implemented in various platforms over the years, most recently in Apple iOS, which will only run signed code and treats the device as a trusted platform. Whether that model becomes a dominant one in the years to come remains to be seen, but Cheswick said he thinks there’s a good chance it could happen.
“I think we can win. Correct software can be implemented if we’re very careful,” he said.
Hackers reportedly breached servers in January belonging to Cupid Media, a niche dating service with 30 million users, stealing more than 42 million unencrypted passwords and various other sensitive data.
Cupid Media operates a variety of niche dating sites based on ethnicity, religion, physical appearance, special interests, lifestyle and more.
Brian Krebs, who first obtained information about the attack earlier this month, suggests that the Australia-based online dating service may have failed to remove information belonging to users who had deleted their accounts. This, Krebs said, is likely how the site ended up exposing the information of more users than are currently registered there.
The Cupid Media compromise, which the company’s managing director, Andrew Bolton confirmed to Krebs, demonstrates two troubling realities: users are still bad at creating passwords and some companies are still failing to encrypt user data, passwords in particular.
According to the report, the hack exposed the names, email addresses, and birthdays of current and former users as well. The stolen information was found on a server which contained information from other recent data breaches, including some of the 2.9 million customer records stolen from Adobe, uncovered by Krebs.
Krebs examined the passwords used on the Cupid Media service, making lists of the top-ten numeric and non-numeric passwords. What he found was not promising:
Graphs via Krebs on Security