Themes.org Cracked

sammoth writes: "themes.org was hacked [CT:Cracked] and replaced with a rather vulgar logo. The intruder makes some bold statements about the security, or lack there of, on several sites. " Of course I'm still in Tokyo right now, so your guess about what's happening is just as good as mine. And 5000ms ping times to the U.S. East Coast sure makes posting this story tricky ;) Apparently the cracker managed to get into SourceForge and Apache.org too ... and he posted user accounts and passwords on t.o along with a rant that I haven't seen. Update: 05/31 02:40 PM by T : Here's an informative explanation on apache.org of the break-in on that site.

Comments

"What do you if you're owned"

[DaveTerrell]

Rule #1: Unplug the ethernet cable, not the power. It's hard to do a post-mortem if your filesystem is crashed.

Rule #2: don't give any indication that you're aware the box has been rooted before you engage rule #1.

Rule #3: Don't trust anything that might have gone through that box for a reasonable period of time. Re-password, check other machines, reinstall software, etc. Good luck.

Rule #4: Run OpenBSD and don't get rooted. :)

Re:"What do you if you're owned"

[Xofer D]

I think this would be a good time to link to The Linux Security HOWTO: What to Do During and After a Breakin , as well as of course the Linux Security HOWTO itself . Don't just read it. Implement it.

Evil Overlord List, item #401

[XPulga]

Whenever a site gets cracked, post an article on slashdot about it (even if you're half globe away with 5000 ms ping delay) so they get slashdotted too.

Re:Out come the Wolves...

[sheldon]

Well I'm not sure what you mean by small percentage.

Microsoft has around 50% of the commercial web server space according to the Netcraft SSL survey. That's a fairly large chunk considering the next competitor is Apache with 30%.

Apache is certainly used for a lot of hosted web sites... you know the routine "Hi my name is Joe and this is my website!"

Now one could probably argue that it's easier to knock off the small websites. After all they probably aren't maintained frequently.

But on the other hand, they also aren't accessed frequently so who would notice?

Much more fun to hit the high profile sites. Especially if there are some juicy credit card numbers to be had because of poor site design.

Re:All OSes are insecure...

[johnnyb]

The difference is that on the Internet people seem to be much more willing to do bad things. Therefore, you have to be totally up on security. Let's look at it from this perspective:

In other areas of life, security isn't that big of a deal. It's easy to break into cars, it's easy to break into stores. I can deface just about any building in town if I wanted to. However, fewer people consider this allowable behavior, so you don't need the same kind of security to prevent this.

In the same way, you could probably murder entire buildings worth of people simply by putting dangerous chemicals in their air-conditioning system, because most air-conditioning systems aren't well-guarded at all. However, most people have more of a respect for life than that. On the internet, there isn't much respect for anything. So, you can either accept that you're going to get hacked, or spend all day keeping up with updates.

Re:Interesting

[devin]

This might be it.

Re:Interesting

[PD]

Attrition is dead. Maybe /. could become the new home for orphaned defacements.

Some ideas for securing a public access Linux

[Ex Machina]

Check out how I "secure" my network, Its not perfect but its relatively easy to implement. http://while1.org/security.shtml and now I post the whole thing to karma whore! :)

We try to keep While(1).org fairly secure. Here is a general overview of our security process. It should be helpful for many novice UNIX admins.

• Operating System: Although OpenBSD is generally regarded as the best Freenix in terms of security, GNU/Linux is under more active development, faster, more user friendly and supports far more software packages and types of hardware than OpenBSD (sorry Theo, much respect...). I, along with most of the other admins and users are more familiar with a GNU environment. The distribution we use is Debian. I chose Debian for several reasons: free (libre and gratis), strong package system and reliability. It hasn't let me down. I do prefer Slackware on my personal box, since the -current tree is more stable than Debian's unstable. However, Debian's package system is nicer and provides many things that Slackware lacks (I may abandon Slackware as soon as Debian supports XF4 and kernel 2.4 by default in stable). Debian also keeps up to date on security issues.
• Kernel: We now run a Linux 2.4 kernel. Although most security tools/patches are 2.2 only, the mature (READ: usable) ones have been ported to kernel 2.4. I'm confident that more will follow. 2.2 is dead. We have disabled modules entirely in our kernel to prevent hax0ring and to avoid using modules (does anyone else hate them?). We only have a few drivers enabled. Besides helping performance, this protects against hostile code injection into the kernel. It is possible for a clever coder to inject code into a non-modular kernel, but most rootkits use kernel modules. Not allowing kernel modules and using 2.4, prevents us from using some really cool security tools like LOMAC. However, I found that LOMAC did not play nicely with OpenWall's Secure Linux patch (or cron, or init or getty ...). When Lomac behaves nicer, it will be added (I'd also like to see it as a patch rather than a module). Currently, we are using the GetRewted.net patch which provides lots of security enhancements. We may be adding more secure kernel additions such as the NSA's Security Enhanced Linux. However, at this time, we feel that the current kernel security model is both secure and usable. If you have any neat kernel goodies we might like, tell us.
• Firewall: Note that we are NOT running any sort of real firewall. We feel that the extra kernel overhead of the firewall hurts performance and adds needless complexity to the server. Since we are NOT trusting local (ie: users with shell access) anyway, we feel that a firewall is basically useless since Linux's TCP/IP stack is already fault-tolerant, mature and robust. We augmented the TCP/IP stack with this shell script to limit our vulnerability to DoS attacks. Firewalling services should not be needed if your services are secure (run with minimal priviliges and SECURE by design and condiguration). Eventually we may drop an OpenBSD or Linux 2.4 firewall in front of the server as a measure for restricting local users ability to portscan, DoS and exploit remote hosts.
• Authentication / Login: Remote interactive sessions are only supported over ssh (and we run OpenSSH). Telnet is not allowed. Rhosts authentication is not allowed. I've looked at forcing people to use S/Keys, but it is a real pain in the ass on both ends. We are currently allowing FTP in. When I'm confident that all the users can get a good graphical scp/sftp client for their platform, I'll kill FTP. Since I'm not relying on trusting local users anyway, this is more a security concern for individual users. I'm considering locking some users who don't use their shells out of real shell access.
• Users: I only make accounts for people I know personally. I also monitor user login s and their activity using whowatch and process accounting. I'm suspicious of logins from weird hosts. I also use PAM to set resource limits.
• Monitoring: We watch out for network nastiness with Snort which is an AWESOME IDS. We monitor its logs and other system activity with Psionic's LogCheck. Occasionally, I'll audit the machines for weird ports using nmap and Nessus, both of which are REALLY nice. I'll also routinely verify system integrity using a combination of Tripwire and chkrootkit, on a system booted from a known CLEAN floppy containing the tools.

Re:Rewarding the Hacker?

[jonbrewer]

Good lord, why not? Themes.org and Sourceforge aren't exactly conveying information of vital importance to anyone. Their cracking isn't going to affect the markets, political battles, holy wars, sickness, or starvation anywhere in the world.

Why not reward the hacker by posting their conquest on Slashdot? Especially since they've proved their talent in such a benign way. And, of course, they've done the community a service by exposing vunerable security holes... which will hopefully be patched before some site of actual significance is hacked, sending the world into economic depression.

(I sure wish someone had cracked the Florida electoral system beforehand...)

This is why 4.4BSD invented the immutable bit

[bee]

Breakins like this are why the immutable bit was introduced in 4.4BSD. If you set your important executables immutable (ls, ps, ssh, etc) then even if someone does root your box, they can't change those without taking the machine down to single-user mode and changing it there, which in most cases can't be done without physical console access. This trick works for logfiles too; an immutable logfile can be appended to but not deleted or rewritten.

---

Re:Rewarding the Hacker?

[JabberWokky]

And, of course, they've done the community a service by exposing vunerable security holes... which will hopefully be patched before some site of actual significance is hacked, sending the world into economic depression.

When it was announced that Sourceforge had been hacked, I was the only one that ventured the idea that it wasn't a technical hack, but a social one (okay, that sounds like I've got a swollen head, but the point is, most people lept to the conclusion that it was a technical hole, rather than a social one).

Most likely, this will not be the only other OSDN and related sites that is defaced - if they got into Sourceforge and Themes.org on stolen passwords, they are probably collecting passwords, looking through history files, hammering through, searching for passwords to other sites. Since it's a fairly small pool of admins that all work together, it is likely that there are some overlap between admins. Plus the odd (and stupid) admin that uses the same passwords at multiple sites.

Social engineering, stealing a password or swiping a laptop does not beneficially expose security holes unless the password was negligently left out, or the social engineering targeted somebody who shouldn't have had the password anyway. I know a large ISP (one of the, oh, say, top two) where most of the sales force knows the NT Admin password for all machines on the network. That's negligence.

Having a laptop in session get swiped at Comdex means you better know what's on that laptop (and deal with it quickly), but at that point, can just be a race. And if you leave it at a restaurant, come back the next day to pick it up, unaware that the busboy is a 133t d00d, is that negligence (in a perfect world, yes. In reality, it's a bit more fuzzy).

And of course, the tendancy towards smart cards (which aren't) will only make this problem worse. A bit of biometrics might help: a thumbpad on the side of the card, maybe.

--
Evan

Apache.org's announcement

[Chuck Chunder]

From the announce@apache.org mailing list:
====

Earlier this month, a public server of the Apache Software Foundation (ASF) was illegally accessed by unknown crackers. The intrusion into this server, which handles the public mail lists, web services, and the source code repositories of all ASF projects was quickly discovered, and the server immediately taken offline. Security specialists and administrators determined the extent of the intrusion, repaired the damage, and brought the server back into public service.

The public server that was affected by the incident serves as a source code repository as well as the main distribution server for binary release of ASF software. There is no evidence that any source or binary code was affected by the intrusion, and the integrity of all binary versions of ASF software has been explicitly verified. This includes the industry-leading Apache web server.

Specifically: on May 17th, an Apache developer with a sourceforge.net account logged into a shell account at SourceForge, and then logged from there into his account at apache.org. The ssh client at SourceForge had been compromised to log outgoing names and passwords, so the cracker was thus able get a shell on apache.org. After unsuccessfully attempting to get elevated privileges using an old installation of Bugzilla on apache.org, the cracker used a weakness in the ssh daemon (OpenSSH 2.2) to gain root privileges. Once root, s/he replaced our ssh client and server with versions designed to log names and passwords. When they did this replacement, the nightly automated security audits caught the change, as well as a few other trojaned executables the cracker had left behind. Once we discovered the compromise, we shut down ssh entirely, and through the serial console performed an exhaustive audit of the system. Once a fresh copy of the operating system was installed, backdoors removed, and passwords zeroed out, ssh and commit access was re-enabled. After this, an exhaustive audit of all Apache source code and binary distributions was performed.

The ASF is working closely with other organizations as the investigation continues, specifically examining the link to other intrusion(s), such as that at SourceForge (http://sourceforge.net/) [ and php.net (http://www.php.net/). ]

Through an extra verification step available to the ASF, the integrity of all source code repositories is being individually verified by developers. This is possible because ASF source code is distributed under an open-source license, and the source code is publicly and freely available. Therefore, the ASF repositories are being compared against the thousands of copies that have been distributed around the globe. While it was quickly determined that the source code repositories on the ASF server were untouched by the intruders, this extra verification step provides additional assurance that no damage was done.

As of Tuesday, May 29, most of the repository has been checked, and as expected, no problems have been found. A list of verified modules will be maintained, and is available here: http://www.apache.org/info/hack-20010519.html

Because of the possible link of the ASF server intrusion to other computer security incidents, the investigation is ongoing. When complete, the ASF will offer a complete and public report.

The Apache Software Foundation strongly condemns this illegal intrusion, and is evaluating all options, including prosecution of the individual(s) responsible to the fullest extent of the law. Anyone with pertinent information relating to this or other related events should contact root@apache.org. Anyone from the media with further interest should contact press@apache.org.

Thanks.

Brian Behlendorf
President, Apache Software Foundation
====

A better hack...

[Polo]

A better hack would to be crack slashdot, (possibly from Japan), then post a very subtle and believable story telling of other sites being compromised with "vulgar pictures"...

and then chuckle in a maniacal way as the slashdot effect works as a DOS attack on those sites...

Taco on "Crack"

[QuantumG]

sigh.

Re:Taco on "Crack"

[Cardhore]

I agree.

Remember when the word hacker used to mean someone who breaks into networks or writes code? And crackers were the ones who cracked the copy protection on software and had the "s3r1a1 #'s". They were always grouped with anarchy, virii, and wares all over the net.

Who cares if "good" and "bad" hackers are called hackers? Most people can understand who you are if you take two minutes to explain which type you are . . . people are surprisingly able to understand these things if someone explains them to them. Most people are willing to listen; just talk to them.

Mmm.... Infowar.

[solios]

First the DDOS attacks- and probably other sorts of similar high-profile hits before then. Then the discovery that M$'s internal network had been compromised; and now in the past week, Themes.org was cracked and Sourceforge was messed with. Slashdot was compromised a few months ago as well (and the staff was very open about what went down and how it had been possible), and I'm sure there are many others that are escaping my attention at the moment.

Is it just me, or are these sorts of things on the rise- not only the frequency, but the profile of the target? How long until a *really* high profile, high volume portal or site such as Amazon, Ebay, or Yahoo gets 0wn3d?

It's geurilla warfare- a war without soldiers, ammunition or human casualties. The attackers cannot be easily found, and even when they are, prosecuting them is difficult, if not impossible (extradition treaties, diplomatics, etceteras). From what I've seen, all of the major targets have been hosted on US soil- I wouldn't be surprised if many of the attackers were overseas. Firewalls don't seem up to the task, and neither do many sysadmins.

What sort of tools exist to prevent this sort of thing (aside from simply using OpenBSD)? Any Gibsonian Black Ice? The TCP/IP equivalents of radar and surface-to-air missiles? Are any of them open sourced, and what is the state of their development?

Re:Mmm.... Infowar.

[dudle]

What sort of tools exist to prevent this sort of thing (aside from simply using OpenBSD)?

That's not right! You don't get protected from viruses just by installing Norton Antivirus, you have to constently update it, make sure you run the newest version, etc.

Securing a system requires deep knowledge about that said system. I don't know shit about OpenBSD. Do you really think I will be more secure if I were to use OpenBSD tomorrow rather than Debian that I know pretty well? I don't think so either.

Any Gibsonian Black Ice? The TCP/IP equivalents of radar and surface-to-air missiles? Are any of them open sourced, and what is the state of their development?

Snort, logcheck and the like do help, as long as you stay up to date with BugTraq and you keep you head cold. The minute you think you are secure, you get screwed. All the tools in the world won't help you if you don't know how to use them.

So what can we do? Well here is my humble opinion:
Before you get owned

• Knowledge is gold but documentation is golden.
• Get a working backup solution in place

Once you realize you're owned

1. Unplug the box
2. Get the hot spare and restore the data on it (you do have a hot spare I hope)
3. Analyse the system in a post-mortem mode
4. Reinstall the compromised system from scratch

Good Luck.

Mirror (I think)

[chris88]

This is what I took from here. Which says it's a mirror.

Re:The rant

[zimbu]

....I wouldnt be sitting atop a mountain of roots and oodles of proprietary software..

apache.org and sourceforge.com those are the first places I go to get my proprietary software.

Re:Interesting

[mini me]

Actaully http://defaced.alldas.de/ has already taken over this role. Mind you themes.org doesn't seem to be on there yet!? They do however provide all the info on operating systems and multiple attacks, etc.

The rant

[quickquack]

Here's what the cracker posted:

The site's "shell server" was compromised May 22 after a SourceForge employee logged on to an outside Internet service provider that had already been taken over by the intruder, said Pat McGovern, site director of SourceForge.net. When the staff member logged on to SourceForge remotely, the intruder captured the password.

Well some of that is true, I mean I did trojan ssh but I did it about 5 months ago, so kudos to the admin you sir are awesome..

"What happened was the (ISP) was compromised and had not known it," McGovern said, adding that the site's administrator quickly noticed the intruder and shut systems down. "Basically we had to go through and rebuild the machine, and then we checked the log file of everyone who used the machine."

hrm I guess that could also be considered true, if by true you mean, finding out every box on your network is owned 5 months after the fact and only due to my own boredom that consisted of me ircing it infront of the admin, by the way good job of auditing your network, wait thats just too much sarcasm for one sentence..

After the attack, VA removed the shell service until workers could reinstall the software and data on the server. The shell server allowed SourceForge members to type commands into the system remotely. On Thursday, the company posted an alert that the shell server couldn't be used because of an "unscheduled maintenance event."

It also allowed me to sniff my way onto apache.org and sourceforge webserver and leave all sorts of goodies in the code..

In this case, they only got into a shell server," McGovern said.

Hey, theres no disputing that, I mean.. wait.. Whats this I'm defacing ?

The company also decided to shut down its "compile farm," a collection of computers running different operating systems on which SourceForge developers can test their software.

Why would they shut down other boxes, if only the shell server was hacked ?

Although illicit modifications to the programming projects are a concern, McGovern said the intruder didn't get that far.
oh come now, you're just being silly..

Its ok thought I dont blame you guys, I mean atleast you admited to being schooled, thats more then I can say for akamai, but thats a different story all together.. But never the less, I'd like to thank valinux.. apache.. akamai and ofcourse exodus without their poor security and refusal to make security breaches known to the public I wouldnt be sitting atop a mountain of roots and oodles of proprietary software.. This is the fluffy bunny signing of.. beep..

-fluffy@#blackpanthers on efnet (the scourge of efnet)

Greets to: dianora.. tsk.. squrl.. cumstud.. glitch.. snow.. dwalrus.. cotton butt.. JAIL MITNICK! / FREE THE SHDWKNGHT!!!!!

Note: I removed the /etc/passwd file at the end of this. Thought it would be nicer that way.
------------

Someone should...

[hyoo]

...hack goatse.cx and put up a non-vulgar picture.

Rewarding the Hacker?

[Alien54]

While it is nice to know that the site got hacked, aren't we rewarding the hacked by posting all to info in a public forum?

Sort of between a rock and a hard place here. we need to inform the affected users, but we do not want to reward the hacker with the notoriety they crave.

Check out the Vinny the Vampire comic strip

Re:Rewarding the Hacker?

[swillden]

And of course, the tendancy towards smart cards (which aren't) will only make this problem worse. A bit of biometrics might help: a thumbpad on the side of the card, maybe.

As someone who designs and implements high-security access control systems for a living, I disagree that smart cards make the problem worse (and they are actually pretty smart). Yes, cards can be stolen, but in any reasonable implementation the cards perform access control on the usage of their stored secrets, requiring password or biometric authentication (actually, I'm not aware of any real-world, secure implementations that use biometrics because unless the matching is done either on the card or in another secure device that shares keys with the card, then biometric authentication is extremely weak).

Even without a second authentication factor, and even without a secure token, the use of a cryptographic authentication mechanism does vastly improve security over weak, reused and occasionally even sniffable passwords. Applying two-factor authentication, with a secure token as one factor essentially eliminates a whole class of attacks. Use of a host security module on the server is also of great benefit, making it impossible for the attacker to get at the most valuable secrets in the event they manage to compromise the server.

The tendency towards smart cards does in fact go a very long way towards solving this problem.

Re:the rant that CmdrTaco mentioned ....

[phaze3000]

I think you're getting confused here..

X server - what actually displays stuff, runs on your local machine
X client - program that runs on remote machine
SSH daemon - program that runs on remote machine giving you shell access
SSH client - program that runs on your local machine that allows you to connect to SSH daemon on remote machine.

Right, now we've got that clear, let's see what these programs actually allow us to do in terms of potential exploits.
SSH - allows us to run (gasp!) ARBITARY CODE on the remote machine. Except that it runs as the user we're logged in as, which presumably will be a low enough level only to cause problems to ourself (unless there are unpatched programs). This is really only a problem if we've already got root, in which case there are already plenty of naughty things we can do.
Running an X client when logged in via SSH allows one to run X clients (ie X applications) on the remote server, but have them display on our local X server. The code is still running on the remote server, just like it is when we execute a program via SSH. Just like when we use SSH, the output from the program is sent to our screen rather than the machine it's actually running on.

So, to conclude - there is no extra security risk from running X apps remotely. The programs are still running on the remote machine, they're just displaying on your local X server.

The security vulnerability here came about because there was a cracked SSH executable on a machine which one of the Sourceforge guys then used to log in to Sourceforge. The cracker didn't go into details, but I'm willing to bet it's some ancient vulnerability that was expolited - like the portmapper one that a couple of worms have used, or a wu-ftpd issue. Or maybe something bind-related.

Hope this stops anyone from panicing unnecessarily.

--

Re:Interesting

[Lyrrad]

Well, I'd assume that themes.org will come out with a theme about this.

But, http://defaced.alldas.de/ should have it soon.

Nuke the planet from orbit--only way to be sure

[KMitchell]

If the "rant" is to be believed, SourceForge missed a trojan when they recovered their server... I was thinking when reading the original story that I wouldn't feel comfortable just going through the logs and trusting that I caught everything... I guess re-installing from source media *IS* the only way to go...

The big remaining questions are how many sysadmins at sites "trusted" by a compromised box should be looking for rootkits and dusting off backup CDs... and how many man-hours will it take to audit the hosted code to regain confidence that there ISN'T a backdoor somewhere...

--Ken

Re:Interesting

[diamondc]

what the hell... peopl are mirroring deleting th passwords sugarkane.rgv.net/~diamondc/themesownage.html

Security

[iCharles]

Boy, the security on IIS/NT really sucks to allow such a hack to happen.

Oh, yeah...

Re:Out come the Wolves...

[ocbwilg]

I can see it now... PR folks from Microsoft, and other closed-source businesses are going to jump all over this (or related matters):

Please...the absolute last thing MS wants to do is to actually get people started comparing the number of cracked web servers between NT/IIS and anything else. Even their corporate PR droids know that NT/IIS is by far the most exploited/cracked web server combination in the world (and disproportionately so when you consider that they have such a small percentage of the web server marketshare).

This worries me...

[Scoria]

... and it should worry you as well, if you use any of OSDN's services.

That's right, any of them. After all, they're keeping very quiet about it and just about everything of OSDN's is getting cracked lately.

Whoever this is, they must have root or access to sniff network traffic. It seems like whatever they don't already have access to, they can get it.

Should you be worried? Yes. Is it overreacting? No.

We rely on these people to keep our source (relatively) secure and disclose the problems that may be occuring...br>
Will I be using SourceForge to store my code? No. I'll use a local box behind a firewall with no services, except a secure FTP daemon, allowed.

If nothing else, at least keep a local backup, as many people don't seem to be doing this. They may have even installed a trojan into the box to insert code into the applications.

Or maybe even a trojaned build of 'make.'

You never know...