Monthly Archives: August 2015

Ins0mnia and NetworkToolbox

You may have heard about about Ins0mnia which is a security vulnerability that allows an iOS App to continue to run in the background, even if the App was terminated by the user and not visible in the task switcher. Security researchers argue that Apps that are using this Ins0mnia vulnerability may even be able access the microphone or camera without your knowing.

As an App developer I can tell you that camera access is not possible in the background and both microphone and camera access will only be possible if a user acknowledged the request to access those peripherals. Without a user confirmation, even an App using the Ins0mnia vulnerability can not access microphone and camera.

But anyways, the Ins0mnia flaw is not good but it’s good that Apple fixed this security issue with iOS 8.4.1 (so hurry, if you didn’t already update).

So what about Ins0mnia and NetworkToolbox ? Can NetworkToolbox detect Ins0mnia ? I would be scared if that could be the case to be honest. Because that would mean that Apps would have access to other Apps out of it’s own Sandbox. This is only possible on Jailbroken devices and that’s why Jailbroken devices are quite insecure.

But NetworkToolbox can indeed help. With the recently introduced Connections Tool you can find out, if one of your Apps “calls home” which means if it sends data from your device to another server on the Internet. As already mentioned, I created a small tutorial which explains how to do that.

But it’s even easier with Ins0mnia because the nature of Ins0mnia is, that it continues to run in the background and also communicates over the network while in the background.

So here is, what you can do (not only to detect Ins0mnia) :

First, you should close all Apps on your device (double tap the home button and swipe all Apps to the top one after the other).

Then, start NetworkToolbox and open the Connections tool. Normally you will see about 10 to 15 connections. If you wait a while and press the refresh button, this number should go down to about five or even three. If you take a look at these few connections, you should only see Apples IP Addresses (those starting with 17), maybe the IP Address of the mail provider you are using and maybe some akamai domains. That should really be all you see after a few minutes. If you see more and different addresses, it’s worth to inspect them because that’s unusual and can be caused by an App using the Ins0mnia vulnerability.

Don’t trust the evil!

Best Regards,

Marcus


New Version 8.2.1 now available

The next version 8.2.1 of NetworkToolbox is now available.

I hope you will be excited about the new features.

Please note: Don’t forget to check for a Data Update also.

iPhone-1
So here is what’s new:


ALDI / MAGINON / Rollei WebCam findings – Update

This is indeed a scary story.

Today, I went to my favorite discount grocery Store (ALDI) for buying some items. To my surprise, they offered PTZ WiFi WebCams for less than 40EUR (about 45 bucks) so at the checkout I asked for a couple of those cameras.

Once back home, I did some quick researching and can’t believe what I found. The camera came with default credentials (guess what: admin as username and blank password) so I started using my NetworkToolbox to explore the HTTP-Head information of the Camera internal web server. The results were:

Content-Type: text/html
Server: mcdhttpd/1.0
Connection: close

This revealed a very ‘good’ string (mcdhttpd) to search for on Morpheus or Shodan with my NetworkToolbox. Quick searches confirmed that the ALDI Camera was in fact the renamed Rollei SafetyCam. (You will agree that this Camera uses a quite misleading name after read further. ALDI must have known the issues as they call it different 😉 )

Both, Morpheus and Shodan found hundreds of such cameras even around the world. Most of them in Germany, Austria, Hungary and Switzerland where ALDI is locaded and seemed to sell this WebCam. Of course, I didn’t try but I am pretty sure that there are lots of cameras using the same default credentials.

UPDATE: Thank you for your reports, confirming that several of those entries are indeed still using the default credentials.

Until now, you might think, “Ok, so I can look into somebody else’s Garden or nursery room or listen to what the say – so what?”

But it gets worse.

The funny WebCam offers WiFi and direct DynDNS support and so it also includes configuration pages for maintaining those credentials. The good thing is, the Camera supports WPA2 PSK AES and TKIP WiFi encryption, the worse is, the PSK Key will be displayed (and likely stored) in plain text. So once you find such a camera, you know how to access the WiFi network of the owner.

Even better, almost the same applies to the DDNS settings. Here, the Password is a secured text field, but the password can easily be read out. So by this, you even know how to connect to that WebCam (and the network!) in the future.

Can this get worse. Yes, it can:

The same security issues apply to the setting for the Mail that the device can send in case of alarms. Mailserver, mail username and password are plain-text or easy to be read out. So we all can be lucky to get more spam in the future, sent from those WebCam mail accounts. Thank you!

So what is my Point?

I contacted Maginon, informed them about these security issues and asked for a statement but got no response yet.

Some screen shots in the Manual contains dates of the year 2012. Likely this was the year when the Camera was developed. Looks as the security standard is even older and it has never been updated.

Very likely, this piece of hardware contains more internal vulnerabilities and security issues.

This is again an example of how a single device can jeopardize your whole network security when added to your network.

Don’t trust the evil.

Have a great weekend.

Regards,
Marcus