GNU Savannah Site Compromised

Trailrunner7 writes "A site belonging to the Savannah GNU free software archive was attacked recently, leading to a compromise of encrypted passwords and enabling the attackers to access restricted project material. The compromise was the result of a SQL injection attack against the savannah.gnu.org site within the last couple of days and the site is still offline now. A notice on the site says that the group has finished the process of restoring all of the data from a clean backup and bringing up access to some resources, but is still in the middle of adjusting its security settings."

Comments

Encrypted passwords?

[gcnaddict]

They didn't hash the passwords with something decent like SHA2? Really?

I mean if they encrypted them weakly or used SHA1 or MD5, that's about as bad as going plaintext. I'd expect far better from them.

Re:Encrypted passwords?

[recoiledsnake]

Add to that that gcc is hosted. Compromise gcc's source and you get access to everything you ever want. Obligatory Ken Thompson compiler trojan article link http://cm.bell-labs.com/who/ken/trust.html#fig6

The actual bug I planted in the compiler would match code in the UNIX "login" command. The replacement code would miscompile the login command so that it would accept either the intended encrypted password or a particular known password. Thus if this code were installed in binary and the binary were used to compile the login command, I could log into that system as any user.

Such blatant code would not go undetected for long. Even the most casual perusal of the source of the C compiler would raise suspicions.

FIGURE 7

The final step is represented in Figure 7. This simply adds a second Trojan horse to the one that already exists. The second pattern is aimed at the C compiler. The replacement code is a Stage I self-reproducing program that inserts both Trojan horses into the compiler. This requires a learning phase as in the Stage II example. First we compile the modified source with the normal C compiler to produce a bugged binary. We install this binary as the official C. We can now remove the bugs from the source of the compiler and the new binary will reinsert the bugs whenever it is compiled. Of course, the login command will remain bugged with no trace in source anywhere.
Moral

The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect.

Re:Encrypted passwords?

[gcnaddict]

You kidding? That has absolutely everything to do with the hash function used!

SHA1 is highly vulnerable to brute force through optimized attacks. That's why NIST (among others) are recommending moving away from SHA1. Ditto for MD5.

Re:Encrypted passwords?

[recoiledsnake]

A salt + a good hash will prevent against bruteforcing. Encryption will allow the attacker to get the original password back which can be used on other websites etc. Any web site worth it's salt (pun unintended) hashes the passwords instead of encrypting them. Cmon, this is Web Security 101 stuff.

Re:Encrypted passwords?

[gcnaddict]

[ ] Implement crypt-md5 support (like /etc/shadow, strong and LDAP-compatible) hashes, or possibly crypt-sha2

Holy shit, they're actually seriously considering MD5. This is embarrassing.

Guys, there's a reason for why I'm saying that MD5 is a Very Bad Idea.

Re:Encrypted passwords?

[Tacvek]

Add to that that gcc is hosted.

GCC's code respositories are hosted on gcc.gnu.org, a machine also known as sourceware.org, which is owned and operated by Redhat and provides hosting for basically the entire GNU toolchain (automake, autoconf, binutils, GCC, gdb, glibc, and libstdc++)[1].

This attack therefore would not be able to modify the GCC sources.

[1] Notably not present are GNU's bison, libtool, m4 and make.

Re:Encrypted passwords?

[tsm_sf]

Protection against brute forcing is a password that isn't in any dictionary attack database, or a l33t variant thereof.

So basically most Hotmail accounts have more secure usernames (a la 'HotAunt67') than passwords ('susan').

Re:Encrypted passwords?

[Anonymous Coward]

[ ] Implement crypt-md5 support (like /etc/shadow, strong and LDAP-compatible) hashes, or possibly crypt-sha2

Holy shit, they're actually seriously considering MD5. This is embarrassing.

Guys, there's a reason for why I'm saying that MD5 is a Very Bad Idea.

That's straight MD5. Password hashes, using PHK@FreeBSD's algorithm, is a bit more complicated (e.g., a thousand iterations with a salt):

http://en.wikipedia.org/wiki/Crypt_(Unix)#MD5-based_scheme

Most Linux distributions still use the MD5-based hash for their shadow files. Of course using a new algorithm is probably better, but we're (hopefully) not talking about straight MD5, but rather the crypt/PHK variant.

Re:Encrypted passwords?

[tlhIngan]

You kidding? That has absolutely everything to do with the hash function used!

SHA1 is highly vulnerable to brute force through optimized attacks. That's why NIST (among others) are recommending moving away from SHA1. Ditto for MD5.

That's if you want to intelligently brute force a SHA1 hash. If however the test material is short (e.g., passwords), then it doesn't matter if you use SHA1, SHA2, whatever. Just do a simple dictionary attack first to see if you can get easy passwords.

Re:Encrypted passwords?

[kangsterizer]

It's actually not *that* bad. You can't actually remotely crack MD5 passwords.. or even plain text since you can't access them.

When you can access them it usually means the system is already fully compromised (not in all cases, but in most).
Then, you'd better not be using the same password or key for several systems (Arnold S. says: big mistake.)
Most don't even know, that you can capture plain text passwords from the SSH server when using password authentication, even with nice SHA2 passwords behind SSH. (using SSH keys and disabling password auth is highly recommended).

So having the passwords hashed with a good algorithm is always a plus, but it's not a big step up. It's quite a small one in fact. You see, even salted MD5 passwords are difficult to recover. You'll find dozen of matches and you won't know which one is the actual password if it's not dictionary based. (and even so, you can't use rainbow tables due to the salt, and it will still take a pretty long time).

Using MD5 is however MUCH worse when used as a security checksum: file checksum, certificate checksum etc. Because there's no salting, and there's no need to find the *original* data here.

You just need to make new data that has the same checksum. Much easier if the aglorithm is broken.

This later reason is actually the reason why MD5 (and to some level, SHA1) are truly broken and inadvisable.

Re:Encrypted passwords?

[Anonymous Coward]

Various Unixes, including Linux distributions like RHEL / CentOS include a modern algorithm inspired by PHK that uses the later SHA family algorithms, and has variable rounds.

But keep in mind that despite all the tutting from know-nothings on Slashdot who react to keywords like 'MD5' even the original DES-based Crypt remains remarkably secure. While a Windows password or MD5 rainbow table is something you can get from any Torrent site, crypt tables still don't exist. While Windows brute forcers can chew through eight alphanumerics while you wait for your pizza to cook, crypt will take weeks.

Basically, other systems spent the early 21st century catching up to where Unix was in the 1970s.

And none of this helps you when a user picks something dumb like 'linux' or 'opensesame' as a password.

Obilgatory

[hairyfeet]

You'd think a site like GNU would have better coders that wouldn't fall for a Bobby Drop Tables gag. I thought the GNU was full of wise old neckbeards?

Re:Obilgatory

[Anonymous Coward]

Does it look to you like this GNU code was written by a wise old neckbeard? It's 780 lines of unreadable crap. This is what the code of a wise old neckbeard looks like.

Re:But Linux is TEH SAFEZORZ!

[MichaelSmith]

I thought Linux was always 100% secure, completely unhackable, because they're the admins are experts and the software has built in security! You mean ... it's not true?

Maybe this one runs HURD.

Re:But Linux is TEH SAFEZORZ!

[LWATCDR]

It was a GNU project it was running on HURD not Linux.

Umm.. this wasn't a LINUX issue it was an SQL injection attack on a website. Are just trying to troll or do you really not know the difference?

Nothing new

[recoiledsnake]

Red Hat/Fedora servers had been hacked compromising the private signing key http://www.pcworld.com/businesscenter/article/150212/hackers_crack_into_red_hat.html

Ubuntu repositories hacked http://www.pcworld.com/businesscenter/article/150212/hackers_crack_into_red_hat.html

And don't forget the Debian SSL key debacle....

Suggestion

[Anonymous Coward]

They should use Windows 7. They could avoid this kind of attack.

Re:So?

[vlm]

"enabling the attackers to access restricted project material."

So? I though it was all about free & open source. Therefore, what restricted material?

Personal contact info for copyright assignees beyond the legally required minimum?

Private GPG keys?

Just making some good guesses.

Re:Sequel

[butalearner]

a SQL injection

Well, we know how the author pronounces SQL now; I have always preferred "an SQL injection"---that is, "S.Q.L."

What, you don't mentally pronounce all acronyms? Well, now, aren't you just a SOB.

Not the first time.

[molo]

GNU Savannah was hacked in 2003 also. http://news.cnet.com/2100-7344-5117271.html

"We expect to take measures in the aftermath of the Savannah incident," said Eben Moglen, general counsel for the Free Software Foundation, which maintains the GNU Project, a source of freely available software for Unix and Linux systems. Among the measures, the project leaders will force developers to digitally sign any code they submit, and they plan to introduce additional features to freely available source-code maintenance systems--the best known being the Concurrent Versions System, or CVS--to check developers' digital signatures before accepting changes.

"We believe (adding digital signatures) is the single most useful technical change to tighten these systems to assure the integrity of the code they contain," Moglen said.

Does anyone know if the changes described here came to be? Did they help at all in this attack?

-molo

Re:Not the first time.

[jrumney]

They changed CVS and other version control systems hosted on savannah to require ssh key based logon for write access. It's not quite what is quoted, but a big step in that direction that was immediately achievable without waiting for the changes in CVS and other programs. They did change the FTP upload process to require GPG signatures for all uploads.

However the web based system that was hacked this time around has a password based login, and allows users to change their authorized SSH keys. It also allows users to register a GPG key, but this is just to allow project members to share their keys (and probably intended for future use when signed commits is available and working), the FTP keyring is more tightly controlled.

Re:But Linux is TEH SAFEZORZ!

[gringer]

You're the one who's shortsighted to think that it's isolated to HURD.

I think GP was pointing out [at least] two things:

1. A GNU operating system is possible without the Linux kernel (i.e. GNU/HURD rather than GNU/Linux)
2. An SQL Injection attack doesn't care much about the underlying operating system

They don't appear to think it's isolated to HURD. I interpreted the statement "this wasn't a LINUX issue" as meaning Linux isn't a necessary precondition for attacks of this nature.