Important: This is a new version of the post, which does not contain the name of the website, as the owner removed the code and explained to my why he did it.

As you most likely know I’m running NIDS (Network Intrusion detection systems) to monitor the traffic going into and out of multiple networks. Today I saw a traffic which is normal if one is using VoIP via the Internet – but the source address did not use VoIP at that time.

Together with 2 friends I started investigating. The destination IP address belongs to Amazon AWS … even more interesting. So we took a look at the DNS requests the PC made and that resolved to that IP address, which showed:

stun1.webrtc.us-east-1.prod.mozaws.net

So that originates from the Firefox browser and is connected to WebRTC. So we went to the PC and looked through the browsing history, but the pages looked “normal”, so we started to access them again to find out which one triggers the request. And we found it, visiting thread pages on XXX did trigger the requests. Even more interesting was that we were able to reproduce the requests on a Firebox browser running NoScripts! So we looked at the HTML code of the page and found following:

And at the end there are following lines:

So we did take a look at the HTTP requests made by the client and at the DOM tree and found following:

This shows that the local IP addresses (behind a NAT router) and the external IP address used for the WebRTC request is sent in an JPG image request to the server. This seemed to be aimed at deanonymizing the client, if the user accesses it via a VPN connection. Some weeks ago there was a post about something like this – deanonymizing Tor users – a little searching revealed following page. Looking at the source code there, showed that the most parts are identical, just adding it to the DOM tree was new. The exploit works for Firefox and Chrome currently – Internet Explorer does not support WebRTC so far.

After this findings I did sent an email to the owner of the homepage, asked if this is by purpose or if the homepage got hacked. He responded a day later and explained that it was needed against an attacker. Anyway as some people rely on their anonymity I wrote this post, to get the word out that if you need anonymity you need to take actions – not only for this page but for other too. The code is out in the wide – it will be used and misused.

Solutions:

The best solution is to set the Tor/VPN Tunnel up on the router and not the PC – also for similar exploits in the future.

Fast solution for this is to install a special plugin: Firefox, Chrome (does currently not work with Chrome V40.0.2214.111, as a reader just reported to me – ScriptSafe does) – this is also a good idea if you’re not using Tor or a VPN.

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.

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!

It is HTTP and not HTTPS? In 2014 using HTTP for login? That was even in 2011 bad.

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?

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.

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.

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.

Many people got new debit cards (called “Bankomatkarte in Austria) from the various bankings institutes in the last months and years. Many cards are PayPass enabled for wireless money transactions. PayPass is based on NFC, which is also integrated in some of the modern smart phones. The default setting is that five 25 Euro transactions can be done without entering a PIN. So a possible damage can be up to 125 Euro. You’ll verify if your debit card supports that standard by checking it has PayPass printed on it.

Picture: Maestro PayPass

But I’ve seen some cards with only this symbol (at least on the front side):

Anyway in therapy the card needs to be within 10cm of the reader and therefore an attack is not that easy. But already at Defcon 20 in 2012 Eddie Lee presented the possible of a NFCProxy which allows to misuse a card. The attack setup looks like this:

Picture: Eddie Lee @ Defcon 20

So this allows following attack vector. You’re standing in a crow or in a line and have your debit card in your back pocket. One of the attacker stands behind you …. and the other can be e.g. hundred meters away (only limited by the delay and reach of the network connection). They will be able to get your money with much less risk than with pocket picketing. And to make it even better – you can download the App for Android as an .apk file, ready to install and use, from Sourceforge.

So now you know of the problem, what can you to mitigate that problem?

If you don’t need that feature at all, try to talk to your bank to disable that function. Some will do it for free, others will charge you. Some banks allow to you to choose if you want one with or without at renewal of your card.

You basically like the feature, but you would like to have more control over it – thats also possible:

Search for RFID/NFC blocking sleeves for credit card or payment cards

You can get also wallets with RFID/NFC blocking feature … but currently they look not that great .. at least the ones I found

Originally I only wanted to look at the traffic to check why it took so long on my mobile, but than I found some bad security implementations.

1. The web service is password protected, but the password which is the same for all copies of the app is send in the clear

Just look at the request which is send via HTTP (not HTTPS) to the server. Take the string and to a base64 decoding and you get: client:xxxxxx – oh thats user name and password and its the same for any copy of the app.

2. We collect private data and don’t tell our users for what

The app asks following question “Um in den vollen Genuss der Vorzüge dieser App zu kommen, können Sie sich bei uns registrieren. Wollen Sie das jetzt tun? / To get the full use of the app you can register. Do you want to register now?” at every launch until you say yes.

But for what feature do you need to register? What happens with the data you provide? There is nothing in the legal notice of the app. I’m also missing the DVR number from the Austrian Data Protection Authority. Also a quick search in the database didn’t show anything. Is it possible they forgot it?

3. We don’t care about private data which is given to us

The private data you’re asks at every launch until you provide it, is send in the clear through the Internet. A SSL certificate was too expensive?

4. We are generating incremented client IDs to make it easy to guess the IDs of other users

At the first launch of the app on a mobile, the app requests an unique ID from the server which is not something random and not guessable. No its just a incremented integer (can’t be the primary key of the database table?), at least my tests showed this … the value got only bigger and not that much bigger, every time.

And as the image at point 3 shows that everything someone needs to change the user data on the server for an other user is this number, a small script which starts from 1 up to the 20.000 would be something nice …… the question is what else can you do with this ID? Should I dig deeper?

5. We’re using an old version of Apache Tomcat

The web service tells everyone who wants to know it, that its running on an Apache Tomcat/6.0.35. There are 7.0 and 8.0 releases out already, but the current patch release of 6.0 is 6.0.39 released 31 January 2014. But its worse than that, 6.0.35 was released on 5 Dec 2011 and replaced on the 19 Oct 2012 with 6.0.36. Someone not patching for over 2 years? No can’t be, the app is not that old. So an old version was installed in the first place?

ps: If you’re working with Ubuntu 12.04 LTS package … Tomcat is in universe not main … no official security patches.

This are my results after looking at the app for a short period of time … needed to do other stuff in between

For some time now a mobile app for Andriod phones and iPhones is advertized which is called the official app of Tirol’s Avalanche Warning Service and Tiroler Tageszeitung (Tirol Daily Newspaper), so I installed it on my Android phone some days ago. Yesterday I went on a ski-tour (ski mountaineering) and on the way in the car I tried to update the daily avalanche report but it took really long and failed in the end. I thought that can’t be possible be, as the homepage of the Tyrol’s Avalanche Warning Service worked without any problems and was fast.

So when I was home again I took a closer look the traffic the app sends and receives from the Internet … as I wanted to know why it was so slow. I installed the app on my test mobile and traced the traffic it produced on my router while it launched the first time. I was a little bit shocked when I look at the size of the trace – it was 18Mbyte big. Ok this makes it quite clear why it took so long on my mobile –> So part of the post series will be getting the size of the communication down , so I opened the trace in Wireshark and took at look at it. First I checked where the traffic was coming from.

So my focus was one the 188.40.84.141 which was the IP address of tirol.lawine-app.com and it is hosted by a German provider called Hetzner (you can rent “cheap” servers there). As I opened the TCP stream I saw at once a misconfiguration. The client supports gzip but the server does not send gzipped.

Just for getting the value how much it would save without any other tuning I gzipped the trace file and I got from 18.5Mbyte to 16.8Mbyte – 10% saved. Than I extracted all downloaded files. jpg files with 11Mbyte and png files with 4,3Mbyte … so it seems that saving there will help the most. Looking at the biggest pictures leaded to the realization that the jpg images where saved in the lowest compress mode. e.g. 2014-02-10_0730_schneeabs.jpg

206462 Bytes: orginal image

194822 Bytes: gimp with 90% quality (10% saving)

116875 Bytes: gimp with 70% quality (40% saving)

Some questions also arose:

Some information like the legend are always the same … why not download it only once and reuse until the legend gets update?

Some big parts of the pictures are only text, why not sent the text and let the app render it?

The other question is why are the jgep files 771 x 566 and the png files 410×238 showing the same map of Tirol? Downsizing would save 60% of the Size (with the same compression level)

Why are some maps done in PNG anyway? e.g. 2014-02-10_0730_regionallevel_colour_pm.png has 134103 Bytes, saving it as jpeg in gimp with 90% quality leads to 75015 Bytes (45% saving)

So I tried to calculate the savings without minimizing the information that are transferred – just the representation and it leads to over 60% .. so instead of 18Mbyte we would only need to transfer 7Mbyte. If the default setting would be changed to 3 days instead of 7, it would go even further down, as I guess most people look only on the last 3, if even that. So it could come down to 3-4 Mbyte … that would be Ok, so please optimize your software!

I only wanted to make one post about this app, but then I found, while looking at the traffic, some security and privacy concerns I need to look into a bit closer …. so expect a part 2.

There seams to be a virus wave here in Austria and Germany, don’t really know why but somehow many people click on the links and download the malware. Maybe its because the mail is a faked invoice from some well known (mobile) telecommunication providers and are written in good German – normally spam like this written in broken German. And it seams that the mail passed anti spam systems as I got the some mails on the cooperate account and at home .. normally I don’t get spam mails for month.

Anyway, while I was driving home today it was even in the local radio news .. one of the top items there. And when I was home a relative, which is not that close by called me and asked be how to get ride off that virus. He got infected as initially his anti virus didn’t detected it. I recommend him following link from Raymond. Its a comprehensive list of 26 bootable antivirus rescue CDs for offline scanning. I recommend him to use at least two of the following from the list.

Bitdefender Rescue CD

Kaspersky Rescue Disk

F-Secure Rescue CD

Windows Defender Offline

So if you get asked the same from your relative you don’t need to search further.

Yesterday I wrote about the the information leak at the Railjet Wifi. Today I’m traveling back to Tirol again with a Railjet and I found something other disturbing. I believe its even more problematic as it concerns the mail system. I used a openssl client to check various SSL and TLS connections to my servers, and when I called following:

Hey, my server does not support STARTTLS? I’m sure it does. I did a SSH to a server of mine and checked typed the same command and got my server certificate complete with chain. So something is not right here. I switched to Wireshark (which is running all the time … Ok, I launched it ) and looked at the traffic:

Hey? Thats not my mail server. Its not my IP address and its sure not the mail server software I use. WTF?

Someone is intercepting my SMTP traffic and if my mail clients would use the default setting (use TLS if possible) I would now send my login data (which is for most people the same as for fetching mails) in the clear over an unprotected WiFi. Block port 25 if you have fear of spammers, but don’t force unencrypted traffic over a open wifi.

Anyway whats that profinet.at stuff …. can’t be profi as in professionals. The Whois tells following:

Today I traveled with the OEBB Railjet which provides a free WiFi. As the journey took some hours I had time to look at my networks traces and found something. After the captive portal with the Terms of Services was acknowledged, a page with some infos is shown. One of the infos is the original URL the user requested. If the users clicks on the link a separate tab opens with the page. The problem is that the URL the browser was given to access this info page has following format:

Which is sent as referrer to the original requested page if you click onto the link. As you see this referrer contains the full MAC address of the requesting device. Normally the MAC address is only visible via Layer 2 but with the information leak in my case www.orf.at knows my MAC address and if I have already gotten a cookie, they could add now my MAC to the list of know IDs. Ok, I guess the ORF doesn’t do that, but others might.

A solution would be simple for the OEBB, but until then don’t click on this link – type the URL again.

In my last blog post I have shown how to connect to a PPPoA provider with a Mikrotik router and get the public IP address on the router. I also mentioned that my provider has the bad habit of disconnecting every 8h. As thats not exactly 8h, it tends to wander, but I want at least always the same times. This blog post shows you how to do that if you want the same.

What the script basically does is to force a reconnect at a given time once a day. First we need to make sure that we’ve the correct time on the router. The simplest way to do that is following line:
/system ntp client set enabled=yes mode=unicast primary-ntp=91.189.94.4

But you can only use an IP address there, if you want DNS names take a look hat this script. Also verify that you’ve configured the correct time zone with this command:
/system clock set time-zone-name=Europe/Vienna

Now we need to write the script, which we to in 2 steps. First we create the script ….
/system script add name=scriptForcedDslReconnect source=""

… than we open it in the editor and add the actual code
[admin@MikroTik] > /system script edit 0
value-name: source

After this you get an editor and just copy and paste following lines:
/interface pptp-client set [find name="pptpDslInternet"] disabled=yes
/interface pptp-client set [find name="pptpDslInternet"] disabled=no
/log info message="pptpDslInternet forced reconnect. Done!"

and press CRTL-O. You can now check if all is correct with (everything should be colored in the script)
/system script print

Now we only need to add it to the scheduler
/system scheduler add name=schedularForcedDslReconnect start-time=00:40:00 interval=24h on-event=scriptForcedDslReconnect

And we’re done, it will disconnect always at 00:40, 8:40, 16:40 … as we wanted.