Hypo Tirol – Repeat after me: HTTP is bad, HTTPS is good

January 24, 2015

As I know many friends which are Hypo Tirol banking customers and are using the mobile banking app – and my wife is on a business trip and its dark outside – I took a short look at the mobile banking app for Android. And “Oh my God” the same mistakes banks made 10 years ago with online banking are made again.

I downloaded the app and launched it … I got to following

So what does Wireshark tell me after the I started the app?

Yes, there is some (most part) HTTP … so lets open the URL on my PC.

so the whole starting GUI of the banking app is transferred from the server via HTTP.

Attack vector

An attacker can use this to change the content to his liking and as the URL is not shown in the app it could be anything. An idea would be a site that looks like the banking site. The link “Mobile Banking” goes to the HTTPS URL

https://mbp.banking.co.at/appl/mbp/login.html?resource=002

The attacker just can copy and paste the pages and change the links, so it looks identical for the user ;-). So the only question remains – how an attacker can change the content:

• The DNS servers return the IP address of the attacker for mobile.hypotirol.com
  • there are many know worms that change the DNS server settings of consumer internet routers
  • DNS poisoning attacks … seen in the wild for banking attacks
• A Man in the Middle attack on a public Wifi, but the first two are much easier and can be exploited remotely.

Fix

Use HTTPS everywhere – no HTTP. And check the certificates.

Dropbox notify feature leaks information

January 20, 2015

While I was routinly looking with Wireshark through traffic … everybody needs a hobby 😉 … I saw something interesting. One client was sending a HTTP GET request every 55 seconds. Looking at that request showed following:

which leads to following response normally:

But lets take a look back to the request. This is the Dropbox client doing requests for checking if some other host changed a file. The problem is that it is HTTP and not HTTPS and the user_id and host_int is send in clear text as GET parameters. With this it is easy for some party that sees much of the traffic to track a user over networks and devices. Ok that can also be done via cookies as the Snowden documents show, but they are not send every 55 seconds even if you don’t surf the web – the client does that in the background all the time – a wonderful tracking beacon.

I find that a bad security practice as with HTTPS there would be no information leak and as the SSL connection could also be persistent as the HTTP connection already is, it would be no big additional load on the servers. Anyway – even if HTTP would be a must, it should be POST and not GET, as the GET parameters are stored in proxies servers (e.g. in a transparent ones)

Do not rely on Windows DHCP server logs as security logs

January 18, 2015

Many companies I know backup their DHCP log files so that they are able to but a MAC address to an IP address seen in an security incident. Sure it is possible that an attacker uses a static IP address, but more often than not is a dynamic one – just because it is easier or he does not posses the privileges to change it. Even if you’re using a simple MAC address based network authentication solution you’ll have log files which ties the MAC address to a specific Ethernet port and so a physical location.

So far so good, but there is a problem with this setup and the Windows DHCP server (at least in 2008R2 and newer) – I didn’t check other server. Lets take a look at the log file and how it looks normally.

Microsoft DHCP Service Activity Log
Event ID Meaning
...
10 A new IP address was leased to a client.
11 A lease was renewed by a client.
...
ID,Date,Time,Description,IP Address,Host Name,MAC Address,User Name, TransactionID, QResult,Probationtime, CorrelationID,Dhcid.
11,01/16/15,00:00:15,Renew,10.xxx.xxx.xxx,coolhostname.domain,940C6D4B992E,,373417312,0,,,

So we’ve a renew here and we’re able to tie the IP address to the MAC address. But sometimes you’ll see entries like this:

11,01/18/15,09:00:55,Renew,10.xxx.xxx.xxx,,1049406658305861646638,,2351324735,0,,,

or
11,01/18/15,12:49:12,Renew,10.xxx.xxx.xxx,coolhostname.domain,4019407634303263415422,,2657325422,0,,,

That does not look like a MAC address? Whats that?

I’ve seen this with some embedded devices and a Fedora 21 client. This put me on the right track. Following Bugzilla entry explains the problem:

“In Fedora 20, it sends a client identifier, and that client identifier is equal to the MAC address of the interface. This is recognized by the DHCP server’s static configuration and the Fedora 20 client gets an IP address.

Fedora 21 now sends a different client identifier that is not equal to the MAC address of the identifier. This new string format for client identifier doesn’t match anything in the static configuration of the DHCP server so it fails to get an IP address assigned.”

“Same issue here. I can confirm “send dhcp-client-identifier = hardware;” fixes the issue. DHCP server is a microsoft windows server and there’s nothing I can do to change its configuration.”

To see the difference in various DHCP packets I’ve some screenshots for you:

A DHCP request without a client identifier:

 

A DHCP request with a MAC address as client identifier:

A DHCP request with a non MAC address as client identifier:

To summaries it – devices can use the MAC address or an UID to identify with the DHCP server. The problem now is that the Microsoft DHCP server does not log the MAC address anywhere and you won’t find the UID in your network logs. But as you see all requests have the client MAC address in the packet – Microsoft just does not write it into the log.

Whats funny is that the column in the Windows DHCP server log is called “MAC Address” but there is sometimes no mac address. A discussion with the Microsoft Premier Support reviled that this is a indented feature and no bug. 😉

The insecurity of the online version of the Tiroler Tageszeitung

January 17, 2015

This is the first post in over a month, why? As always I was at the Chaos Communication Congress in Hamburg and as I came back there was finally snow –> so I went ski mountaineering. Anyway here is new post, as today its raining so let’s write a post. 😉

This post is about the lack of security awareness at the major tyrolian news paper Tiroler Tageszeitung (in short TT). So lets start why I believe that is true. To be more accurate what I found within 5minutes of looking – it took much longer to write this post.

The subscriber area

When you access http://user.tt.com/ you get following Login prompt.

But look above ….

Yes, this site is not HTTPS protected. This is generally not a good idea as an attacker is able to change the URL the passwords are sent to after pressing the login button. But Ok, in 2011 that was not that bad, bad but not that bad. Why I talk about 2011 I’ll tell you later.

So lets enter our mail address and password and click the login button. What request is send?

Yeap!

1. It is HTTP and not HTTPS? In 2014 using HTTP for login? That was even in 2011 bad.
2. They are using HTTP GET with the password as parameter. I can’t believe it. Why? GET parameters are logged on web servers and even worse on proxy servers.  Newer, Newer summit passwords with GET, use POST and use HTTPS!

So  reading the online TT while waiting for something in a public WiFi network (which is most likely unencrypted)  is not a good idea. How many TT users are reusing their password (the email address is a given) ? How may users a potentially affected?

At least I’m able to answer the second question.  There is the Österreichische Auflagenkontrolle (ÖAK) … which counts how many copies of a given print media are sold.

Thats from 2012, the ones from 2013 are sightly smaller but not that formated that nicely for showing a screenshot here. So over 80.000 affected users. The state of Tirol has about 720.038 citizens according to Wikipedia. So over 10% of the population is affected.

The server side

While looking at the get request I found something else interesting.  At least the user.tt.com server seems to be running Debian Lenny.

Why is that important? Let’s go to the Debian Wiki and have a look.

Yes, you read that correctly. No security updates since 2012 and it I believe nobody installs a system with a operation system that is old-stable, the server install and setup must be at least be from 2010.  So lets take a look what vulnerabilities be could possible find for Apache 2.2 and PHP 5.2.6 patched the last time in 2012.  Let’s have a look at PHP first and followed by Apache. Apache is better than PHP, but for PHP there are some pretty high rated vulnerabilities, one even with the highest rating. Basically you can get everything from the box if you want. When I took a look which JavaScript made the HTTP GET request with the password I found following.

jQuery 1.7.2 that sounds old …. a look at the release notes tells 21.3.2012, not new but only a medium vulnerability … attacking PHP is easier.

Basically we could own the user.tt.com server easily, but whats about the other servers. Are they better? What is obvious from the start that the servers for the main site are different ones and they are using Varnish as is an HTTP accelerator and the learned to hight the Apache version in the HTTP header.

A short look in the Whois shows that the user.tt.com seems to be hosted by the TT itself and the frontend server for www.tt.com by the APA guys. It seems that they are filtering the bad stuff from the backend TT servers. As I didn’t want to dig deeper than whas possible in 5 minutes I stopped here … Just one thing I found which is not security related: tt.com is heavy using Google services for example Google Analytics.

The option _anonymizeIp() is missing here to not violate the Austrian data protections law and you need to post a information for your visitors (could not find one on tt.com) and make a opt-out possible.

So much for my 5 minutes analytics of the Tiroler Tageszeitungs homepage. 😉