Patch released for major Man-in-the-Middle attack on iPhones and iPads that allows hackers to intercept communication. Mac desktop patch to follow.
I was brought an iPad 2 today that was on and running, but for some reason the power and home buttons were not working right. Pressing or holding the power button did nothing. Hitting the home button would not take you back to the desktop, but oddly enough it seemed to take you back a screen in the settings page. So it seemed that the Home button was still functioning at some level.
Searched the internet and found that this has happened on many iPads. One person suggested to hold the Home button, then rotate the tablet from portrait to landscape mode. Though it seemed to work for many people, it did nothing on this one.
Finally I had to hit and hold both the Power and Home buttons for like 15 seconds and the unit finally returned to the desktop. I hit the Home button twice to see what was running. There were about 20 programs open!
I closed them all and rebooted the iPad.
Simply opening a specially crafted e-mail on a Mac, iPhone or iPad could allow a remote attacker to hack your network, according to security specialist Bogdan Calin.
In the video above Calin shows a feature that Apple products have enabled by default that a hacker could manipulate to gain access to your computer’s IP address. With this information, a script can be written that automatically attacks your router’s DNS settings. Doing so would allow a hacker to control what websites that you see when you are surfing the internet.
All from an imbedded script hidden in an innocent looking e-mail:
“I got the idea for these tests after I noticed that Apple devices load remote images in emails by default. This can cause privacy issues and it is not a recommended practice. A malicious user can send you an email with an embedded 1×1 pixel image with the background colour of your email client, so it is not visible. The email client will load this image from a remote server and by doing so, it discloses your IP address and email client banner, and possible your identity. In some situations, such behaviour can have catastrophic consequences.”
The attack works by inserting several DNS change commands with default router usernames and passwords inside the e-mail. These are executed silently when the e-mail is read. If the included username and password matches your router, it could change your DNS settings.
These settings tell your computer where to go to find correct internet addresses for website names. If these settings were set to a malicious server, the hacker could send you to a bogus page that looks like a real one, but could harvest your credentials or account information.
The author recommends changing the “download remote image” Mail settings on Apple products to off or changing your router password to something complex. Using a long complex router password is always good advice.
Sometimes it is the oddest, harmless looking things that could cause problems. I can’t think of anything more innocuous looking than the following Linux shell command:
But DO NOT run this on a Linux system, or chances are that you will perform a Denial of Service attack on your own machine! You may have to hard reset your system to get it back and you COULD LOSE DATA!
This is not new, I have seen this floating around, and it looked interesting. It was referenced in a 2007 post that said it didn’t work anymore because most modern OS’s are configured to protect against it. So of course I just HAD to try it.
I booted up my Ubuntu 12.04 system, opened a command shell, entered the command and…
It locked dead!
Okay just what is this command???
FORK BOMB PROCESS ATTACK
Meet the “Fork Bomb”. Basically all it does is instruct Linux to open processes – over and over again for an almost infinite number of times. Your RAM and CPU usage rises until the system no longer responds to input.
Let’s see what it does to an Ubuntu 12.04 system.
Here is an Ubuntu 12.04 System Monitor screenshot of a system before I ran the Fork Bomb:
The CPU and Memory usage are steady.
Now once the Fork Bomb is started:
Notice the significant increase in CPU and RAM usage. It even doubled the CPU usage on the virtual host, taking it from 8% to 17% while the attack was running.
I lost all control of the Ubuntu system. Even the keyboard lights were unresponsive. Supposedly some operating systems will recover if left alone long enough. But I waited a while and I never got control back.
(Okay, for all those out there claiming that it was just a Virtual Machine, I tried it on a stand alone Ubuntu 12.04 system with the same results. Okay, there was a quarter second pause before I lost control of the machine!)
DEFENDING AGAINST THE ATTACK
This is very easy to defend against. All you need to do is set limits to the number of processes that a user can open. These can be set per user, per group or globally. And you can set this one of two ways.
You can use the ulimit command for instant change that only lasts until the user logs off, or make the change permanent by editing the /etc/security/limits.conf file.
To use the ulimit command simply type “ulimit -u” with the number of processes that you want users to be allowed to run. So to set the limit to 512 just type:
sudo ulimit -u 512
Does this work? Absolutely – after running ulimit, the fork bomb is effectively throttled:
As you can see from the screenshot above, there is very little increase in RAM usage and the CPU usage is much more tolerable. And more importantly, I had full control of the system.
You can also change the /etc/security/limits.conf file to make the change permanent. Full instructions can be found on AskUbuntu.com, but basically just add the following line to the config file:
* hard nproc 512
The “*” means apply the change to everyone, “Hard” means it is a hard limit, and “nproc 512” locks the number of processes to 512.
You need to adjust the number of processes to a number that would be the best setting for your system. 512 seemed to work great on mine. Don’t set the number to low, or you may have other “denial of service” type issues, lol.
Oh, and for all the Mac Fanboys out there, this command didn’t seem to have any effect when run on a newer Mac. Okay, my friend ran it and it ate up 24 Gb of RAM, but seeming he had 64Gb of RAM on the system, it just laughed the attack off.
Even running it on a Mac with 24Gb of RAM had no discernible effect, other than getting a screen full of “Bash Fork: Resource Temporarily Unavailable” error messages like above. Looks like Mac’s have process limits enabled by default. (Thanks Command_Prompt and Bill!)
This should be obvious, but for the record, you should never run this command on systems that you do not own… Or put it in someone’s startup script.
But knowing how to limit a user’s ability to run processes is very important and throttling them on Linux systems where it is not done by default could curtail some problems before they surface.