SWITCH Security-Blog

SWITCH-CERT IT-Security Blog


Retefe with a new twist

A few months ago, we blogged about the banking trojan Retefe (Blog post in German) that was and still is targeting Switzerland. First off, Retefe is different because it only targets Switzerland, Austria and Sweden (and sometimes Japan). Contrast this to many other banking Trojans, which have a much more global and dynamic target list. Not only that, but the Retefe infrastructure also prevents computers from not affected countries to connect to its systems by using geo-location aware access lists and filters. The second unique property of Retefe is the fact, that it only modifies the operating system by adding a fake root certificate and by changing the DNS server for domain name resolution. After infection, the installer removes itself, which makes life hard for anti-virus software trying to detect a malicious Retefe component or activity.

Since a few days, Retefe is back again with a new twist. It still targets the same countries and the same banks. Not too exciting, the spam campaign has changed. However, in this wave Retefe is picky and only installs itself on selected computers. And some icing to the cake, it also installs another malware called DOFOIL. In this blog post, we give a technical analysis of the new Retefe.
Continue reading


1 Comment

A look at a phishing website

Yesterday we came across a phishing website under .ch where we were able to download the phishing kit. A phishing kit is an archive file which contains all the relevant files for hosting a phishing website. In this case, the archive contained some static HTML, JS and image files for hosting the phishing form, but also a PHP file for sending the data to the perpetrator, and – most interestingly –an .htaccess file. The .htaccess file is a configuration file used by some popular web servers, which allows the user of a website to override a subset of the server’s global configuration for the directory that the file is located in and all its sub-directories.

A phishing website is frequently only accessible from the targeted country. In our case, this was controlled by the .htaccess file which contained a large list of IP address ranges from where it is allowed to access the site. As an incident handler, we often get reports of malicious websites that we cannot verify with IP addresses from Swiss ISPs. An unwary user might think that the phishing website has already been taken down, but that is not the case. The user is just not allowed to access the phishing website from its IP address.

Continue reading

News


IT-Security-Links #61

  • McAfee Labs reports that a new ransomware called CryptoWall uses Tor for communication and demands Bitcoin from the user in exchange for the private key to decrypt the files. “The use of Tor and Bitcoin in this operation make tracing the attackers more difficult” writes McAfee.
  • Firefox version 31 is improving malware detection. Firefox has long been using Google’s Safe Browsing service to check for malicious web sites, now it also checks downloaded files.
  • Isreal’s Homeland Security writes that anonymous hackers have launched DDoS attacks against network infrastructure from Israel. The attacks also affected DNS name resolution on domain names ending in .co.il.
  • The Register writes that Security outlet VUPEN has revealed it held onto a critical Internet Explorer vulnerability for three years before disclosing it at the March Pwn2Own hacker competition. VUPEN makes money by selling exploits to its customers.
  • The Moscow Times writes that Russia’s Interior Ministry has put out a tender on its official government procurement website for anyone who can identify Tor users. On a related note, the Tor team issued a security advisory this week, warning operators of hidden services about attacks to deanonymizing users. And if that’s not enough Tor news for this week, according to the Tor project’s latest annual financial statements (PDF), the US government increased its funding to 1.8 million US dollars in 2013!

German:


4 Comments

Retefe Bankentrojaner

E-Banking ist seit seiner Entstehung ein attraktives Tummelfeld für Betrüger. Oft wird auf spezielle Schadsoftware, auf sogenannte Bankentrojaner, zurückgegriffen, um arglosen Opfern Geld abzuziehen.

Die meisten dieser Bankentrojaner basieren auf technisch betrachtet ziemlich komplexen Softwarekomponenten: Verschlüsselte Konfigurationen, Man-in-the-Browser-Funktionalität, Persistenz- und Updatemechanismen, um einige zu nennen. Im letzten halben Jahr hat sich eine gänzlich neue Variante behauptet, welche erst im Februar 2014 einen Namen erhielt: Retefe. Nur wenig wurde bis an hin publiziert, einer der Hauptgründe ist sicherlich, dass die Schadsoftware nur in wenigen Ländern (CH, AT, SE, JP) agiert und nur einige ausgewählte Banken angreift. TrendMicro (Blogartikel: Operation Emmental (DE), (EN)) und SWITCH-CERT möchten hiermit nun etwas detaillierter über diesen Trojaner berichten.

Das Besondere am Retefe Bankentrojaner ist seine Schlichtheit. Das infizierte System wird wie folgt manipuliert:

  1. Auf dem PC des Opfers wird der Eintrag des DNS-Servers auf einen bösartigen DNS-Server geändert.
  2. Auf dem PC des Opfers wird ein gefälschtes Root-Zertifikat installiert, siehe auch unser kürzlich veröffentlichten Blogartikel zu diesem Thema.

 

Nach der Infektion löscht sich die Installationsroutine selbst. Ausser dem manipulierten System bleibt nichts zurück, was es schwierig für Antiviren-Programme macht, im Nachhinein eine Infektion festzustellen.

An Eleganz ist diese Schadsoftware schwer zu übertreffen: Sie verzichtet auf die in der Einführung genannten Softwarekomponenten und minimiert damit die Komplexität. Es scheint auch, dass es aus Betrügersicht heutzutage ökonomischer ist, schlicht und einfach neue Opfer-PCs mittels Spam-Kampagnen zu infizieren.

Wie sieht der Modus Operandi konkret aus?

Modus Operandi eines möglichen Schadenfalls

Modus Operandi eines möglichen Schadenfalls

Continue reading


2 Comments

Taking Advantage of DNSSEC

According to measurements by APNIC’s Geoff Huston currently 16 percent of Swiss Internet users use a DNSSEC validating DNS resolver. If you want to benefit from the added security with DNSSEC in your network then I suggest you enable DNSSEC validation in your network as well. SurfNet published a deployment guide recently that takes BIND 9.x, Unbound and Microsoft Windows Server 2012 into account.

Enabling DNSSEC validation on your DNS resolvers is one simple step and it protects you from DNS Cache Poisoning. However, if it were only for this, then the DNSSEC protocol complexity would come at a high cost for only providing this one benefit. In fact, DNSSEC is much more than only a protection from Cache Poisoning. It’s a new PKI in DNS and if you have signed your zone and are already validating then you can take advantage of that PKI. Some use cases are described below but there are many more ideas which are currently discussed.
Continue reading


Verbindungsprobleme bei der DNS Namensauflösung erkennen

Die ursprüngliche Spezifikation von DNS-Nachrichten (RFC 1035), welche über UDP gesendet werden, ist auf 512 Bytes begrenzt. Bereits Ende der Neunzigerjahre wurde mit dem “Extension Mechanisms for DNS (EDNS0)” (RFC 2671) eine Erweiterung für das DNS-Protokoll festgelegt, welche es u.a. dem Client erlaubt eine grössere Buffergrösse bekannt zu geben.

Die meisten DNS Resolver-Implementierungen kündigen eine Buffergrösse von 4096 Bytes an. Das heisst aber auch, dass bei einer maximalen Paketgrösse (Maximum Transmission Unit, MTU) von 1500 Bytes eine Fragmentierung der Datenpakete stattfindet. Die Vergangenheit hat gezeigt, dass viele Netzwerk- und Sicherheitsprodukte diese Protokolländerung noch nicht mitgekriegt haben und auf eine kleinere Paketgrösse bestehen. Für DNSSEC ist die EDNS0-Erweiterung eine Voraussetzung, da durch die Signierung der Daten die Paketgrösse ansteigt.

Die Unterstützung einer grossen Buffergrösse von Ihrem DNS-Resolver zur Aussenwelt ist aber auch relevant, wenn Sie keine DNSSEC-Validierung auf dem DNS-Resolver aktiviert haben. Aktuelle DNS-Resolver kennzeichnen die Unterstützung von DNSSEC (durch das DO-bit, Bezeichnung “DNSSEC OK”-bit, RFC 3225) und erhalten deshalb in der Antwort die DNSSEC-Signaturen, auch wenn der DNS-Resolver die Validierung nicht aktiviert hat.
Continue reading


DNS Zone File Time Value Recommendations

When setting up a zone file for a domain name, the administrator can freely choose what time values he would like to set on the SOA record or regarding the Time To Live (TTL) value on the Resource Records (RR). There are already many useful documents describing recommendations for these time values but most lack the reference to signed zones using DNSSEC because at the time these documents were published, DNSSEC did either not exist or had no relevance. We tried to update the recommendations for these time values so that the none-experts can adapt their template or have a reference. Our recommendations work for both signed and unsigned zones and in the best case it helps improve the stability and resilience of the DNS.

Our recommended DNS example.com zone file in BIND format looks as follow:

$TTL 86400 ; (1 day)
$ORIGIN example.com.
@ IN SOA ns1.example.com. hostmaster.example.com. (
                2014012401 ; serial YYYYMMDDnn
                14400      ; refresh (4 hours)
                1800       ; retry   (30 minutes)
                1209600    ; expire  (2 weeks)
                3600       ; minimum (1 hour)
                )

         86400    IN   NS    ns1
         86400    IN   NS    ns2

                   IN   A     203.0.113.10
                   IN   AAAA  2001:DB8:BEEF:113::10
www                IN   CNAME example.com.
ftp                IN   CNAME example.com.

ns1      86400    IN   A     192.0.2.22
         86400    IN   AAAA  2001:DB8:BEEF:2::22
ns2      86400    IN   A     198.51.100.22
         86400    IN   AAAA  2001:DB8:BEEF:100::22
...

Please read the following sections for a more detailed explanation.

Continue reading