Is it just me, or does anyone wish that compromise disclosures should be hosted somewhere other than the site that has been compromised? What if there's a persistent threat and their webserver is still hosed, injecting 0days into responses? Not that it's happening here - I still clicked it - but I was hesitant.
I don't think there's much point in worrying about drive-by browser attacks. We all visit a lot of sites, and many sites are hacked without their owners knowing, but just serving malware/phishing/redirects for spam, ad networks, and injection into more popular sites.
If a browser 0day really did apply to my up-to-date version of firefox and really was a problem, well, I'd feel pretty screwed.
You are right. We should even go further and reset the whole interweb each time there is a disclosure, or at least randomize the DNS records of the affected servers.
> We have confirmed that initial entry was made via a team member's compromised login details and not as the result of a vulnerability in the phpBB software.
> The attackers were able to obtain access to the phpBB.com and area51 databases, meaning that user information, including hashed salted passwords, was compromised. Additionally, all logins on area51 between Dec. 12th and Dec. 15th were logged in plaintext. While the hashing algorithm utilized in phpBB will make it difficult to obtain those passwords, you should not take any chances.
A bit of clarification should be given. The staff's login information was stolen, allowing someone to get a dump of the database containing user info. What kind of login information was stolen? Is this an shell account, was an SSH key stolen, was this an admin panel account?
Secondly, "all logins [...] were logged in plaintext". Does this mean the username and password were logged, the password hashes and sessions? What actual information was plaintext to the user?
It's great that groups are willing to own up to these kinds of events, but without specific information, it's hard to understand how broad a compromise we're talking.
Here is an email I received from phpbbhelp.org:
> Hello everyone,
>
> On September 9th, an attacker was able to gain unauthorized access to the server hosting phpbbhelp.org. This remained unnoticed until late yesterday. The individual (might be individuals) responsible is the same one taking credit for the Tapatalk, phpBB.com, and Ars Technica breaches.
>
> A keylogger was added to the login page, and if your username is on the following list, the plaintext password you used on phpbbhelp.org is likely in their hands.
> List: [removed]
> We have to assume that the database was likewise dumped and that everyone's email addresses and hashed passwords are likewise in the wild.
>
> Please change any password that you may have used on phpbbhelp.org since September.
>
> If I have any further information, I will provide it. USF will remain offline until after we have restored phpBB.com and I have some time to go through it.
>
>
>
> - Yuriy Rusko
I'm would assume the same thing was done on the phpbb.com servers.
As good as qmail is, the official release is so far behind the times it's ridiculous. The unofficial patches, made unofficial by a stubborn refusal on the part of the author to merge them in, have fixed most of these issues, but then what's the point of using qmail if you have to use the untrusted version?
Sadly qmail is a lesson of how you can be correct and completely wrong at the same time.
Imagine a completely secure operating system that only runs on 32-bit systems. Could you actually advocate using it in a serious production capacity?
phpBB 2 was a total security nightmare and anyone running it or version 1 in production should be shot.
They realized how horrible things were and massively cleaned up their act around version 3. No published vulnerabilities issued since 2010, and only a handful for 3.x in general.
I have a Google App Engine instance, and it started getting a lot of random requests, which may be related to this. My website had 5,000 requests yesterday (normally less than 50). The logs indicate a lot of these:
That's an unrelated probe for a different, surely vulnerable, script - Zeroboard.
If the attack probes disturb you, begin gathering their patterns and plonking their IPs into a black hole using something like fail2ban. Er, well, that's what I'd do on a normal system. Not sure what to do about that on GAE.