By Mike S
iPhoneDevSDK—the site apparently responsible for the hacks at Facebook, Apple, and Twitter—says it was not aware it was being used to attack visitors until it read press reports this week. In a news post do not click if you’re wary of security breaches on Wednesday, site admins said they had no knowledge of the breach and were not contacted by any of the affected companies. Though, iPhoneDevSDK is now working with Facebook’s security team in order to share information about what happened.
Also, this is a great reminder to log and monitor, or SIEM. An admin’s account was compromised, then their website was hacked.
Tripwire would have caught the changes, and login auditing would have caught the hacker/admin’s actions.
By Mike S
This is why you employ defense-in-depth and full network monitoring, even if you don’t care what websites your employees visit at work.
But while the company was informed by AT&T of suspicious activity over its network connection on October 25—the day the Wen story was published—the attack had begun weeks earlier and appears to have been focused on getting into the e-mail accounts of Times Shanghai Bureau Chief David Barboza and South Asia Bureau Chief Jim Yardley. The attack used 45 different pieces of custom malware code, including remote access tools that gave Chinese hackers the run of the Times’ network.
The attackers used a botnet of computers compromised at US universities to obscure the source of the attack. They then infected computers at the Times with malware, most likely through e-mail “spear phishing” attacks, and used the malware to install remote access tools on at least three target systems that allowed them to gather more information from the network—finally finding the Windows network domain controller and grabbing its user directory and password tables. The hackers then used the cracked passwords to access other systems and created a custom program built to infiltrate the Times‘ mailserver to search all the e-mails and documents sent to Barboza and Yardley’s accounts—apparently searching for the names of people who may have spoken to Barboza as he reported on the Wen family.
By Mike S
By Mike S
Bad news for RoR sites… it’ll probably be years before they’re all upgraded and patched.
Hundreds of thousands of websites are potentially at risk following the discovery of an extremely critical vulnerability in the Ruby on Rails framework that gives remote attackers the ability to execute malicious code on the underlying servers.
The bug is present in Rails versions spanning the past six years and in default configurations gives hackers a simple and reliable way to pilfer database contents, run system commands, and cause websites to crash, according to Ben Murphy, one of the developers who has confirmed the vulnerability. As of last week, the framework was used by more than 240,000 websites, including Github, Hulu, and Basecamp, underscoring the seriousness of the threat.
By Mike S
It’s interesting seeing how extensive our police-state surveillance is:
While the details of this investigation that have leaked thus far provide us all a fascinating glimpse into the usually sensitive methods used by FBI agents, this should also serve as a warning, by demonstrating the extent to which the government can pierce the veil of communications anonymity without ever having to obtain a search warrant or other court order from a neutral judge.
The guest lists from hotels, IP login records, as well as the creative request to email providers for “information about other accounts that have logged in from this IP address” are all forms of data that the government can obtain with a subpoena. There is no independent review, no check against abuse, and further, the target of the subpoena will often never learn that the government obtained data (unless charges are filed, or, as in this particular case, government officials eagerly leak details of the investigation to the press). Unfortunately, our existing surveillance laws really only protect the “what” being communicated; the government’s powers to determine “who” communicated remain largely unchecked.
By Mike S
A low-tech variation on the “watch facebook for announcements of when people will be away from home”:
The scheme is simple enough: you open the newspaper or look online at the obituaries, and it’s a roadmap for criminals as to where you’ll be and when you’ll be there — a funeral home for the visitation, a cemetery for the burial.
By Mike S
Which will the market reward: Those who disclose vulnerabilities to the public so they can be patched? or those who keep vulnerabilities secret and sell them to underground bidders?
By Mike S
It’s at times like these that defense in depth really shines!
To detect targeted threats, companies must first be more aware of what is going on in their networks, Percoco says. By watching for events — and not just suspicious activity — a company can detect the existence of an infection. Known as indicators of compromise, or IOCs, these events can tip a company off that something unwanted is inside the firewall.
Finally, companies can take the “deny all” approach to applications, just like the recommended practice for firewall rules. Known as whitelisting, the defensive technology allows only known good programs to run on systems. With millions of variants of malware being generated every year, focusing on the 10,000 to 25,000 programs running on a typical system make more sense, Bit9′s Sverdlove says.
I expect whitelisting to become more popular, and hopefully, much easier. The main problem I’ve seen with whitelisting is that the basic set of apps is easy to enumerate and whitelist, but then as patches get rolled out — nearly every other week for Java and Firefox — the app must be re-whitelisted. It just doesn’t seem to scale well when you have lots of users roaming around with lots of applications, and lots of updates, and lots of broken, no-longer-whitelisted applications.
By Mike S
It is quite an impressive sample of software engineering and deployment:
Attackers behind the Flame espionage malware that targeted computers in Iran used more than 80 different domain names to siphon computer-generated designs, PDF files, and e-mail from its victims, according to a new analysis from researchers who helped discover the threat.
The unknown authors of Flame shut down the sprawling command-and-control (C&C) infrastructure immediately after last Monday’s disclosure that the highly sophisticated malware had remained undetected for at least two years on computers belonging to government-run organizations, private companies, and others. The 80 separate domain names were registered using a huge roster of fake identities, and some of the addresses were secured more than four years ago.
“The Flame C&C domains were registered with an impressive list of fake identities and with a variety of registrars, going back as far as 2008,” Kaspersky Lab expert Alexander Gostev wrote in a blog post published Monday. “In general, each fake identity registered only 2-3 domains, but there are some rare cases when a fake identity registered up to 4 domains.”
Names used to obtain the domains included Adrien Leroy, Arthur Vangen, George Wirtz, Gerard Caraty, Ivan Blix, and at least 15 others. They claimed to reside in a host of cities in Europe and elsewhere, in some cases at addresses that turned out to belong to hotels such as the Appart’Hotel Residence Dizerens in Geneva or, with a slight modification, the Apple Inn in Amsterdam. Other fake identities used addresses of shops, organizations, or doctor’s offices. Because of the effectiveness and complexity of Flame and its targeting of Iran and other Middle Eastern computers, researchers have speculated it was sponsored by a wealthy nation-state.
By Mike S
Those Sword and Shield guys are pretty clever!
First, I scanned the network with Nessus and did not find any easily exploited vulnerabilities but I did find a medium-risk vulnerability showing unauthenticated access to multiple NFS shares Nessus ID 42256. Browsing the shares I found a backup copy of the client’s public web site, which was developed using Visual Studio. Visual Studio stores database connection strings, including plaintext passwords, in .config files. Using the command grep -r connectionStrings= at the root of the source directory, I found multiple connection strings that used three different database passwords.