Last updated at Thu, 29 Aug 2024 20:47:23 GMT
Mobile application security
A few years ago, Sean Gallagher wrote this article that we believe outlines one of the most important areas of application security risk today, mobile application security. In his article for Ars Technica, “Mobile Application Security: Always Keep the Back Door Locked,” Gallagher outlines that its important to address mobile application security because many of the mobile applications we use today access backend middleware and corporate data sources. We have email applications, Twitter front end applications, even payment and banking applications.These mobile applications carry the same risks we have been fighting with web applications –they enable traffic to pass through normal corporate defenses like network firewalls.
Why mobile applications are vulnerable
There has been so much talk about device security, but most mobile applications make server side calls which is really the part that needs securing because server side compromise will impact more users and can expose sensitive and costly information. And since mobile applications are new and businesses are rushing to get them out the door, all too often they are aren't architected and configured with proper security and access controls leaving them vulnerable to attackers. As Gallagher put it, “Speed (to market) Kills.”
Are mobile application vulnerabilities new?
The reality is that the vulnerabilities that are showing up in mobile applications aren't new at all.There are the same old vulnerabilities that we have been hunting for over 13 years now, SQLInjection, XSS and the like. In my recent post, I call it mobile application security Where's Waldo. Read that post for more info on why the vulnerabilities are as Gallagher puts it, Deja Vu.
How easy it is to attack mobile applications
Man in the middle attacks
It's surprisingly easy to attack mobile applications. You can just park myself in the mall with a laptop and a Wi-Fi Pineapple. The Wifi Pineapple enables you to deliver real Internet access as a ‘man in middle.' As people join your Wifi, you simply watch the traffic coming from their smartphones without them knowing that their smartphone is connected to you. And when their applications get updates from a server, you see those updates. You can - but you won't, right? - pull data from the sniffed traffic to do a man-in-the-middle attack if the application doesn't have additional sorts of controls and protection, it could then be used to attack and access data in the backend systems.
Finding incomplete NONCE usage
Another technique you can use, is looking for lack of, or ineffective use of a NONCE, a number used once. When building mobile apps, developers must use one time tokens. The client must have a special session token that is only used to create the NONCE. It looks at what its going to send in a string and calculates a special value that will only be valid for that request because it will be very difficult to re-create that key for another request. So, it is very hard to hack those kinds of apps. For people building mobile applications, the NONCE technique is fairly well-known. Its a part of OAUTH which is becoming standard. It has become a part of identify management, but unfortunately not everyone is using it. In normal web use it wasn't as critical because you have slightly more trust in the communication layer, but with mobile, you can't trust it at all and use of the NONCE is critical.
We're seeing many mobile applications that use a NONCE for one kind of request, but not for another. For example in the case of an application that might front-end Twitter, the developers might use a NONCE for sending Tweets, but they might not use a NONCE for reading messages. Since there isn't a NONCE used for reading messages, we can leverage the man in the middle attack described above to sniff credentials for a user and then read private messages as that user.In a way, its similar to CSRF. It's like the mobile equivalent to anti-CSRF support. It basically prevent replay attacks for mobile backend.