11 Oct KSN: An Analysis of Web Browsers Sergey Golovanov
12 Jan Lab Matters - Cloudy with a chance of stolen data Ryan Naraine
17 Nov Money from the cloud Vyacheslav Zakorzhevsky
21 Sep Kaspersky Lab... also in my list of DDoS attacks! [by SpyEye] Jorge Mieres
28 Jul Amazon S3 exploiting through SpyEye Jorge Mieres
Join our blog
You can contribute to our blog if you have +100 points. Comment on articles and blogposts, and other users will rate your comments. You receive points for positive ratings.
Today, cybercriminals are quick to exploit vulnerabilities in Adobe Reader, Flash and Java to infect users’ computers. There is a simple reason for this popularity: exploits of vulnerabilities found in these products can infect computers regardless of which operating systems and browsers are used on the attacked machines. We assumed that the threats posed to users were unaffected by their choice of browser and undertook a little research to test this assumption.
Dan Geer's fantastic Keynote Speech kicked off Day 2 of SOURCE Conference Boston this morning. The talk itself was heady and complex, something to keep up with. Notable talks also were Jeremey Westerman's "Covering *aaS - Cloud Security Case Studies for SaaS, PaaS and IaaS", and Dan Rosenberg's "Android Modding for the Security Practitioner".
"The internet will never be as free as it is this morning." Dan Geer is one of the best, sharpest computing/network security speakers around. His talk descended from a high-level, lengthy, example-laden description of most every developed nation's dependency on the internet: "Dependence with respect to the internet is transitive, dependence on television is not...We are at the point where it may no longer be possible to live your life without having a critical dependence on the Internet, even if you live at the end of a dirt road but still occasionally buy nails or gasoline." And, he wound through multiple examples of failures in US systems to provide fallback options. He talked about his little local bank, whom he wrote a letter to close down the auto-created online account he wouldn't use. They, as an exception, closed it down immediately. His 401k account administrator Fidelity Investments, on the other hand, would not accept customer instructions from him in writing. The company continues to send him mailed marketing content of all kinds in writing at the address from which he sends his letters. Their auditors apparently approve of Fidelity's rejection of customer-initiated hand-written delivered communications, instead, accepting email/online chat messaging or instructions over the phone. This discussion made its way through systems design, unified field theory, and fault tolerance, eventually landing on key points that intrusion prevention is agreed not to be a workable model, instead, the elegance of "intrusion tolerance" must be built into systems, and countries and organizations that cannot build tolerance into their systems are not sustainable. Favorite quotes: "forget the banks, it is the internet that is too big to fail", "Is there room for those who choose simply to not participate in the internet?", "HTML5 is Turing complete. HTML4 is not", and "Should we preserve a manual means? Preserving fallback is prudent if not essential."
Jeremy Westerman's "Covering *aaS - Cloud Security Case Studies..." presented several design cases for Universities and other organizations. The single most important point to learn from this talk is that API key management is unfortunately not handled with as much urgency and awareness as private SSL keys for large organizations. This API key, in the context of multiple, popular single sign-on (SSO) solutions in use at large universities, is the key to tens of thousands, if not hundreds of thousands, of email accounts. Similar API key schemes are implemented on IaaS solutions like the Xen supported Amazon EC2 environment and VMWare vCloud Teramark environments. Without appropriate awareness, developers are storing that key in improper locations like the hard drive of the sign-on machine, or the developers themselves are storing keys on their development system hard drives in non-obvious places, emailing/"dropboxing" them around to each other and then simply transferring the API keys to the production environment, instead of re-issuing production API keys. It is practically imperative that these keys are taken out of the hands of developers. These loose handling practices are bad news - viral code like Sality and other viral code and worms previously high in our prevention stats have maintained functionality to steal FTP and web admin account passwords in order to silently host malicious code, encrypted or otherwise, on legitimate web sites without the owner's knowledge. In other words, developers have been effective and weak targets in the past for credential theft, enabling silent site compromise and malicious use. Most schools don't want that - I remember one unfortunate notification at a small Arts college, where the web admin really didn't want to believe that the encrypted blob of data hosted on his school's web server was a viral payload updating other students' infected systems, located there because his credentials were Sality-stolen after trying to run cracked software distributed over a P2P network. Anyway, it happens and it can be planned for and prevented.
Director of Kaspersky Lab's global research and analysis team Costin Raiu appears on Lab Matters to discuss the security ramifications of the growing dependence on cloud computing. The discussions center on the convenience of using consumer cloud services and some of the risks involved with outsourcing security to third-parties.
Not so long ago we wrote about cybercriminals using infected computers to generate virtual money via Bitcoin. A couple of days ago we discovered a malicious program called Trojan-Downloader.Win32.MQL5Miner.a which also uses the resources of infected computers, but this time to make money in MQL5 Cloud Network, a distributed computing network.
The MQL5 Cloud Network site
MetaQuotes is a developer of software for financial markets. Several weeks ago, information appeared on the net that the company was offering to pay users to participate in distributed computing. Apparently, this is what attracted malicious users to the new cloud service.
Google search results for the phrase: “MQL5 Cloud Network money”
There are grounds to believe that the malicious program spreads via email. Having infected a computer, the malicious program first determines if the operating system is 32-bit or 64-bit. It then downloads the appropriate version of the official software from MetaQuotes SoftWare. MQL5Miner then launches the service to participate in the cloud computing network. But the cybercriminals specify their own account data and receive the payments for any distributed computing operations that are performed on an infected machine.
A window from the legitimate MetaQuotes software
When it comes to making money, cybercriminals don’t miss a trick. That includes exploiting the resources of infected computers without their owners’ knowledge or consent.
We have notified MetaQuotes about the account being used by cybercriminals.
The title of this post suggests that I’ve been thinking of one of the cyber-criminals that uses SpyEye, maybe in admiration! But actually his cyber-criminal actions overshadow anything else.
The truth is that, following my post highlighting the tactic of using as C&C one of the Cloud Computing services offered by Amazon, I found a sample of SpyEye that is somewhat interesting: among its goals is an attack DDoS directed against the Kaspersky Lab website.
The SpyEye configuration file, which is basically a compressed file and password protected (usually MD5), stores the resources involved in the planned attack. The surprise came when I looked at the configuration file of the plugin (ddos.dll.cfg). The following image shows the parameters set in this file:
Cloud Computing providers offer gigabytes of storage for free, and the cybercriminals use to maintain and spread malware of all the kind. At the same time, many legitimate services are not free, but are still very attractive to cybercrime gangs. In the case of Amazon, Amazon Simple Storage Service (Amazon S3) does the trick.
Despite being a paid service, the cost is not an obstacle for profitable attackers. In fact, my colleague Dmitry Bestuzhev recently told us about the spread of malware exploiting this service to "the cloud".
The truth is that these cases are not isolated. According to our research, cybercriminals have been running SpyEye activities and from Amazon for the past couple of weeks.
We decided to see how successful our nameless ‘miner’ was, and ended up getting a bit of a surprise.