Share

Related Links

  • Pure Hacking
  • Reed Exhibitions Ltd is not responsible for the content of external websites.

Top 5 Stories

News

Researcher defeats two-factor iPhone authentication

12 April 2011

An Australian IT security researcher has staged a demonstration of how to compromise the security of an Apple iPhone when using the smartphone as a two-factor authentication (2FA) device.

Many banks, notably in Australia and the US, have been using text message authentication as a means of adding 2FA security to online banking services.

According to Tyrone Miller, a director with Sydney-based Pure Hacking, by remotely compromising an iPhone with malware, it is now possible to remotely monitor the smartphone and route the users' credential keystrokes – which would not normally appear on the phone's screen, Infosecurity notes – to an on-handset SQLlite database.

By using a simple remote telnet application, in this case Putty, Miller claims that the 2FA credentials can be accessed by cybercriminals.

Miller says that he has staged a demonstration of a 2FA iPhone hack and posted a video of the session to YouTube.

As he reports in his latest security blog: "SMS 2-factor authentication has had a major impact in reducing online fraud."

"This is because an attacker must not only capture the victim's username and password to login to their bank account, but they must now also have the victim's phone to receive the SMS 2-factor authentication token", he says.

"This restricts the number of possible attacks dramatically", he adds.

However, he goes on to say, where previously a user would login to their internet banking on their laptop, and then receive the SMS token on their mobile, the attacker may be able to capture the username and password of the victim, but they are unable to capture the SMS token.

"Now we find that users are logging into their internet banking on their smartphone, and then receiving the SMS token on the same device. This means that an attacker who has hacked the victim's smartphone, most likely via a malicious website, is now able to capture the username, password, and SMS token all on the one device", he says.

Detailed examination of Miller's video suggests that his remote telnet session is attaching to the root directory of iOS - using the well-known root/alpine ID/password combination - tapping a methodology similar to the iKeyGuard keylogging app we reported on yesterday, Infosecurity notes.

This hack would require physical access to a users' iPhone for a period of time, to install the malware, but once installed, a remote telnet session would be easy to access using 2G, 3G or WiFi connections.

This article is featured in:
Application Security  •  Data Loss  •  Identity and Access Management  •  Wireless and Mobile Security

 

Comments

VirtualS says:

15 June 2011
So I need Two Factor and based upon this article I have to consider the possibility of how simple my Two Factor device (or solution) is to hack! So if I look at the market and all the noise around Two Factor hacking...

1 - I attempt to hack 5 Billion Phones (some Apple, some Blackberry, some Android and the majority not even smart phones) - should take me several tens of thousands of man days (at 20 minutes a phone) even if they were all Apple and the user will never notice I've stolen his new shiny iPhone!

2 - I hack the manufactures database who supplies the tokens (oops think this one has happened already to RSA). This gives me hundreds of thousands (if not millions) of user secure log in details and takes minutes (once the planning is done) to achieve.

Two Factor provides "stronger" authentication a bit like "stainless" cutlery ... it stains less! If someone wants to hack you they will. Security is based upon layers and Strong Authentication is just one layer and you need to weigh up the options. I would always recommend any company implements Two Factor, but don't be fooled by some of the "what if" FUD (Fear Uncertainty and Doubt) out there.

You have to consider three simple areas when considering Two Factor (and I rate these in order of selection (not importance - as this is what every customer will look at first):-

- Cost - have we got budget and what is the ROI. Where the ROI us usually the "what if" factor.
- Usability - will my users be able to work this and if so how easy is it for them to use
- Versatility - all users are not the same, all geographies are not the same - so can the solution lend itself to a lot of variables where the market (be it legal, technical etc.) demands.
- Simplicity - most Two Factor solutions are a nightmare to look after and administer. The hidden costs of deployment, management are never really thought about.So what impact will it have on my business.

It is funny that the latter one is usually the highest cost to any business, with the usability being the reason most people don't even bother!

So does Cloud provide the answer, if I off load all this admin stuff to someone else?

Well if you're not worried where your details are held and trust someone who can never be hacked (oops again - think this has happened a lot lately, to a lot of very high profile customers!)

As the saying goes "horses for courses"

VictorV says:

15 June 2011
"This hack would require physical access to a users' iPhone for a period of time, to install the malware"

Basically means the hack involves a full jailbreak of the phone. A user will soon notice as there will suddenly be Cydia installed. And also if someone has access to your phone for the 20 minutes to do a jailbreak, they could just read the SMS. If you have a token, (hard or soft) you need to make sure that users take care of it. Personally I think if it's on a phone, then that's something a user'll more likely take care of.

Note: The majority of comments posted are created by members of the public. The views expressed are theirs and unless specifically stated are not those Elsevier Ltd. We are not responsible for any content posted by members of the public or content of any third party sites that are accessible through this site. Any links to third party websites from this website do not amount to any endorsement of that site by the Elsevier Ltd and any use of that site by you is at your own risk. For further information, please refer to our Terms & Conditions.

Comment on this article

You must be registered and logged in to leave a comment about this article.

We use cookies to operate this website and to improve its usability. Full details of what cookies are, why we use them and how you can manage them can be found by reading our Privacy & Cookies page. Please note that by using this site you are consenting to the use of cookies. ×