11 Nov How to keep your Bitcoins safe Stefan Tanase
08 Oct HTTPS working for malicious users Andrey Makhnutin
03 Sep NetTraveler Is Back: The 'Red Star' APT Returns With New Tricks Costin Raiu
12 Aug Central Tibetan Administration Website Strategically Compromised as Part of Watering Hole Attack Kurt Baumgartner
12 Aug Visit from an old friend: Counter.php Vicente Diaz
09 Aug Securing your Email space GReAT
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.
As Bitcoin reached an all-time high of $327/BTC, news about yet another huge robbery hit the world of crypto-currencies. One of the relatively new “Bitcoin banking” services named inputs.io claimed it has been compromised by hackers. The attackers were able to penetrate the server on October 23 and 26 and transfer 4100 BTC (approximately US$1.2 million). According to “Tradefortress”, the service owner, the attackers used old email accounts together with a password reset technique: “They were able to bypass two-factor authorization due to a flaw on the server host side”.
Right now it is not possible to confirm that this was a real hack, and not merely a site owner scamming customers. But it is not the first time this has happened - there were a number of similar incidents in recent years on many different bitcoin storage and exchange services. Examples include, in May and July 2012, the Bitconica theft (approx. 58,000 bitcoins stolen), Linode hacks in March 2012 (approx. 46,000 bitcoins stolen) and Bitfloor Theft in September 2012 (approx. 24,000 bitcoins stolen).
All this accidents happened because of silly mistakes made by service operators. Bitfloor was robbed because its unencrypted wallet backup was mistakenly stored on some of the servers. The Bitconica theft occured when a top privileged email account was compromised giving the cybercriminals access to Bitconica’s rackspace server where the wallet was kept. There are hundreds of similar examples.
Bitcoin is a secure and viable currency, but its security ultimately depends on its users. If users are unable to establish the security of their own wallets they definitely will lose them.
The best strategy for storing and using Bitcoins securely is “Don’t keep all of your eggs in the same basket”. Use different approaches for short-term and long-term storage. The most flexible solutions are usually the least secure ones as well. You don’t want to keep all of your bitcoins on your mobile or Blockchain wallet for instance - but just enough for weekly use. At the end of the week, you can top-up your Bitcoins from your long-term storage, the one which is secured.
If you own a couple of Bitcoins, then the most important thing is how to keep them safe. Here’s a couple of tips from our side based on personal experience and watching cybercriminals at work.
First of all – the Bitcoins should not be kept in online stock exchange services or banks that are new and untrustworthy. Keep in mind that most of these services are anonymous; owners are only known by nicknames so most likely, you will not be able to get a refund of your money if something bad happens. Even if a service has a perfect reputation, it could also be compromised like any ordinary bank. To store your Bitcoins, you can use an open-source “offline” bitcoin client like Electrum or Armory. These encrypt your wallet with a strong password and protect it, ensuring that only you have access to your crypto-currency.
Passphrases for your bitcoin wallets and online storages should be complex as possible – use open source password generating software.
Once you have your bitcoins in an “offline” wallet, secured by a strong password, make sure your PC is protected with a good, solid antivirus and your PC has the latest software updates installed. If you have a huge amount of bitcoins - you should keep them in a wallet on a PC that is not connected to the Internet at all!
Some say Bitcoins will bring down governments or even the society as we know it; others advocate it as the solution to all our financial problems. To be honest, when it comes to Bitcoins, nobody knows what the future will bring. One thing is for sure, though - cybercriminals are highly interested into stealing your hard earned crypto-currencies, so we’re likely to see more attacks in the future.
Infected websites appear on the Internet literally every day. They include personal blogs on WordPress that become infected during mass, automated attacks, and the websites of major media outlets, each of which malicious users infect manually after some preparatory steps. All of these resources replenish the arsenal of so-called “traffic traders” — cybercriminals who redirect visitors to infected websites to the online resources of their malware-writing clients. In the end a user, suspecting nothing, can become the victim of a drive-by attack and, if the user’s browser or the browser’s plug-ins have the necessary vulnerabilities, malware will be downloaded to and installed on the victim’s computer.
Kaspersky Lab has a system that automatically detects and visits infected websites in order to collect a malicious sample and send it to our virus lab for research. To ensure this system is as effective as possible when it comes to detecting online threats, infected websites are studied by virus analysts. With the precision and attentiveness of a forensics examiner, they are able to determine how attacks are launched when a user visits a website.
My attention then turned to an unassuming string in Fiddler, which indicated that part of the site’s content is downloaded through an encrypted channel via HTTPS.
It was hard to believe that malicious users went through the costly procedure of obtaining an SSL certificate for the website in order to spread malicious programs, since these websites are put onto blacklists by antivirus companies and lose their value very quickly. But as Sherlock Holmes says, “Eliminate all other factors, and the one which remains must be the truth.”
I wasn’t feeling overly confident when I switched on Fiddler’s option to decipher HTTPS traffic. But as it turned out, what had originally seemed like an altogether ordinary string was in fact concealing a redirect to a malicious website.
The site that served as the source of malicious software, just like the website that served as the redirect intermediary with the SSL certificate, were both added to our database of malicious resources right then and there. All of the malware that they had been spreading had already previously been detected and identified by Kaspersky Lab.
But my curiosity was piqued: are malicious users really purchasing SSL certificates for the secure transmission of malicious code, or had they somehow figured out a way to get past browser verification using fake SSL certificates? Surprising as it was, the certificate was the real deal.
Quite often, we see malicious users preying on the trust of their victims — they hack accounts on social networks in order to send links to that person’s friends under the guise of yet another cute cat video (but with an .exe extension, and not everyone will fall for that), and they recreate the logos of law enforcement agencies seeded with a blackmailer Trojan, and persuade users to enter their cell phone numbers “to fight botnets”. But what’s more, malicious users also expend no small effort to fool antivirus companies and independent researchers. What may seem like a harmless grey string in an HTTPS connection is just one example of these types of tactics, vying for experts’ trust in these technologies that were designed with the intention of protecting users against online sabotage.
During the last week, several spear-phishing e-mails were sent to multiple Uyghur activists. Here’s an example:
A snippet of code on the Central Tibetan Administration website redirects CN speaking visitors to a Java exploit that drops an APT-related backdoor. For some context, the site claims the administration itself as "...the Central Tibetan Administration (CTA) of His Holiness the Dalai Lama, this is the continuation of the government of independent Tibet." The selection of placement for the malicious code is fairly extraordinary, so let's dive in.
The attack itself is precisely targeted, as an appended, embedded iframe redirects "xizang-zhiye(dot)org" visitors (this is the CN-translated version of the site) to a java exploit that maintains a backdoor payload. The english and Tibetan versions of the website do not maintain this embedded iframe on the Chinese version (please do not visit at this time). At this point in time, it seems that the few systems attacked with this code are located in China and the US, although there could be more. The Java exploit being delivered is the 212kb "YPVo.jar" (edd8b301eeb083e9fdf0ae3a9bdb3cd6), which archives, drops and executes the backdoor as well. That file is a 397 kb win32 executable "aMCBlHPl.exe" (a6d7edc77e745a91b1fc6be985994c6a) detected as "Trojan.Win32.Swisyn.cyxf". Backdoors detected with the Swisyn verdict are frequently a part of APT related toolchains, and this one most certainly is.
The Java exploit appears to attack the older CVE-2012-4681 vulnerability, which is a bit of a surprise, but it was used by the actor distributing the original CVE-2012-4681 0day Gondzz.class and Gondvv.class in August of last year. You can see the 4681 exploit code in the image above along with code setting the jvm SecurityManager to null to disable Java's policy checks and then running the Payload.main method. The Payload.main method contains some interesting but simple capabilities that enable an attacker to download the payload over https and AES decrypt it using Java's built-in AES crypto libraries, but the package is not configured to use that code in this case. Instead, a couple of lines in its configuration file direct the exploit to drop and execute the jar file's win32 exe resource. The backdoor itself is detected by most of the AV crowd as variants of gaming password stealers, which is flatly incorrect. The related C2 is located at news.worldlinking.com (184.108.40.206).
This threat actor has been quietly operating these sorts of watering hole attacks for at least a couple of years and also the standard spearphishing campaigns against a variety of targets that include Tibetan groups. Our KSN community recorded related events going back to at least a busy late 2011 season. We also show Apple related Java exploits from this server targeting the more recent CVE-2013-2423.
UPDATE 2013.08.13: The CN version of the site at "xizang-zhiye(dot)org" appears to be cleaned up and has not been serving any malicious code that I can find over the past day. The administrators appear to have cleaned everything up on early Tuesday their time/later Monday "western" time and there are no indications of any return since. We will continue to monitor the site for signs of compromise.
Around one year ago I posted about what were the most common web attacks in Spain and how the malware was spread. It is time for an update!
We regularly collect data regarding infected web sites based in our detections on KSN. Apart from the general verdicts that I usually find in the top of the rank, there was another one in the top 3 for the last months that caught my eye: Trojan.JS.Iframe.aeq.
Lavabit was one of the very few secure e-mail service providers bringing security for its paid customers by encrypting all locally stored e-mail messages with an asymmetric key and AES-256. This means that in order to decrypt the messages, an attacker would need to compromise the server first and then to know your password. There was no way even for Lavabit to decrypt emails without a user’s password. A detailed description of how the Lavabit technology worked is available here: pastebin.com/rQ1Gvfy0
While researching PlugX propagation with the use of Java exploits we stumbled upon one compromised site that hosted and pushed a malicious Java applet exploiting the CVE 2013-0422 vulnerability. The very malicious Java application was detected heuristically with generic verdict for that vulnerability and it would have been hardly possible to spot that particular site between tons of other places where various malicious Java applications were detected with that generic verdict. But it was a very specific search conducted back then and this site appeared in statistics among not so many search results. Well, to be honest it was a false positive in terms of search criteria, but in this case it was a lucky mistake.
The infectious website was an Internet resource named - minjok.com and it turned out to be a news site in Korean and English languages covering mostly political events around the Korean peninsula. We notified an editor of this site about the compromise and although he has not responded, the site got closed after a while.
This is how minjok.com is described at http://www.northkoreatech.org/the-north-korean-website-list/minjok-tongshin/:
Description of minjok.com
A new-ish Flash exploit has been on the loose for attacks around the web. This time, the attackers have compromised a caregiver site providing support for Tibetan refugee children and are spreading backdoors signed with Winnti stolen certificates delivered with Flash exploits - the compromised web site is the NGO "Tibetan Homes Foundation". Previously, FireEye identified similar "Lady Boyle" related malicious swf exploiting CVE-2013-0634. A notification has been sent to the contacts of the web site, but apparently the malicious footer.swf file is still hosted at the Foundation's web site, so please do not visit it just yet. Also, be sure to update your Flash player to the latest version.
This site certainly appears to be a classic example of a "watering hole" attack. F-Secure pointed out another Lady Boyle watering hole set up against a related Uyghur group, which has been targeted in tandem following the early March World Uyghur Congress. The delivered backdoors are shown to be signed with Winnti-stolen digital certificates in the F-Secure post, including the stolen MGAME certificate.
Here is an example of those same stolen certs reused for the backdoors in the Tibetan Homes Foundation incident. We see both the MGAME cert and the ShenZehn certs signing the backdoors, here are screenshots of the latter:
Our products detect the Flash exploit+payload as Exploit.SWF.CVE-2013-0634.a. Here is a heatmap of our worldwide detections. Note that not all of these detections are Lady Boyle related, I estimate that at least a third of them are:
Other sites hosting the Lady Boyle swf exploit over the past couple of months have included "tibetangeeks.com", who recently cleaned up their site and posted a cooperative plea to their attackers, and "vot.org" or the "Voice of Tibet" which is also cleaned up. Currently cleaned up but previously serving "Exploit.SWF.CVE-2013-0634.a" were Uyghur related sites "istiqlaltv.com" and "maarip.org", with the same "LadyBoyle" swf path as the Tibetan Homes Foundation, i.e.:
So, what we have is an active watering hole campaign implementing a fairly new Flash exploit and abusing digital certificates that were stolen as a part of the ongoing Winnti targeted attack campaigns on game developers and publishers.
Earlier today, the Laboratory of Cryptography and System Security (CrySyS Lab), together with the Hungarian National Security Authority (NBF), published details on a high profile targeted attack against Hungary. The details about the exact targets are not known and the incident remains classified.
Considering the implications of such an attack, Kaspersky Lab’s Global Research & Analysis Team performed a technical analysis of the campaign and related malware samples.
You can read our short FAQ below and you can download our technical analysis paper linked at the end of the blogpost.
Earlier today, Softpedia reported that an Algerian hacker using the nickname MCA-CRB has managed to deface the Romanian sites of Google (google.ro) and Yahoo! (yahoo.ro).
When we found out about this incident we were pretty skeptical of these websites being hacked. A website as large as Google can be hacked, in theory, but it’s highly unlikely. We then noticed that both domains resolve to an IP address located in the Netherlands: 220.127.116.11 (server1.joomlapartner.nl) – so it rather looks like a DNS poisoning attack.
The question which remains unanswered up until now is where exactly the DNS spoofing/poisoning attack has happened.There are several possible scenarios here: