Information Security News
Security researchers have uncovered an active malware campaign in the wild that steals the Apple ID credentials from jailbroken iPhones and iPads.
News of the malware, dubbed "unflod" based on the name of a library that's installed on infected devices, first surfaced late last week on a pair of reddit threads here and here. In the posts, readers reported their jailbroken iOS devices recently started experiencing repeated crashes, often after installing jailbroken-specific customizations known as tweaks that were not a part of the official Cydia market, which acts as an alternative to Apple's App Store.
Since then, security researcher Stefan Esser has performed what's called a static analysis on the binary code that the reddit users isolated on compromised devices. In a blog post reporting the results, he said unflod hooks into the SSLWrite function of an infected device's security framework. It then scans it for strings accompanying the Apple ID and password that's transmitted to Apple servers. When the credentials are found, they're transmitted to attacker-controlled servers.
Here's one yardstick that I use before signing up for any new online service: I first search the Interwebs for stories from users who tried to close their account and to leave same service, and were given a hard time. I understand that commercially it is "rewarding" to show 300 million subscribers, even if 90% of them are stale accounts. But from a privacy and data security point of view, it does NOT make any sense for a user to leave an account behind that he/she knows for sure will never be used again. Some services, also larger ones, are handling this issue professionally, and have a decently findable link on their home page that allows the closing of an account and deletion of stored data. Others .. give you the run-around via six levels of customer "service", and in the end, they basically change your username to username.inactive, but leave everything else as-is. And keep spamming you, too.
If you have stories to share about online services that don't let you leave, please do so below. Keep it PG-13 and factual, please, but if a little ire shines through, we understand ...(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
If you want to protect yourself against the 500,000 or so HTTPS certificates that may have been compromised by the catastrophic Heartbleed bug, don't count on the revocation mechanism built-in to your browser. It doesn't do what its creators designed it to do, and switching it on makes you no more secure than leaving it off, one of the Internet's most respected cryptography engineers said over the weekend.
For years, people have characterized the ineffectiveness of the online certificate status protocol (OCSP) as Exhibit A in the case that the Internet's secure sockets layer and transport layer security (TLS) protocols are hopelessly broken. Until now, no one paid much attention. The disclosure two weeks ago of the so-called Heartbleed bug in the widely-used OpenSSL cryptography library has since transformed the critical shortcoming into a major problem, the stuff of absurdist theater. Security experts admonish administrators of all previously vulnerable websites to revoke and reissue TLS certificates, even as they warn that revocation checks in browsers do little to make end users safer and could indeed weaken the security and reliability of the Internet if they were made more effective.
Certificate revocation is the process of a browser or other application performing an online lookup to confirm that a TLS certificate hasn't been revoked. The futility of certificate revocation was most recently discussed in a blog post published Saturday by Adam Langley, an engineer who was writing on his own behalf but who also handles important cryptography and security issues at Google. In the post, Langley recites a litany of technical considerations that have long prevented real-time online certificate revocations from thwarting attackers armed with compromised certificates, even when the digital credentials have been recalled. Some of the considerations include:
by Sean Gallagher
First, DSL router owners got an unwelcome Christmas present. Now, the same gift is back as an Easter egg. The same security researcher who originally discovered a backdoor in 24 models of wireless DSL routers has found that a patch intended to fix that problem doesn’t actually get rid of the backdoor—it just conceals it. And the nature of the “fix” suggests that the backdoor, which is part of the firmware for wireless DSL routers based on technology from the Taiwanese manufacturer Sercomm, was an intentional feature to begin with.
Back in December, Eloi Vanderbecken of Synacktiv Digital Security was visiting his family for the Christmas holiday, and for various reasons he had the need to gain administrative access to their Linksys WAG200G DSL gateway over Wi-Fi. He discovered that the device was listening on an undocumented Internet Protocol port number, and after analyzing the code in the firmware, he found that the port could be used to send administrative commands to the router without a password.
After Vanderbecken published his results, others confirmed that the same backdoor existed on other systems based on the same Sercomm modem, including home routers from Netgear, Cisco (both under the Cisco and Linksys brands), and Diamond. In January, Netgear and other vendors published a new version of the firmware that was supposed to close the back door.
Now that the frantic frenzy around "Heartbleed" has calmed, and most sites are patched, it is time to circle back. For a server at a community college that I knew had been affected, I wanted to see if someone had pulled any data via Heartbleed during the roughly 36 hours between when the vulnerability became widely known, and when IDS signatures and patches were deployed to protect the site.
Problem is, Heartbleed leaves basically no traces in the httpd server log, so checking there for attacks didn't help. After a bit of pondering, we came up with the idea to correlate the firewall log with the web server log. If the firewall had seen a number of tcp/443 (HTTPS) connections to the web server from a certain IP, but these same connections were not in the web server log, chances were that we had found ourselves a bleeder.
The first IP that the correlation script identified as potentially fishy turned out to be owned by SSLlabs, and likely belongs to their public SSL scanner that everyone was using at the height of the panic. So .. the script seemed to be working well, and was pulling out the "right" types of connections.
A bit later, we found another IP, registered to an ISP in Malaysia. Twenty minutes of hits only on the firewall, at a rate of about one every 5 seconds, followed by a 5 minute pause, followed by hits both on the firewall and on the web server. Hmm, peculiar :). Chances are high this was in fact someone who tried to steal cookies of active sessions first, and then tried to re-use the cookies to break in. For the second part of the attack, the web server log shows GET requests to the application, followed by a 302 redirect to the "login" page, so "something" must have gone wrong on the attacker's side in either stealing the cookies, or in splicing them back into his fake requests. After another 20 minutes and about 60 requests which all were answered with a redirect, the attacker gave up.
Which tools or methods did you use to identify "heartbleed" leaks that occurred in the time span where your site was vulnerable, but IDS instrumentation and patching wasn't really available yet? Feel free to let us know via the contact form, or share in the comments below!(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
OpenSSL, in spite of its name, isn't really a part of the OpenBSD project. But as one of the more positive results of the recent Heartbleed fiasco, the OpenBSD developers, who are known for their focus on readable and secure code, have now started a full-scale review and cleanup of the OpenSSL codebase.
If you are interested in writing secure code in C (not necessarily a contradiction in terms), I recommend you take a look at http://opensslrampage.org/archive/2014/4, where the OpenBSD-OpenSSL diffs and code changes are coming in fast, and are often accompanied by cynical but instructive comments. As one poster put it, "I don't know if I should laugh or cry". The good news though definitely is that the OpenSSL code is being looked at, carefully and expertly, and everyone will be better off for it.(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Posted by InfoSec News on Apr 21http://www.bankinfosecurity.com/michaels-confirms-data-breach-a-6763
Posted by InfoSec News on Apr 21http://www.nextgov.com/cybersecurity/2014/04/heartbleed-means-healthcaregov-users-must-reset-passwords/82852/
Posted by InfoSec News on Apr 21http://www.darkreading.com/author.asp?section_id=331&doc_id=1204560
Posted by InfoSec News on Apr 21http://www.armytimes.com/article/20140407/NEWS04/304070052/Cyber-warfare-research-institute-open-West-Point
Posted by InfoSec News on Apr 21http://arstechnica.com/security/2014/04/mission-critical-satellite-communications-wide-open-to-malicious-hacking/