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:

  • Introduction of Public / Private keys

The SSH and SFTP Tools now supports Public Private keys for a more secure connection. As key maintenance is usually not so easy, I also added a separate Tool for maintaining your keys. Finally, you can even generate all kind of keys from inside NetworkToolbox. To encourage more people to use Public/Private keys, I wrote an easy to follow tutorial which can already be found here.

  • A Connections Tool was added

This tool can be used to not only but mainly to identify Apps on your device that are “calling home” or establishing undesired connections. There is also a tutorial called Identify hidden App Communication.

  • Completely renewed HTTP Tool

So far, I was not quite happy with the HTTP Tool. On one hand, it was able to reveal a lot of Website internals but on the other hand it often failed to display websites correctly. This has been resolved now. The HTTP Tool was completely re-written and now feels much more like Safari but still allows to perform the parameter traversal and standard password tests.

  • Improved Traceroute

Traceroute now resolves addresses much more reliable and faster than before.

  • Improved Certificates Tool

The domain names that belongs to a certificate are now listed separately one after the other so you can now easily inspect (e.g. visit) each individual website the certificate belongs to. This is especially useful along with the Connections Tool as described in the tutorial.

  • Other bug fixes and improvements

Unfortunately, in the past, some features did not regard timeout values which caused the App to crash in some situations. Also, an iOS bug caused some Tools to crash when one of the Tool Buttons (e.g. in the FTP Tool) were hit while the keyboard was hidden. All that has been solved now as well as some other minor bugs and improvements as usual.


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 complain that this camera uses default credentials. This is by all means NOT NECESSARY. There are many good alternatives. The simplest would be to request a password change along with the first login. And even if Maginon/Rollei would not be able to fix this security flaw, they should have a big warning in their manual saying “THE FIRST THING YOU SHOULD DO IS TO CHANGE THE DEFAULT PASSWORD“.
  • I complain (even though this is unfortunately common to many devices) that they respond with a unique, easy to identify string on a HTTP HEAD request (mcdhttpd). This fact alone is responsible that thousands of ALDI customers that are on risk now as their devices can easily be found.
  • I complain that they display the WiFi credentials in plain text and don’t encrypt other passwords (DDNS, SMTP Server, FTP, Additional users) so that they can easily be read out with a web browser. This is again simply NOT NECESSARY and INSECURE. I also bet they store them unencrypted (why to encrypt something that is displayed anyways)
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