Stop panicking about the Locky ransomware [Update 2]

February 22, 2016

Almost everyone in the German speaking media and many IT professionals are running around like a bunch of scared chicken because of the Locky ransomware. Stop that! And think!

1. Ransomware is not new
2. Ransomware with correctly implemented crypto is not new

I really don’t understand why this ransomware is hyped that much. You just need to implement the security procedures you should have already implemented years ago. Following list shows what security procedures would help in this case and most of them should already be implemented in your company. All are not specify to Locky and will help you against many other malware.

Blocking the infection

• Force a HTTP and HTTPS proxy and block .exe downloads
  That is really simple to implemented even for small companies. e.g. Untangle supports that. You can opt to not scan e-Banking sites if this is a concern.
• Block direct internet access except over the proxy
  Make only exceptions for specify IP addresses or domains. Every enterprise Firewall allows that, if you’ve only a router currently think about using something like Untangle or pfSense(Open Source).
• Remove or block mails with DOC, XLS or PDF attachments which contain macros.
  If a user really needs that file with macros he can request it from the IT department. If you’re using Open Source software as your mail gateway take a look at ExeFilter. Otherwise take a look at your commercial product or talk to your email service provider.
• Enforce prompting before MS Office runs a macro
  MS Office allows you to configure that before executing a macro the user gets prompted. You can configure that also via GPO or OCT. Make sure the user can’t deactivate it and if you need internal macros/scripts sign them by your internal CA.
• Block access to Tor nodes
  Why should a user from your company network need to access a tor node? Block that on the router or proxy. Sometime ago I’ve written about doing that with a Microtik router. The script can be easily modified or any other router or firewall which allows configuration via the CLI.
• Use application whitelisting
  As with firewall rules long ago we currently only block bad files (blacklisting) but on the firewalls we’ve moved to whitelisting (only allow the configured good stuff) years ago. Its time to move to the same method for exe files on your Windows systems.  If you’re using a central software deployment it is also not that difficult:
  • Allow everything that is installed in folders that only a local administrator is able to write to (e.g. c:\windows or c:\program files)
  • Allow digital signed files (e.g. everything from Microsoft, Google, Cisco)
  • Block everything else.
• [Update]Block AD networks
  I really have forgotten that point, sorry. Block ad networks, they are used to inject malware via the browser. On the computer itself I recommend uBlock Origin for Firefox and Chrome. Some proxy server allow to filter the ads already there, if that feature works ok, enable it also there. [/Update]

Detecting an infection

• Network Intrusion Detection System (NIDS) or Network Intrusion Prevention System (NIPS)
  A NIDS will be able to alert you to suspicious DNS queries or access to tor nodes.  If you’re fast enough in reacting to the alert you can disconnect the computer from the network. A NIPS can be able to block some stuff put it is still possible to get through sometimes, so fast reaction is also recommenced here. pfSense and Untangle both provide that functionality.  Security Onion is an alternative.
• [Update] Run a software that detect typical ransom malware behavior
  By it’s nature ransom malware must behave a certain way. It creates many files and deletes many files at the same time, which is not normal for most programs. Following free software, currently in Beta, detects that.[/Update]

Mitigating an infection

• No working under administrator accounts
  The users the employees use for their day2day job must not be in any administrator group. This is also valid for your IT administrators, they need secondary users with higher privileges (and different password and not stored).
• Make sure the file servers have snapshot activated
  This is a feature of modern file servers, just take a look at FreeNAS. Its important that removing the snapshots cannot be done by normal users. (Windows Server allows that sometimes!). This features allows you to go back to the state fast without needing a restore from backup.
• Make and keep offline backups
  As the headlines says … make sure you’ve backups that are outside the reach of the malware and also make sure the restore works before hand.
• Least necessary privilages
  There should be no normal user (even not the IT administrators) that is able to access all file server shares. Use special admin or service users to privileged access.
• Block client 2 client traffic
  Make lateral movement for the malware impossible by blocking client to client traffic. Most clients don’t need to talk to each other and if they do its most likely something like RDP but not the windows file sharing stuff.

These procedures where just top of my head and I’m sure I’ll got more if thought a little bit more about it. In summary: Locky is no problem to you’re organisation if you did your homework. If not –> do it now!

Setup Let’s encrypt TLS certificate for Proxmox [Update]

February 21, 2016

The graphical interface of Proxmox runs on port 8006 and uses HTTPS. By default this is a self signed certificate, which is a problem if you login in from a client the first time. In this case you’re not sure if there is no MitM attack going on. But there is a solution for this by using Let’s encrypt.

First you need to install git

apt-get install git

download the client software

cd /root
git clone https://github.com/letsencrypt/letsencrypt

and now you need to “patch” it as with running containers the check for a free port 80 most likely fails as a container with a running a web server is quite common. Open this file /root/letsencrypt/letsencrypt/plugins/util.py with an editor and place

return False

as first command in the already_listening method. Make sure that it is aligned with the line above and below as Python requires that. It should look this:

ps: If you started to read this article after calling ./letsencrypt-auto the first time you also need to patch following file the same way.

/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/letsencrypt/plugins/util.py

[Update] In the newer version the client is called certbot and so the path got changed to

/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot/plugins/util.py

[/Update]

Now make sure that Port 80 is not firewalled and therefore reachable from the Internet and call following command:

cd /root/letsencrypt/
./letsencrypt-auto certonly --standalone --standalone-supported-challenges http-01 -d <dnsname>

Replace with the <dnsname> with the dns name you use to connect to the management Web GUI. If all worked, you should see following:

IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live//fullchain.pem. Your cert
will expire on 2016-05-21. To obtain a new version of the
certificate in the future, simply run Let's Encrypt again.
- If you like Let's Encrypt, please consider supporting our work by:
....

Now only saving the old certificate with these commands …

mv /etc/pve/pve-root-ca.pem /etc/pve/pve-root-ca.pem.orig
mv /etc/pve/local/pve-ssl.key /etc/pve/local/pve-ssl.key.orig
mv /etc/pve/local/pve-ssl.pem /etc/pve/local/pve-ssl.pem.orig

and copying the new ones to the correct place …

cp /etc/letsencrypt/live/<hostname>/chain.pem /etc/pve/pve-root-ca.pem
cp /etc/letsencrypt/live/<hostname>/privkey.pem /etc/pve/local/pve-ssl.key
cp /etc/letsencrypt/live/<hostname>/cert.pem /etc/pve/local/pve-ssl.pem

followed by a restart of the processes:

service pveproxy restart
service pvedaemon restart

is open.

The last 5 commands are needed, because the special file system Proxmox uses for /etc/pve does not support symlinks. You need to execute that 5 commands after each renewal. The option for this is “renew”. You can/should automate the renew process.

Tips on how to provide a secure public WiFi hotspot – Part 3

February 4, 2016

This the last part of the the series “tips on how to provide a secure public WiFi hotspot”. In the first two parts we concentrated on the wireless and layer 2 and 3 part, this time we take a look at the application layer stuff you should tune to provide a secure hotspot.

Captive Portal and non HTTP traffic

If you want or need to show the user a website before he is able to surf the web, you should not only think about redirecting HTTP to your landing page.  You should reject (send an ICMP error) for all other TCP connection attempts. Why? Many pages are nowadays HTTPS and letting the user wait for a time-out is not nice. Sure technical minded user will not wait, but others may do. Sure this is not a security advice but an usability one. But it does work nice together with following: Don’t try to provide your own TLS certificate to redirect traffic to the captive portal. Users should not be trained to accept error messages and ignore them and it will give your hotspot an bad look security-wise.

There is just nothing you can do to redirect HTTPS URLs. Just make sure that the captive portal detection of modern operating systems work and so the user is told there is a captive portal.

HTTPS for captive portal

If you require any data from the user except accepting the terms of service your captive portal should be HTTPS.  Get an official DNS name for your portal, e.g. portal.<company>.com and a valid TLS certificate. As there are multiple methods for getting free TLS certificate e.g. startssl or let’s encryt, you should get a real one. One thing that is important to whitelist for your captive portal are the OCSP and CRL URLs of your certificate, issuing CA and root CA. To check for the URLs look at the certificate details for all certificates in the chain of your captive portal. Following images show the 2 places for google.com (you need to check also the Google Internet Authority G2 and GeoTrust Gobal CA in this case.)

Why, you ask, you should whitelist these URLs? The browsers will check them before showing your captive portal site. Some/Most browsers will fail open, but some will fail close.

Limit and monitor the DNS

If the user has not past the captive portal his only way though the firewall will be the DNS server. You normally need to resolve the requests to the true IP address to guard against problems with false cached DNS entries after the user past the captive portal. As the user is able to craft the requests as he likes it is possible to send data through to a 3rd party DNS server. This setup can be used as DNS tunnel – it will be not fast but its possible to work through it. As nowadays simple howtos like following and OpenSource tools are provided, consider it easily possible for most power users – its not a expert thing any more.

So now comes the question what you can do against it. In this case you don’t need to block the covert channel of sophisticated malware but just script kiddies that want to tunnel through. Your typical user will only need A and AAAA query types. Tunneling is mostly done via TXT as it allows big packets. Following query types are common:

• Any
• A
• AAAA
• CNAME
• MX
• NS
• SOA

I won’t go into too much detail, but blocking can be done on the DNS server … e.g. if it is a Windows DNS Server (Allow only certain QTypes) or with the Firewall in this case iptables.

Content Filtering via DNS

Often you’re required to filter certain traffic but don’t want to setup and maintain a transparent proxy or with all the HTTPS it does not help that much any more. An easy way is to use the OpenDNS system, which allows to select certain categories which are then blocked on the DNS level (Query will resolve to an error page) . If you redirect all port 53 traffic to your DNS server which uses the OpenDNS ones as recursive DNS servers you should be good for most cases.

SMTP

Just reject (blocking lets the client run into timeouts) TCP port 25, otherwise infected client systems will flood your bandwidth with SPAM mails.  A mail agent should not send mails to the mail server via port 25 anyway.

I hope this article series helped you and leads to more secure hot spots I’m also able to enjoy. 😉

Austrian Mobile Phone Signature is vulnerable against phishing and MitM attacks

February 1, 2016

Update: As some people asked. I’m not saying that the mobile phone signature is not good. It is much better than simple username and password and it protects against attacks that work against username/password. Specially as many users reuse their passwords.

Talking with various people about the Two Factor Authentication (2FA) which is used in Austria to access public services led to my impression that most people think that the system is really secure. While it is more secure than a simple user/password combination its by far not that secure. In this post I’ll show how a simple phishing and man in the middle attack can be performed.  This is no 0day attack or something that runs through the media, it is just showing a design weakness which is not toughed up by mitigating techniques.

For your information: Most attackers don’t use 0days to get into systems, (spear) phishing is much easier and cheaper. The problem is that most companies and government agencies don’t take it seriously – as this case will show.

After showing the attack, I’ll provide methods to mitigate that kind of attacks – some are really easy and I don’t know why there are not deployed.

Background

Some text parts from the offical “Mobile Phone Signature or Citizen Card” webpage. The “important” parts are highlighted:

There are two alternative forms of the Citizen-Card functionality:

• Mobile Phone Signature: This requires a ready-to-receive mobile phone. The Mobile Phone Signature works with all mobile phones and is free of charge.
• Smart card: This requires a smart card with activated Citizen Card functionality (e.g. e-card) and a smart-card reading device.

Both alternatives can be used for the creation of legally valid signatures in online procedures. These signatures are legally equivalent to handwritten signatures. This way, the mobile phone and your activated e-card become your virtual ID, which can be used quite similar to your driving license. You have also the possibility to sign documents or invoices electronically with your Mobile Phone Signature or Citizen Card.

Yes you read correctly it is a qualified signature – which is:

The highest quality level for an electronic signature. Electronic Signature Act (SigG) § 4 declares that a qualified electronic signature is the legal equivalent of a written signature (with only a few exceptions such as e.g. Notary records).

So if an attacker is able to fake the signature he can get really far …..

Claims by the operator

From their  offical “Mobile Phone Signature or Citizen Card” webpage:

Mobile Phone Signature and Citizen Card are particularly reliable methods to identify oneself on the Internet. Both provide high security against

• theft of access codes (such as phishing)
• attacks through the network (Man in the Middle)
• attacks on the computer (for example viruses)

…. hm that’s bold …. we should take a look at it ….

Basics

There is no legal difference between the signatures so most citizens by far took the easier and cheaper one, which is the mobile phone signature. So lets take a short look at how the mobile phone signature works from the user perceptive – which is enough for our purpose and attack.

1. Go to a homepage which allows you to login via mobile phone signature
   
2. After clicking on the “Mobile BKU”, I need to input my phone number and my signature password. The darker grey area is provided by the https://www.handy-signatur.at/mobile/https-security-layer-request/ website and not by the site I want to access.
   Update: Some sites redirect to www.handy-signatur.at and some include it as an iFrame.
3. If these entries are correct I get a SMS, which contains a TAN which I need to enter into the website. The SMS looks like this:
   mobile phone signature
reference value: yt7Zqb8aTZ
TAN: 3As3Rz
(valid for 5 min.)
   
4. You’re logged in.

 

The attack

This attack assumes that the user is using a separated device to receive the SMS … otherwise the attack would be even easier. Following diagram shows the steps need to impersonate a user.

1. The attacker sends a phishing email to the user. To make it more real lets be more specific. The attacker tells the user that there is something wrong with his taxes and that he needs to log into “finanz online” (tax and revenue office online portal) to fix it.
2. The user clicks onto the link “finanzonline-bmfgv.at” or “finanzonline-bmf.at” which looks like the real one and even has a HTTPS certificate. How?
   Getting a domain validation certificate (and often free e.g. startssl or let’s encryt) is really simple and the domains are still vacant.
   
3. The Man in the Middle (MitM) server requests a page from the site we want to log into. It is not necessary that this is the “finanz online” site. It can be any other which uses mobile phone signature and the users has access to. The request/response are needed to get the correct link/parameters for the request to the mobile phone signature server.
4. The MitM server sends the user a fake “finanz online”. The mobile phone signature frame is relayed through the MiTM server which changes the traffic accordingly.
5. The user enters the phone number and password and sends it to the MitM server,
6. which forwards the data to the mobile phone signature server.
7. The mobile phone signature server sends a SMS to the user,
8. which the user enters into the HTML form and sets to the MitM server.
9. The MitM servers sends that to the mobile phone signature server,
10. which redirects him to the side he wants to get to.
    Important: That does not to be the site used for the phishing, as the SMS contains no information for the user to which site he authenticates.
11. As nice add-on …. provide the user with a page that reports that the email was send in error and that everything is ok with his taxes.  😉

That’s not that complicated … it is done against online banking sites every day of the week and the mTAN for a banking can not be used for various other sites and so trick the user into thinking its only a “unimportant” site he is loggin into.

From the claims of the operator the first 2 are not true. And also the third is not valid, everything an attacker is able to do via a phishing attack is also possible via malware on the computer. He just needs to install his own CA onto the system and is so able to redirect the traffic to its own servers. In this case the attacker does not even need to register a domain or an official TLS certificate.  So all 3 claims are not correct.

Mitigation techniques

Here are some mitigations techniques. From simple to more complicated to implement:

1. Tell the user in the SMS to which service he is authenticating for.
   This allows the user to make sure his authentication is used for the service he wants to sign in.
2. Write the IP address and/or the provider name in the SMS to the user. Also add the country the IP address belongs to.
   If I’m a Telekom Austria or UPC customer at home I know that, or at least I know that I’m not a China Telekom customer.
3. Send an email to user that he is used a new ISP, if the IP address is from an AS that does not match any old one.
   This way the user at least knows that something wrong happend and is maybe able to prevent something or go the police.
4. With cooperation from the Austrian mobile phone providers it is possible to check if the phone is currently registered in the same country as the computer (SS7 network).

Following techniques need software on the computer:

1. Provide a browser add-on which stores a secure hashed version of the signature password and checks every browser edit field if the mobile phone signature got entered into an 3rd party website. This also makes sure that the user is not using the password e.g. for facebook. 😉
2. Browser add-on connects periodically (e.g. at the start of the browser) to the mobile phone signature server. If a login is performed from an other network/country block it or warn the user in the SMS.

All of the above won’t prevent all possible phishing attacks, but they will make them much much harder! As written in the beginning of this post, this attack is not some remarkably new one. It’s just about thinking the attack vectors through and some mitigations against them. I hope this post leads to a better security of the mobile phone signature server and all users and provides which use it.