Image via Wikipedia
According to DreamHost’s Status and Blog, staff noticed some unusual activity on one of their databases that held user login information for shell accounts. While the passwords were mostly encrypted, hackers “hacker found a legacy pool of unencrypted FTP/shell passwords in a database table that we had not previously deleted,” according to DreamHost CEO Simon Anderson.
As a precaution, ALL shell/FTP account passwords were reset by DreamHost. While it will cause some inconvenience for users trying to access their sites over SSH/FTP, the implications are much more serious. A lot of CMS systems store their database username and passwords in plaintext on configuration files. If whoever gained access to DreamHost’s shell account database and managed to decrypt the information, then they would have unmitigated access to not only sites’ files, but they could potentially (and most likely) gain access to the back-end database driving those sites with all user data. This could be a very major breach of user data from one of the largest web hosts in the United States.
DreamHost is being unusually mum about the technical details about the hack and is angering customers over their negligence regarding out-dated server software. While most front-end software is kept up-to-date, their back-end software is grossly outdated and there appears to be no real effort nor care by DreamHost to keep OS and back-end software updated. What makes things worse is that DreamHost’s official stance on their security solution is to not disclose what technologies they use. Rather than taking a proactive and relatively transparent stance to their own security systems, the company has decided to take-up a reactive and a “security through obscurity” stance.
Related articles
- DreamHost Security Issue Prompts FTP Password Resets (sucuri.net)
- Changing Shell/FTP Passwords due to Security Issue (dreamhoststatus.com)
- Security Update (dreamhost.com)
Image via CrunchBase
I first took attention to Carrier IQ when it was discovered by custom ROM developers for the phone I personally have; the Sprint Epic4G made by Samsung. The device is part of the massively popular Galaxy S line of Android-powered devices that virtually every major cellular carrier in the world sells. Around June, it was discovered that this software records virtually everything a user does with their phone from each screen-tap to every site they visit to recording audio and even the physical orientation of the device itself.
A thread (which I now cannot find on XDA-Developers) outlined this “middleware” and it was surmised that individual Carriers like Sprint used it solely for coverage and troubleshooting issues. An effort was undertaken to remove this software from the Android Linux kernel as it was discovered to hinder the device’s performance. Developers notably had a very difficult time removing Carrier IQ, but managed to eventually remove it for their custom Android ROMs.
Fast forward to Fall of 2011 where a developer named Trevor Eckhart decided to look into Carrier IQ a bit deeper and found that Carrier IQ was essentially a rootkit and actually recorded almost all actions performed with a device it was installed on and phoned home with that information. He has released a video showing proof of Carrier IQ recording his location with location turned off, un-encrypted HTTPS streams, all SMS messages sent/received, and even EVERY touch of the device screen he makes.
Essentially what everything boils down to is that carriers can spy on literally everything you do with your phone. This is obviously a blatant violation of privacy rights and repercussions are sure to come. Developing…
Related articles
- Carrier IQ Rootkit Reportedly Logs Everything On Millions Of Phones (pcworld.com)
- You Can Test Your Android For Carrier IQ (Sort Of) [Carrier Iq] (gizmodo.com)
- People Are Freaking Out About Carrier IQ, The Hidden Smartphone Program That Tracks Everything You Do (businessinsider.com)
- Carrier IQ: How To Find It, And How To Deal With It – TechCrunch (techcrunch.com)
- Silicon Alley Insider: RIM: We Do Not Authorize Carrier IQ On BlackBerry Phones (RIMM) (businessinsider.com)
- Verizon: No CarrierIQ, No way (gigaom.com)
- So, there’s a rootkit hidden in millions of cellphones (zdnet.com)
- Phone ‘Rootkit’ Maker Carrier IQ May Have Violated Wiretap Law In Millions Of Cases (textually.org)
SANS has posted that they’ve heard grumblings on the Internets of a new OpenSSH exploit in the wild. They haven’t gotten their hands on it yet, but they’ve had several reports and a console log of the supposed exploit in action.
More info after the jump. SANS Diary on the Exploit
A new tool exploiting a quite-clever and very tricky to fix issue with ALL versions of Apache Web Server and Squid as well has been published into the wild yesterday. There’s no paper outlining the exact exploit, but there doesn’t really need to be one. As described by Bojan Zdrnja of SANS ISC, the DoS is carried out basically by telling the server to “hold on, I’m sending more header data,” yet never does:
…the server will open the connection and wait for the complete header to be received. However, the client (the DoS tool) will not send it and will instead keep sending bogus header lines which will keep the connection allocated.
The initial part of the HTTP request is completely legitimate:GET / HTTP/1.1\r\n
Host: host\r\n
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.503l3; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12)\r\n
Content-Length: 42\r\n
After sending this the client waits for certain time – notice that it is missing one CRLF to finish the header which is otherwise completely legitimate. The bogus header line the tools sends is currently:X-a: b\r\n
Which obviously doesn’t mean anything to the server so it keeps waiting for the rest of the header to arrive
Essentially the attacker sends a partial legitimate browser UA string, albeit incomplete with intentions to send the rest of the data to complete the string, yet never does. This in turn holds the session open on the server end, quickly maxing the server’s connection table waiting for “clients” to complete the request.
This attack requires a very small amount of bandwidth to bring a server to its knees. There is no known workaround or patch yet, but can be stopped by including the signature for this type of attack in your IDS (if you have one in front of the web server.)
I recall Check Point VPN-1 R65 introducing a DoS protection technique that could possibly reduce the impact of such type of DoS attack. To keep the firewall’s connections table from becoming saturated in the event of a Denial-of-Service attack, a three-way session verification would take place. When a connection request it is initiated, the firewall would send back an acknowledgment to go ahead and start sending traffic (if the specific connection was allowed in the rulebase), but only keep the connection record in memory, not committing it to the actual connections table on the firewall. If no traffic was returned by the requestor, then the connection would be ignored and purged from memory. This kept the connections table clean of any “dummy” connections and thus would not become saturated and cause traffic-flow to come to a grinding halt. Maybe the fix could be to do something on an HTTP session scale with Apache.
