Spiegel Online uses a 2000 years old cipher for their pay wall

August 3, 2016

Today I cam across some not well done encryption. To be exact I surfed the website of the German news magazine Der Spiegel and clicked on an article that was of the type Spiegel Plus. That type is indicated by this logo:

spiegelplus

Scrolling down after some paragraphs I saw following:

blur_without_javascript

hmmm … funny …. lets take a look in a browser that has JavaScript enabled (as my default one does not).

blur_with_javascript

That’s come kind of pay wall. Lets take a look at the source code of the page with the Firefox Web Developer tools. Using the Inspector and clicking on the blurred paragraph I get to following CSS

blurhmm … lets disable that blur

unblured

Ok readable … but that does not look like German …. but it looks like a ROT13 algorithm, which is  is a simple letter substitution cipher that replaces a letter with the letter x (in the case of ROT13 x=13) letters after it in the alphabet. ROT13 is a special case of the Caesar cipher, developed in ancient Rome. Lets try some ROT variations. As I was just playing around I used a website for this and clicked through it … and I took until ROT25 get readable text.

 

rot25

That was too easy … under 10 minutes to get the clear text. I can’t be the first one … and I’m right … there is a Firefox plugin on Githup.  So it seems this is common knowledge already. Searching the German web I found that one blogger also from Austria already reported it to Spiegel, some Weeks ago … maybe ITIL  does not allow a change ;-).

So to Spiegel, as Andreas already told them, use some real cipher, there are plenty OpenSource JavaScript implementation. And use a different random key for every article, or at least one per day.

 

 

HiKam A7 – IoT security at its worst [Update]

July 8, 2016

[Update]

I’ll reached out to the company which got back to me today and told me that they are working on fixes for the problems.  I’ve also changed my cam from wired to wireless mode today and the app sent the wpa2 password via UDP to the Internet in the clear – I’m glad I used a separate SSID and password for this ;-). I also reported that info to the company.

[/Update]

In my last blog post I’ve written about IoT devices and their bad security and what you can do to mitigate that on a network level – what I didn’t know that I would have such a device in my hands only days later.I did get my hands on a HiKam A7 IP cam, which is at the German Amazon Store the number one product for surveillance cams – so not a nobody. At the end I’ll found 5+ security problems in 2 hours looking at it, but keep on reading for the details. 🙂

hikama7_amazon

As first act I’ve installed the app you need for configuring the cam in the first place. At first start you need to create a user, which should/must be unique per mobile / tablet. Looking at the network traffic I saw a HTTP request to api4.cloud-links.net and guess what was the content of that POST request?

hikama7_app1

Yes, that seems to be the user name and password in an effort to check if the username is already taken. The Pwd parameter is 32 chars long and looks like hex …. that couldn’t be MD5? Lets ask crackstation.net

crackstation

Yes! Sure its unsalted MD5 and the password matches. So here are the first 2 security related errors  … no HTTPS and than unsalted MD5 over an Internet connection.  Something funny – you need to enter the password twice to guard against typing errors … both values are send to the server in the clear …. why not compare them on the client and send the request only if they match? of course also via HTTP and not HTTPS

hikama7_app2So the account is also created with an MD5 password – which leads to the third security related problem …. customer passwords are stored as unsalted MD5 in the database … for years now we should know that that’s bad.

Ok, we got an UserID and soon after the app starts sending UDP packets to Chinese server (cloudlinks.cn) … let’s convert the UserID to hex, maybe we find it again

hikama7_app2_python

and of course we find it again in the UDP packets

hikama7_app3

So the userID is also send in the clear every few seconds and is only a 32bit integer … not hard to guess for an attacker  – third security related error. So this userID seems to be something important, lets call that registration function multiple times with curl and look at the answers.

{"error_code":"0","UserID":"-2144083657","P2PVerifyCode1":"999048728","P2PVerifyCode2":"1551418556","DomainList":""}
{"error_code":"0","UserID":"-2144083654","P2PVerifyCode1":"76169185","P2PVerifyCode2":"196029599","DomainList":""}
one minute wait
{"error_code":"0","UserID":"-2144083636","P2PVerifyCode1":"1008452257","P2PVerifyCode2":"1056609345","DomainList":""}
{"error_code":"0","UserID":"-2144083633","P2PVerifyCode1":"836153359","P2PVerifyCode2":"494065857","DomainList":""}

Oh yeah, the UserID are assigned sequentially for each registration and provided to the user and used later by the client  …. not a good idea .. lets call it fourth security related error

So lets stop looking at the app and take a quick look at the cam it self …. first a nmap scan:

PORT STATE SERVICE VERSION
554/tcp open rtsp?
5000/tcp open soap gSOAP soap 2.8
MAC Address: 4A:81:49:xx:xx:xx (Unknown)
Device type: general purpose
Running: Linux 2.6.X|3.X
OS CPE: cpe:/o:linux:linux_kernel:2.6 cpe:/o:linux:linux_kernel:3
OS details: Linux 2.6.32 - 3.2
Network Distance: 1 hop

hm … RTSP ….. let’s take a look with VLC to check if there is a username/password required

vlc rtsp://xxx.xxx.xxx.xxx:554/onvif1

a7_video

Of course there is no password required, everyone in the same network or who is able to connect port 554 can look at the video (There is no option in the app to configure a RTSP password).  So the next security problem is that there is no authentication required at all for RTSP, fifth security problem. As my router has UPNP disabled I did’t check if the cam would open port 554 on the router.

Interesting, I could not find the MAC vendor – even online. Anyway looking at the traffic the cam sends to the Internet, it seems to talk at once after booting to the same UDP port the app does – even the same IP address, but an other DNS name.

a7_1

a look at the UDP packet shows that the device ID (printed on the cam) in hex is at the same place of the packet as the UserID is:

a7_2

I could find an authentication between the cam and the cloud servers …. but maybe I missed something … but as I’m not 100% sure I’ll won’t count it. 😉

 

Ah there is also a button in the app for a firmware update of the cam …… and of course its HTTP and not HTTPS …. easy code inject? I couldn’t find a signature for the file to protect against it, but I didn’t try it so I’ll also don’t count it.

a7_firmware_update

Here is the link to the firmware file, I couldn’t resist an fast check of the file:

$ binwalk npcupg_13.00.00.90.bin
DECIMAL HEX DESCRIPTION
-------------------------------------------------------------------------------------------------------
32 0x20 JFFS2 filesystem, little endian
2998728 0x2DC1C8 ELF 32-bit LSB executable, ARM, version 1 (SYSV)
3002209 0x2DCF61 LZMA compressed data, properties: 0x03, dictionary size: 524288 bytes, uncompressed size: 196608 bytes

so lets take a look at the filesystem by mounting the jffs2 file system in RAM.

# modprobe mtdram total_size=32768 erase_size=256
# modprobe mtdblock
# dd if=20.jffs2 of=/dev/mtdblock0
5869+1 records in
5869+1 records out
3005295 bytes (3,0 MB) copied, 0,026426 s, 114 MB/s
# mount -t jffs2 /dev/mtdblock0 /mnt/

but that’s for an other time …. the blog post is already really loooooong. There seem to be much more possibilities to hack that cam. It even seems possible to access cam from others, as the authentication is only based on one or two 32bit values. But looking at that more deeply would take more than 2 hours (without writting this post itself)

Ready your home network for IoT

July 2, 2016

I’ll keep reading about the whole Internet of Things (IoT) but something I see missing is the security aspect. Sure there are white papers and article out there how an enterprise should deploy IoT in a secure way, but not much for home and SOHO networks. In this blog post I’ll address the problems of current IoT devices and what you can do to mitigate them.  I’ll concentrate on typical IoT devices used/designed for home users.

Why the security of IoT devices sucks

Just remember one mantra – IoT devices suck at security – and here is the why.

  • Many of these devices are build by Start-ups, which have one goal. Get the product out as fast as possible and get the company bought by someone and hit pay day. Even if not, they need to get enough revenue first and to start than fixing the security problems.
  • If the device is not build by a Start-up than it got build by an established manufacturer in the area the IoT device is build for. The problem is the manufacturer has no idea about connected devices and that Internet stuff – Its called “Neuland” :-). They will make every error the IT industry did 10-15 years ago. Yes, if you’re that long in the business as I’m you’ll see the same security holes you saw in the first years of this millennium for normal PCs now for IoT devices.
  • Usability and security is not easy .. so most of the time the easy to use and insecure variant is used
  • If the IoT device is for a semi established area like IP cams / baby cams the devices are build and designed by a Chinese company and sold under various labels. The company selling the devices does not know anything about the internal workings. If a security problem is found and somehow the OEM vendor in China fixes the problem, you’ll wont get an update from the company that sold the devices.
  • Automatic updates of the devices is not the norm, so most devices wont get any updates. While in the PC marked it is for years now common that  software get updates automatically, the same is not true for most IoT devices. And lets be honest who is checking for security updates of the light bulbs on a regular base?
  • But before we can talk about automatic updates lets don’t forget that for most IoT devices you’ll get updates only for a short period of time. The vendor wants to sell his next product, so why support the old one? To make the problem bigger most IoT will get used longer than a typical mobile phone, which also suck at security update time frames. No one will replace his/her IP cam every 2 years like a mobile phone (ok, that’s also not true, but its typical a shorter interval)
  • UPNP was a bad idea and still is one. Some IoT automatically open ports from the internet so any security flaw can be exploited directly from anywhere in the world. Oh, joy! 🙂
  • Even if the device does not use UPNP it often connects per default directly to a cloud service, over which you (and potentially an attacker) can access your device. e.g. accessing the baby cam via the mobile phone app via and cloud service. There have been some horrible security flaws in the past, like a consecutively numbered ID without password or the MAC address of the device as ID (really heard the guess an MAC address if you know the vendor ID 😉 ).

There are some more points I could made, but these should be already depressing enough.

ps: yes, there are some IoT devices with good security but these are less than 5% of the total market.

Theoretical mitigating the problems

As we’ve established that the security is not good, we need ways to mitigate the problem, within the scope of a home network. To be honest that can’t be done by your typical mum, but needs some one technical minded – but others would not read my blog anyway.

Securing or hardening IoT devices is sometimes possible but for most consumer ones that won’t work. So lets accept that the device will have security problems. In some cases that will be a big problem in its own right, e.g. a IP cam that can be watched from anyone world wide. In other cases e.g. a light bulb that can be controlled from anyone world wide is more a nuisance that a real problem. The same is true for weather station that is readable world wide.

For the first case there is nothing that can be done on the network level as general rule, as disabling the Internet connection for the device will prevent it from working in the first place. Sure there are cases where the cloud connection is not needed, in these you can deactivate or block it. But for the second case there is something. Let’s assume the attacker got access to the IoT device, which is by itself in this example case not that bad, surely a nuisance but not a big problem. The problem arises now from the fact that the IoT device is controlled by the attacker and what he can do with that. So lets look at some possible scenarios.

  • If the device is connected via WiFi the attacker has now the WPA2 PSK key from your WiFi.
  • If the family NAS provides the shares without username/password an attacker can access it
  • Maybe the router can be configured without a secure password or has also a weakness. The attacker can use this to change the DNS servers to allow MiTM attacks
  • ARP spoofing and similar attack are also possible.

To guard against that attacks you need to segment the IoT network from your normal network, even better isolate the various IoT devices from each other.

Practical mitigation – three stupid routers

The segmentation can be achieved in various ways. The first one needs only standard routers …. just more than one … you need 3 routers. Lets take a look at the diagram:

iot_network1

The first router is often provided by the cable or telephone company and you need to buy 2 stupid/cheap routers behind it. One is for the normal internal network and one for the IoT devices that connect a cloud service. For the IoT device router configure the WiFi in client isolation mode (if possible). As both (internal and IoT) routers masquerade their clients a direct connection is not possible. If a connection should be possible a port forwarding needs to be enabled and also make sure that the IP subnets are different.  If one IoT devices gets compromised it can not leak the internal WiFi password as it does not have it. Also accessing the NAS is not possible as the ARP spoofing is not possible. Use the provider router for guest which should not be able to get anything except Internet.

The setup is quite simple and also cheap but has its short comings:

  • Works only for apartments and small houses – if you need more than one access point for you’re house it does not work.
  • You need multiple routers, which need more power.
  • You lack flexibility

Practical mitigation – intelligent router / access points

If you move away from the typical stupid routers you can make use of the more advanced features. The exact setup depends on the used network devices, so I’ll can only show a possible setup. Following requirements need to be met by scenario setup.

  • Three floors, each with its own access point
  • IoT and internal devices in each flow, cable and wireless connect ones (multiple SSIDs on each access point)
  • Clients want to move within the building without loosing connection (same SSIDs on all access points)

Just to make it clear, there are other setups possible to fulfill the requirements. Following diagram shows the possible setup.

iot_network2

The router or firewall (could be a router like a Mikrotik or a pfSense firewall) is the gateway for all 3 networks (yes, I through a guest network in for good measure 🙂 ). On it the policy which network is allowed to connect to which other network is configured. All three networks are connected to the managed switch (if the router has enough ports it may can fulfill the role of switch too).  On the switch most ports will be configured for one VLAN but the ports to the access points get all three VLANs.

The access points get configured in way that the management IP address is in the internal VLAN and a separate SSID is used for each VLAN. All access points use the same SSID for the same VLAN, so roaming for the clients is possible. Set the SSID for IoT and external use to client isolation mode (one wireless client can’t communicate with an other)

Optional, if the the switch supports it. Configure private VLANs for the IoT and external network, so only the router can talk with all devices

I hope this blog post shows you the basics for readying your home or maybe SOHO network for IoT devices which will surely come.

The insecurity of the building automation system KNX

April 29, 2016

Today I’ll write a completely different security blog post to which I normally write. This one is about KNX – I’ll guess most readers (which are largely IT people) don’t even know what it is about. Here from Wikipedia:

KNX is a standardized (EN 50090, ISO/IEC 14543), OSI-based network communications protocol for building automation. KNX is the successor to, and convergence of, three previous standards: the European Home Systems Protocol (EHS), BatiBUS, and the European Installation Bus (EIB or Instabus). The KNX standard is administered by the KNX Association.

tetris1_img6080
(Source: https://laughingsquid.com/tetris-building-hack-at-mit/)

 

Now you’re asking why I’m writing about it and why I wrote it’s a security blog post? The KNX standard is now getting whitely deployed in Tirol in new office buildings and even is used on bigger renovations of these.  Most of these deployments are done by civil and electrical engineer, which don’t think (care?) about IT security. And as it is a network communication protocol and is often connected to the IT network of the company someone in the company should think about it.

KNX Basics

So let’s starts with the basics. The most common form of deploying that network (called KNXnet sometimes only KNX) is over a two wire bus (twisted pair, called KNXnet TP) which is routed in parallel to the 230 V electrical power supply KNXnet connects all devices and systems of the building. To make the list complete following media are possible:

  • TP: twisted pair
  • PL: power line (over the normal 230V lines)
  • IP: Internet protocol
  • RF: wireless

The network speed is 9600 bit/s and following device groups get normally connected to the network:

  • Sensors (e.g. push buttons, wind-, temperature-, movement-sensors)
  • Actuators (dimming units, electrical heating valves, displays)
  • System devices and components (e.g. Line-Couplers, Backbone-Couplers)

Most often the system is used to automate the building (turn all lights of if no one is in the building, move the blinds up and down), but there are also implementations which are more in the direction of alarm systems.  In a security respect that means that everywhere any device, which is connected to KNX networks, is located (outside?) an attacker can get access to the network.  In any case if the system/building is larger the building manager would like to configure the system via his working PC, which leads to a connection to the IT network. This a common case so the “The KNX standard – the basics” shows following diagram:

knxpcAnd yes, you’re reading that correctly, the KNXnet can be tunnelled over IP and therefore over Ethernet, which leads also to following setups:

knxpc2

But lets keep looking at the KNXnet more directly. Setting up the KNX network is possible via 3 bus topologies:
NetworkTopologies
These topologies can be mixed as needed, but no ring is not allowed. As the line and star topology are a subset of the tree topology, the tree topology is the most flexible one and used in most bigger installations. The network IDs of a given nodes is based on its location in the tree (and looks like that 1.5.1), more information can be found here. Following diagram from the “The KNX standard – the basics” shows a full network over various media. The white boxes are the networks IDs of the various devices connected.

knxnetwork

building automation security

As we now know how the system works in basic lets take an overview look why building automation sucks at security.

  • Default passwords: Yes, you’ll see building automations systems in the wild with default passwords. If set a different one it won’t comply to the password policy of the company.
  • No authentication: Be it for users or devices
  • No encryption
  • Management system reachable from the Internet (e.g. for easier support from the vendor)
  • Back door access: Some vendors deploy UMTS/LTE routers and connect via them to the system. This is often done if the system has problems in the first years of the deployment. e.g. most often seen for heading systems … a high percentage seems to have problems in the first years)
  • No separation from the normal PC IT network

And these points are mainly because the building automation is not part of / controlled by the company IT department and therefore not on the radar of the IT security staff.

KNX specific problems

So now lets look at some KNX design problems. KNX providers filters on the line couplers to limit the load on the network. These provide a feature like TTL the field in the IPv4 packets do. But if you use a routing counter of 7, that goes through every filter. This allows to send packets from a subsidiary line (does not matter where you’re connected to the network) to the complete network. You just need to capture a packet (or guess one) which tells all lights to turn off (to show something harmless ;-)) and resend it at a later time with a routing counter of 7 to turn every light in the building of. Spoofing of the network id is simple, just choose one … good luck finding the place where the bad device is – it could be anywhere in (or even outside) the building and it can completely control it. Take a look at following sides from a presentations at BSidesVienna 2014 to get to know many more problems, like code injection to the ETS software and so on. So attacking the IT network over it is also possible .. maybe the ETS software runs in the same networks as you’re other servers? Its really broken from a security stand point.

Hint: KNX for hotels is also quite common and every guest room has access to the KNX network. Just saying – don’t do it 😉

Hint 2: If someone tells KNX provides security features like a password. Reply: Yes – sure …. it’s optional and its a 4 (in words “four”) byte password transmitted in clear text … really hard to sniff or guess  ;-).

KNXnet/IP Secure
At least there is a draft, I’m not sure if implemented so far, for a security extension to KNXnet/IP, which is backward compatible. These extensions should take care about the biggest security problems of KNX. Take a look at following paper and sides.

KNX software

Following software can be used to play with KNXnetworks

Concussion

If you’re in an IT security roll at the IT department you most likely cannot circumvent the installation of a KNX bus, but make sure that the system does not allow any attack vector against your services and systems. Think about it like an external IT network, you need to protect your systems against it (e.g. Firewall, network separation, …) . Make the normal security checks of the devices directly connected to your network (nmap, openvas scans, check used passwords, software versions, ….)  and make sure that its clear (in writing 😉 ) who is responsible for maintaining the KNX network it’s security – its not your.

If you’re a building manager … talk and listen to the security guys from your IT department. They fight every day against attacks and know how to mitigate security problems.

 

 

New RTF macro Malware from the Dridex gang

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.

Details

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:

email

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:

Sub Document_Open()
Dim HGFDSXDSFVV
HCFDSFDSFB = "hel"
VDSFCDSJ = "qweee"

GoTo PQOycAsH
Dim XJwoBhgN As String
Open "JQJLAG.ANU" For Binary As 66

GoTo pKlIahvf
Dim wVyQZrAv As String
Open "CTTBNH.FEB" For Binary As 18
Put #18, , wVyQZrAv
Close #18
pKlIahvf:

Put #66, , XJwoBhgN
...

which then did use WScript.exe  to download a file from

http://wrkstn09.PEORIASENIORBAND.COM/dana/home.php

other researchers report followingURLs:

http://connect.businesshelpa-z.com/dana/home.php
http://wrkstn09.satbootcampaz.com/dana/home.php

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:

Virustotal_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:

dropper

and for the malware itself 10/56:

malware

I normally don’t write about single viruses, but this one is a show case for some opinions I’ve for some time now.

  1. Forget about normal virus detections – sure keep it on Windows system but don’t count on it.
  2. You really need to implemented procedures as described in this early blog post.
  3. 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.
  4. 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.

Blue Code mobile payment – All show and no substance [3. Update]

March 20, 2016

[Update]
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).

[/Update]

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.

First Look

 

bluecode

Looks good, but I saw something additional:

bluecode2

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)
...
#http://202.4.114.227:8080/merchants
...
https://sdk.hockeyapp.net/
https://support.bluecode.com/a/

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
...
https://www.bluecode.com/login
mobile-ca.bluecode.com
mobile-api.bluecode.com
...

Oh, that TLS setup looks not that good:

bluecode3hm .. lets take a look at the certificate …. oh … its the same:

bluecode2

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

  • https://www.bluecode.com/json/support_mobile_app_pages.json and
  • https://www.bluecode.com/json/support_mobile_allgemein.json

return only some text for the App. But the next request is more interesting, it is a certificate signing request (CSR):

blue_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.

blue_crt

Taking a look at that certificate shows following:

blue_crt2

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:

nist

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.

blue_ack

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: /data/data/com.spt.bluecode/app_Certificates/client_certificate_keystore

I copied the file to my computer and tried to open it … I “just” need to get the private key now.

keystore

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 ….

[Update]

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 … 😉

rootcheck

[\Update]

 

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.

 

Block Ransomware botnet C&C traffic with a Mikrotik router

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.

ransomware

Linux part

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

/usr/local/sbin/generateMalwareBlockScripts.py

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 /etc/cron.hourly:

ln -s /usr/local/sbin/generateMalwareBlockScripts.py /etc/cron.hourly/generateMalwareBlockScripts.py

Mikrotik part

Copy and paste following to get the IP address script onto the router:

/system script
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\
\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\
\n# remove the old entries\
\n/ip firewall address-list remove [/ip firewall address-list find list=addressListMalware]\
\n\
\n# import the new entries\
\n/import file-name=addMalwareIPs.rsc\
\n:log info \"Removed old IP addresses and added new ones\"\
\n"

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:

/system script
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\
\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\
\n# remove the old entries\
\n/ip dns static remove [/ip dns static find comment~\"addMalwareDomains\"]\
\n\
\n# import the new entries\
\n/import file-name=addMalwareDomains.rsc\
\n:log info \"Removed old domains and added new ones\"\
\n"

To make the first try run use following command

/system script run scriptUpdateMalwareIPs

and

/system script run scriptUpdateMalwareDomains

if you didn’t get an error

/ip firewall address-list print

and

/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

and

/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

or

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.

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:

letsencrypt

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.)

crl1

crl2

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. 😉

Powered by WordPress
Entries and comments feeds. Valid XHTML and CSS. 77 queries. 0.283 seconds.