Here is a list with working passwords to exactly 100 email-accounts to Embassies and Governments around the world. Yes it’s the real deal and still working when we are posting this. So why in the world would anyone publish this kind of information? Because seriously, I’m not going to call the president of Iran and tell him that I got access to all their embassies. I’m DEranged, not suicidal! He has bombs and stuff…
You’ve probably heard: “More than half of Ubuntu’s production servers had to be pulled offline after a security breach caused those servers to actively attack other machines.”
The servers, especially zambezi were running an incredible amount of web software (over 15 packages that we recognised) and of all the ones where it’s trivial to determine a version, they were without exception out-of-date and missing security patches. An attacker could have gotten a shell through almost any of these sites.
FTP (not sftp, without SSL) was being used to access the machines, so an attacker (in the right place) could also have gotten access by sniffing the clear-text passwords.
The servers have not been upgraded past breezy due to problems with the network card and later kernels. This probably allowed the attacker to gain root.
According to Maligno’s blog, the servers had been running unpatched for 9 months and a half!
The probability of intrusion and/or compromise is determined on how well you manage your systems. The choice of OS just means different attack vectors. What is the use of a [sarcasm]Super-Secure-Unbreakable[/sarcasm] operating system if you don’t patch and update it, use poor configuration management, use clear-text passwords, etc?
“Ubuntu had to shutdown 5 of 8 production servers that are sponsored by Canonical, when they started attacking other systems. Canonical blames the community, saying they were community hosted, and were poorly maintained. However, kernel upgrades couldn’t be done because of poor backwards compatibility with the very hardware that Canonical had sponsored! While people point fingers at each other it is pretty clear that both sides are equally to blame, the community administrators for practicing bad security practices, such as using unencrypted FTP transfers with accounts, not properly maintaining the system. However Canonical should have been well aware of what they are hosting. The question remains, if any of the files distributed to users have been compromised. A major blow for Canonical though who are attempting to enter the business market with Ubuntu Server.”
DNS rebinding attacks subvert the same-origin policy of browsers and convert them into open network proxies. We survey new DNS rebinding attacks that exploit the interaction
between the browser and browser plug-ins such as Flash and Java LiveConnect. These attacks can be used to circumvent firewalls and are highly cost-effective for sending
spam e-mail and defrauding pay-per-click advertisers, requiring less than $100 to temporarily hijack 100,000 IP addresses. We show that a well-known, existing defense
against these attacks, called “DNS pinning,” is ineffective in modern browsers. The primary focus of this work, however, is the design of strong defenses against DNS rebinding attacks that protect modern browsers. For the near-term, we suggest easy-to-deploy defenses that prevent large-scale exploitation by patching individual plug-ins and improving the robustness of browser DNS pinning strategies. For the longterm, we propose two solutions, circumvention-resistant firewalls
and host name authorization, that fix the root cause of DNS rebinding vulnerabilities by preventing the attacker from naming a target server.
Interesting article at Dark Reading about security audits with basic tips on how to pass them (or at least how to give it a good try) It starts off with “Nobody passes a security audit on the first try“. Maybe the title should be changed to “Where will the auditors look for issues (and probably find them)“.
The eight general recommendations are:
Establish a consistent set of practices for change management
Keep your app developers away from production/operations
Give users access only to the data and apps they need
Shore up physical access to your systems
Establish methods to detect security anomalies — and where they come from
Map your security processes to real business processes
Double (and triple) check your accounting processes
Document your work and train your users on what you’ve done
Sounds easy, heh? If you have that reasonably locked down, you’ve gone a long way.
