March 23, 2016
In the aftermath of Locky many companies started blocking EXE files directly attached or in ZIP files on their mail gateways. Some moved further and started removing active content in DOC, XLS, and other MS Office files. Today an old file type got used again and the virus scanner hit rate was really bad again.
The Malware gets delivered by mails with a RTF file attached (which is often used in the medical area), which e.g. looks like this:
The company exists if you check before opening the attachment. Normally bad RTF files did contain EXE files within them, but not this time. This time it contains highly obfuscated macro code, which MS Word executes. which looks like this:
HCFDSFDSFB = "hel"
VDSFCDSJ = "qweee"
Dim XJwoBhgN As String
Open "JQJLAG.ANU" For Binary As 66
Dim wVyQZrAv As String
Open "CTTBNH.FEB" For Binary As 18
Put #18, , wVyQZrAv
Put #66, , XJwoBhgN
which then did use
WScript.exe to download a file from
other researchers report followingURLs:
The file is called
fuckyourself.ass which is in reality a EXE file, which contains the Malware itself. Uploading this (we’re one of the first it seems 😉 ) to Virustotal showed that only 2 virus scanner detected the Malware:
Some hours later and after others saw the file also in the wild and as we reported the file to virus vendors it looks a little bit better, but not good – for the dropper 8/56:
and for the malware itself 10/56:
I normally don’t write about single viruses, but this one is a show case for some opinions I’ve for some time now.
- Forget about normal virus detections – sure keep it on Windows system but don’t count on it.
- You really need to implemented procedures as described in this early blog post.
- It gets more and more important to implement a sand-boxing technology, where all your files which get to you’re company from the internet gets executed / opened. And this means every file .. not only executables. There are also sand boxing technologies that run on premise or in an European data center.
- Bigger companies can mitigate that problem easier, the problem child are home users and small companies.
I don’t have a good solutions for home users so far … maybe someone knows something that I could recommend the Windows home users I know.
March 20, 2016
The vendor contacted me and told me they are working on a fix right now, which should be released shortly. I also got contacted by 3rd parties and they asked if the whole system is broken or not. To make it clear for the non experts. My findings are “easily” fixable and I can’t say anything about the whole system as I didn’t look at it. The vendor has fixed following 2 problems
- bad HTTPS setup for the webservice
- client certificates length (now RSA2048).
Shopping in my local super market I saw an other customer paying with a barcode on the display of his mobile. Looking a little bit around I saw also the ad for it. The service/product is called Blue Code and is from a local company Secure Payment Technologies GmbH based in Innsbruck and is used by some big retail stores.
As you know me, I like to know how stuff around me works and how secure they are. Searching around a little bit in the Internet I didn’t find anything above marketing stuff on how the system works. This intrigued me, as not documented normally means there are some skeletons in the closet. So this post is about the my look into the system.
I normally start with the basics. In this case checking the HTTPS stuff and taking a look at the Android App. Both are done without installing the App on one of my devices.
Looks good, but I saw something additional:
Yes, that’s a wild card certificate. So even if they have an other more secure TLS setup for the payment stuff this certificate would be valid for it. That’s bad security practise. But maybe they use an other domain for the payment stuff or do certificate pinning. So I downloaded the APK. Use this nice site to download the Blue Code APK on your desktop for analysing. APK files are just ZIP files with a special structure, so I’ve extracted the files and took a look at the strings. I took a look at the last 3 versions which I could download.
I found something interesting in the
Blue Code_v1.2.0_apkpure.com.apk (the oldest of the three) …
$ strings classes.dex | grep http
[Copyright (c) 2000-2014 The Legion of the Bouncy Castle Inc. (http://www.bouncycastle.org)
The Bouncy Castle is a crypto library for Java in this case and HockeyApp is for a platform for application development. The IP address is more interesting, it belongs to an ISP from Bangladesh. Hey? The company is from Tirol / Austria – outsourced development? The
Blue Code_v1.3.1_apkpure.com.apk and
Blue Code_v1.3.2_apkpure.com.apk does not contain that string. Also the crypto lib seems to be changed. Anyway the host was not reachable from my computer so I think that’s legacy host that got removed.
So far it seems no other domains are in the App. A search for sub domains shows following:
$ strings resources.arsc | grep bluecode.com
Oh, that TLS setup looks not that good:
So different servers use the same wild card cert … that’s really “good” security practise :-). Are TLS certs too expensive? https://mobile-api.bluecode.com uses also the same certificate and the same TLS setup as https://mobile-ca.bluecode.com (run on the same IP address).
Both hosts look like web services … so I guess the App talks with them, which means the website has a better security than the payment web services? I should look deeper into it.
Note the vendor: Certificate pinning helps only if you don’t use the same wild card certificate for all services, this way if you’re web server gets compromised an attacker can use that for fake your payment webservices.
The setup for a deeper look
Now it is time to look at the traffic the App generates while talking to its servers. Looking at the files packed into the apk file I saw that under /res/raw/ multiple CA certificates (including the CA for the web site and service certificate) got shipped. So I’ll guess there is some certificates pinning done.
So I got my old Nexus 7 out from a storage drawer, and did following to it:
- Unlock Bootloader
- Factory restore with Android 5.1.1
- Rooted it
- Installed Xposed Framework
- Installed JustTrustMe and SSLUnpinnig Modules for Xposed
After that I installed Burp and configured it as an HTTPS proxy on my PC. I’ve already shown how to do that in this blog post. After that I needed only to do following on the tablet:
- configure Burp as the proxy for the Wifi connection
- install the the Burp CA on the tablet
- download and install the BlueCode App.
First launch of the App
At first launch you need to provide a PIN code for something – it was not for what I first thought, but more about that later. After entering you PIN twice the App starts talking with the server.
The two requests to
return only some text for the App. But the next request is more interesting, it is a certificate signing request (CSR):
And there is also a parameter “pin” in the request (salted hash?). Looking at the CSR it seems to be a little short. Anyway the response from the server is a certificate.
Taking a look at that certificate shows following:
I know now why it looked that short, its a 1024 RSA certificate, but signed with SHA256. Someone didn’t understand crypto here. Signing an RSA1024 Key with SHA256, does not make any sense. If you won’t believe me take a look what NIST(National Institute of Standards and Technology) says. From the PDF:
RSA 1024 has a security of lower than 80bit and should not be used for years now!!!
After this request, the next request gets send to mobile-api, with the authToken the App got from the previous request.
This request fails with the HTTPS proxy as the App makes a TLS client authentication, for which my proxy does not have the private key. After some short searching I found it under:
I copied the file to my computer and tried to open it … I “just” need to get the private key now.
Lets stop with looking into the security of Blue Code for mow, as the weekend is almost over and the weather was really good and I needed to go ski montaineering also. But maybe I’ll look later deeper into the system …. So far I found following security problems:
- bad HTTPS setup for the webservice
- wildcard certificates used over multiple servers/services
- client certificates length (RSA 1024bit) which should not be used for years
So many security problems after looking at it only for some hours does not bode well ….
It seems the software has a check that should detect if a devices is rooted …. does not seem to work in my case, maybe I don’t have that directories on my system … 😉
ps: Has someone of you documentation on the protocol of Blue Code? This would allow a high level check and theoretical security check without looking at the traffic.
March 14, 2016
In my last blog post I wrote about blocking, detecting and mitigating the Locky Ransomware. I’ve referenced to a earlier blog post of mine which allows to block traffic to/from the Tor network. This blog post combines both – a way to block Ransomware botnet C&C traffic on a Mikrotik router. The base are the block lists from Abuse.ch, which also provide a nice statistic. Locky is not the most common Ransomware today.
You need also a small Linux/Unix server to help. This server needs to be trustworthy one as the router executes a script this server generates. This is required as RouterOS is only able to parse text files up to 4096 by itself, and the IP address and domain list is longer.
So first we create the script
/usr/local/sbin/generateMalwareBlockScripts.py on the Linux server by downloading following Python script. Open the file and change the paths to your liking. The filename path works on CentOS, on Ubuntu you need to remove the
html directory. Now make the file executable
chmod 755 /usr/local/sbin/generateMalwareBlockScripts.py
and execute it
No output is good. Make sure that the file is reachable via HTTP (e.g. install httpd on CentOS) from the router. If everything works make sure that the script is called once every hour to update the list. e.g. place a symlink in
ln -s /usr/local/sbin/generateMalwareBlockScripts.py /etc/cron.hourly/generateMalwareBlockScripts.py
Copy and paste following to get the IP address script onto the router:
add name=scriptUpdateMalwareIPs owner=admin policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive source="# Script which will download a script which adds the malware IP addresses to an address-list\
\n# Using a script to add this is required as RouterOS can only parse 4096 byte files, and the list is longer\
\n# Written by Robert Penz <[email protected]> \
\n# Released under GPL version 3\
\n# get the \"add script\"\
\n/tool fetch url=\"http://10.xxx.xxx.xxx/addMalwareIPs.rsc\" mode=http\
\n:log info \"Downloaded addMalwareIPs.rsc\"\
\n# remove the old entries\
\n/ip firewall address-list remove [/ip firewall address-list find list=addressListMalware]\
\n# import the new entries\
\n:log info \"Removed old IP addresses and added new ones\"\
and copy and paste following for the DNS filtering script – surely you can combine them … I let them separated as maybe someone needs only one part:
add name=scriptUpdateMalwareDomains owner=admin policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive source="# Script which will download a script which adds the malware domains as static DNS entry\
\n# Using a script to add this is required as RouterOS can only parse 4096 byte files, and the list is longer\
\n# Written by Robert Penz <[email protected]> \
\n# Released under GPL version 3\
\n# get the \"add script\"\
\n/tool fetch url=\"http://10.xxx.xxx.xxx/addMalwareDomains.rsc\" mode=http\
\n:log info \"Downloaded addMalwareDomains.rsc\"\
\n# remove the old entries\
\n/ip dns static remove [/ip dns static find comment~\"addMalwareDomains\"]\
\n# import the new entries\
\n:log info \"Removed old domains and added new ones\"\
To make the first try run use following command
/system script run scriptUpdateMalwareIPs
/system script run scriptUpdateMalwareDomains
if you didn’t get an error
/ip firewall address-list print
/ip dns static print
should show many entries. Now you only need to run the script once a hour which following command does:
/system scheduler add interval=1h name=schedulerUpdateMalwareIPs on-event=scriptUpdateMalwareIPs start-date=nov/30/2014 start-time=00:05:00
/system scheduler add interval=1h name=schedulerUpdateMalwareDomains on-event=scriptUpdateMalwareDomains start-date=nov/30/2014 start-time=00:10:00
You can use the address list and DNS blacklist now in various ways .. the simplest is following
/ip firewall filter
add chain=forward comment="just the answer packets --> pass" connection-state=established
add chain=forward comment="just the answer packets --> pass" connection-state=related
add action=reject chain=forward comment="no Traffic to malware IP addresses" dst-address-list=addressListMalware log=yes log-prefix=malwareIP out-interface=pppoeDslInternet
add action=reject chain=forward comment="report Traffic to DNS fake IP address" dst-address=10.255.255.255 log=yes log-prefix=malwareDNS out-interface=pppoeDslInternet
add chain=forward comment="everything from internal is ok --> pass" in-interface=InternalInterface
If a clients generates traffic to such DNS names or IP address you’ll get following in your log (and the traffic gets blocked):
20:07:16 firewall,info malwareIP forward: in:xxx out:pppoeDslInternet, src-mac xx:xx:xx:xx:xx:xx, proto ICMP (type 8, code 0), 10.xxx.xxx.xxx->104.xxx.xxx.xxx, len 84
20:09:34 firewall,info malwareDNS forward: in:xxx out:pppoeDslInternet, src-mac xx:xx:xx:xx:xx:xx, proto ICMP (type 8, code 0), 10.xxx.xxx.xxx ->10.255.255.255, len 84
ps: The Python script is done in a way that it easily allows you to add also other block lists … e.g. I added the Feodo blocklist from Abuse.ch.
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!
- Ransomware is not new
- 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!
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:
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.
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. 😉
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.
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
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 ….
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.
- Go to a homepage which allows you to login via mobile phone signature
- 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.
- 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
(valid for 5 min.)
- You’re logged in.
- 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.
- 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.
- 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.
- 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.
- The user enters the phone number and password and sends it to the MitM server,
- which forwards the data to the mobile phone signature server.
- The mobile phone signature server sends a SMS to the user,
- which the user enters into the HTML form and sets to the MitM server.
- The MitM servers sends that to the mobile phone signature server,
- 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.
- 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.
Here are some mitigations techniques. From simple to more complicated to implement:
- 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.
- 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.
- 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.
- 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:
- 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. 😉
- 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.
January 7, 2016
Talking with fellows about SNMPv3 I hear often that its not that critical that SNMP is encrypted and that encryption makes debugging more complicated as they can’t see what is send over the network.I won’t talk about the need for encrypting SNMP as it is like SSH gets used instead of Telnet. This post shows how easy it is to decode SNMPv3 encrypted messages with Wireshark (if you know the secrets 🙂 ). This is possible as SNMPv3 is a simple UDP protocol which encodes the packets with a shared secret and does not use forward secrecy like TLS does.
If you take a look on properly encrypted SNMPv3 traffic it looks like this.
Now you just click on “Edit | Preferences”:
Search for “Protocols | SNMP” and click on “User Table | Edit”.
Click onto the “New” button:
Now enter your user name, select the authentication and encryption method and provide the 2 passwords. You don’t need to provide the Engine ID normally.
After clicking onto Ok multiple times the traffic looks like this:
If you use one SNMP profile for multiple systems its nice that the values get stored in the Wireshark preferences. Hope this takes some fear away from SNMPv3. 🙂
January 5, 2016
Why you should not use so called security software, specially if they are “free”, on your mobile? Because they make your security worse most of the time. And no I’m not talking about vulnerabilities in the software itself – sure there a plenty. No there is principle problem as they use ads to finance their software. Why is that bad for your security?
Most big websites like Google and Facebook use today HTTPS for anything you transfer to/from them. But what most people miss is that most ad networks still use HTTP for tracking the user. If you’re just using an app or sometimes even in the background, it sends your information in the clear to the tracking network. Its bad that you get tracked in the first place but in a public WiFi, this information can be used to target and attack you. Lets show you an example.
Lets take a look at 360 Security – Antivirus Boost
And yes their claim for 200 million users seems to be valid
As the app is free they include some ads … e.g. from vungle.com
What is vungle?
Vungle helps mobile application developers promote and monetize their apps through in-app video trailers. They enable developers to get a short, snappy video trailer made and distributed through their in-app mobile video platform. They also generate incremental revenue for developers by displaying video trailers inside of their apps. (Text from CrunchBase)
Lets take a look what their library does – it sends an HTTP post request in the clear
So far so good, but lets take a look at the body, which is a json file.
Oh nice, now we know the location, the mobile phone type, the Android version and the mobile provider. If you know which phone your target uses you now got his/her IP address and Android version for the exploit to inject. For 4.4.2 there should be some easily available. 😉
ps: the NSA does not need to track your location via the mobile operator in a foreign nation … they just look at the internet traffic which goes to AWS cloud to get your location.
Buts not the only ad network which the app includes:
Lets take a look at www.applovin.com .. the homepage looks similar to the first … hmm
Here the HTTP request again
oh, this time no location …. 🙁
“360 Security – Antivirus Boost” is just one test case … most apps which use ads libraries leak such information.
December 7, 2015
So lets start with tips on how to provide a secure public WiFi hotspot part 2. In the first part we concentrated on the wireless part, this time we take a look at the some layer 2 and 3 stuff you can do to protect your hotspot and your clients.
client 2 client traffic again
Yes, I know I’ve written about hat in the first part. But this was on the wireless side. Many access points block the traffic coming and leaving on the wireless interface but not traffic coming or leaving on the wired side. So it is possible to think of an attacker finding it’s victims not on the same access point but on others in the same layer 2. There are multiple way to achieve that once you think about it:
- Lets assume your client networks are all in 10.0.0/16 and you’re servers are in 10.1.0.0/24. You can simply filter with an ALC on the access points or switches which drop traffic where the source and destination host is within 10.0.0/16.
- If you’re using a VPN on you’re access points to tunnel the traffic back to a central controller, just don’t bridge/route traffic between them.
- If it’s one simple layer2 network on one switch, take a look at PVLANs. Many low cost managed switches have this feature.
Enforce DHCP usage
I’ve written a full blog post on why and how to enforce the usage of DHCP in any client network. Its even more important in an public WiFi setting. Following benefits are the most important in this setup:
- Protection against simple ARP spoofing
- That a client configures a fix IP address which an other client got via DHCP – be it by accident or malicious act.
Additionally to the example in the linked blog post, here is one where a Mikrotik router is the default gateway and DHCP server in a client network.
Disable the ARP learning on the router
/interface ethernet set 1 arp=proxy-arp
configure the DHCP server to add dynamic ARP entries
/ip dhcp-server set 1 add-arp=yes
Control the uplink bandwidth
This one is not directly a security point, but without it a user can use up all bandwidth and deny other clients access to the internet. I won’t stop long here, just use something similar like the PCQ on Mikrotiks. This will provide a fair distribution between the clients without looking at the traffic itself and classifying it. So you’re within the net neutrally rules if that matters for you.
Management of your devices
Make sure that no management interface of your devices is reachable via the customer/client networks. The easiest way to achieve this is to use a separate management network and make sure the management services of the devices only listen on this network. For access points it could be as easy as using the untagged VLAN to the switch for management and send the client traffic only as tagged traffic to the switch.
If this is not possible in your setup, make a least sure that a local firewall on the devices allow only administration from specify source IP addresses (e.g. the IP of your central management system, or the VPN IP range you use the remotely log into an router).
no default logins and encrypted management
This should be an no-brainer (but I’ll add it here so no one can say it was not on the list), but I’ve seen access points with the SNMP community
public in the wild. And choose ssh over telnet and HTTPS over HTTP for management. Won’t write more lines about that basic stuff.
monitor the network traffic
Most routers provide plenty of data via netflow or sflow. Capture that with software like Ntop (open source) or a commercial offering. Look at the traffic what is normal and what is not. An example for something like this would be if the average packet sizes goes way down for a client it is likely it is scanning something with a tool like nmap or zmap. ps: Taking a look at the TCP retransmissions also helps to monitor the quality of your service.
After this layer 2 and layer 3 stuff only one part is still open for this series – the application level stuff. Stay tuned.
December 1, 2015
As I was travelling a little bit in the last few months I came across many public WiFi hotspots and most of them where not that good from a security perspective. So I thought lets write some articles with tips on how to build a secure public WiFi hotspot. This article is not for the end user on how to connect securely to a hotspot, but how to provide a secure hotspot.
The first part of this series talks about the wireless part and how to secure it, following posts will talk about other measures to secure your hotspot. So lets start with the security of the data transmitted over the air.
Encyption of the WiFi Traffic
All most all hotspots I cam across did use unencrypted WiFi , the exception where small hotels which used WPA2 PSK on the SOHO Router and told the guest the password at check in. From a security standpoint using WPA2 PSK with one password for all guest is better than an open network. Why do you ask?
- With an open WiFi its trivial to sniff the traffic of other guests and if there are no other protections in the network a man in the middle attack is simply possible. There are really simple to use tools for “normal people” like Firesheep.
- With WPA2 PSK each client gets its own session key during the association process. An attacker needs witness the associaton to eavesdrop on the connection. It is possible my an attacker to force a reassociations, by faking a disassociation packet in the name of the target.The disassociation packet attack is an attack at its own, we’ll talk later about it. With Wireshark you can decrypt all traffic if its sees the association process.
So using WP2 PSK is not perfect but its better than nothing. It is even easy to implement in some cases like in a hotel setting. Put the password in the folder in the guest rooms or tell it the customer at check in / arrival – so you can promote your service too. An other way is to provide two SSIDs one named “Public WLAN open” and one “Public WLAN wps2psk” and tell the user on a captive portal site (if you have/need such an site anyway) to change to the encrypted one for more security.
Ok, that basic security but, you can do better. Some hotels print a username and password on the receipts which you get on check in. You than need to connect to a insecure wifi and need to enter that in a HTTP website. Some hotels also just tell you to use room number as username and your family name or your birthday as password, yes again over an insecure network and over HTTP … ok I’ll stop with the rumpling.
If you provide the user already with a custom login – why not use PEAP or EAP-TTLS to secure the log in. The user chooses the network and gets prompted with an username/password dialog. For this you need to run an RADIUS server against which the Users authenticates, with FreeRadius, which is provided with all major Linux Distributions, its quite easy, even on embedded devices using with OpenWRT. Such a setup is maybe not the best way for a small hotel, but for a big hotel chain, with a central IT department which already prints the login data on the invoices, this should be easily possible. And if the marking persists (the legal stuff could be on the invoice .. as nobody reads the backside anyway) on a captive portal page, just make one where the terms of service needs to be accepted and put some nice marketing images there. 😉
There is also a way for you to use WPA2 Enterprise with PEAP / EAP-TTLS and the newer EAP-PWD if you don’t know the customers and just want to provide a more secure WiFi. Just tell every user the same username / password – as with WAP2 PSK. With FreeRadius its even possible to accept any username / password combinations. With PEAP that works for most clients but not all of them as the returning hash is not correct, but for those the written down username/passwords works. For example at the biggest European hacker congress from the Chaos Computer Club that setup was used 2 times already with over 9000 attendees.
Just to be sure to tell it. The use of PEAP is not recommend for authenticating users for an internal network (e.g. with BYOD) – Why? It is possible to intercept the wireless traffic using a roque accesspoint using the same (company) SSID-name and tools like freeradius-WPE and cloudcracker. But for a free / cheep public WiFi it does seem to an common attack route.
At the end of this chapter I’ll provide you also with a really secure setup (that’s what you want to read if you read my blog? Yeah ;-)), which is not that easy to setup but makes sure you know the user which connect to your network – even if its free to use but you’re required to know the user by law. I’ve not seen this setup in the wild, only told about it by a college.
- Provide an open WiFi which only gets you to an HTTPS page where the user can enter his/her phone number
- Generate a TLS key/cert in a format the mobile browser accepts and encrypt it with an random password
- Send the password via SMS to the user
- Let the User download the key/cert
- Tell him to connect to the secure WiFi with the certificate.
As told above that’s not easy to do … but secure ;-). You can also provide the decrypt password via the HTTPS page, but than you can’t identify the user, but maybe that’s not necessary in your case. This solution is only workable if the user does this once and uses your Internet connection for a long time. e.g. you provide public Wifi in a public transport vehicle for commuters. Otherwise I would stick with the WAP2 Enterprise and EAP-TTLS and as compatibility with PEAP.
rouge access points
Rouge access points in this context are devices an attacker normally uses near your hotspots with your SSIDs to get clients to connect to them. Specially if the WiFI is open or only secured with a know WPA2 PSK it’s easy to do so. Clients which have in past already been connected to your network will often connect automatically to the rouge access point using your SSID. If the attacker does a NAT and connects to your hotspot as client most users will not see a difference and their whole network traffic can be intercepted.
Most enterprise access points provide a feature to at least monitor for rouge access points and alert you if they see your SSID with an BSSID not from your access points. This helps but does not guard completely against it. To get the best protection against that attack you need to use EAP-TLS (certificates for every client – internal wifi setup) oder EAP-TTLS (certificate only for the RADIUS server and username/password for the client). But if the client does not validate the RADIUS server certificate (and there is no common name to check against, only the CA) you can’t prevent that attack, you need to monitor for it and act than.
Following measures can be taken to detect such access points on your network:
- Compare MAC addresses against know vendor IDs. An Apple or Samsung vendor looks more like a mobile phone than a Cisco or Mikrotik one as a client in your hotspot.
- Run an nmap finger print scan against new MAC addresses .. if the OS guess flags it as a WAP, or “Wireless Access” take a look, also take a look at the open ports … telnet and ftp or snmp (with default community) are not common for phones. 🙂
- Look at the traffic with IDSes like Suricata for a X-Forwarded-For field and User-Agent strings associated with proxies
- Detect when one IP address is presenting itself as multiple operating systems e.g. via different TTLs (Linux uses an different than Windows) .. Take a look at this paper and look also at this Linux netfilter module.
denial of service
Depending on the surrounding of your hotspots it is possible that an attacker wants to deny your customers the access to your public WiFi or use the attack to force the client to associate again with the access point to capture the session key. An easy way to do this is to send faked disassociation packets. In 802.11w (rolled up in the 802.11-2012 maintenance release) a protection against this disassociation packets has been implemented and is called protected management frames. Check your access points for support of it. On the client side all modern Linux/BSD distributions support it, starting with Windows 8 the support is also enabled by default.
client 2 client traffic
There is commonly no need for one client to talk to an other client –> block that traffic. Sure you can and should put some text into your terms of service that the user should only connect the network with a secure system and that you’re not responsible for any attack, but there is no harm in providing the user with some additional security against direct attacks and ARP spoofing and there like. Many access points provide this feature, it is often called client isolation –> so that’s a quick win.
dhcp replies / answers
This is connected to filtering client 2 client traffic but I’ve seen that some access points block normal unicast traffic but let broadcast through. With such traffic an attacker can provide the target with an wrong IP address, which is often not filtered by the client isolation feature as it is not within the local subnet and so the access points does not think about it as local traffic. More detail on how I filter that traffic can be found here.
That was the wireless part – I hope it was informative – … the next part will go up the chain to Layer2&3 an application stuff. Stay tuned!
ps: If you’ve ideas to increase the security even more, post a comment! I’m sure I forgot something.