Mar 26, 2014 // Andrew Stroup
Followed by the well-noted Starbucks mobile app security SNAFU (and Delta, Facebook, Match.com, and eHarmony), Walmart has followed suit with their iOS mobile app that exposes users’ passwords, account names and email addresses, as well as many geolocation details and list of recently viewed/scanned products. Walmart is the largest company in the US by revenue and has a very large and experienced IT staff, so what went wrong?
Since the initial report by Daniel Wood (CISSP, GPEN), an independent penetration tester, Walmart has already resolved many of the security issues and is still fixing the geolocation problem. Wood was commissioned by Computerworld to conduct the vulnerability and penetration testing. During his work, he also found security vulnerabilities in Walgreens‘ iOS mobile app.
The unencrypted information stored within the Walmart app is readily available on any mobile device it’s installed on and we’ve learned through efforts like Fireeye and Cellebrite that even phone PIN protection can be subverted through brute force attacks. Additionally, password information was also vulnerable within the iTunes backup (fixed in a recent update) and through public Wi-Fi due to heavy reliance on HTTPS for sole protection, leaving it vulnerable to wireless sniffing attacks.
So what’s the cause of all these security vulnerabilities that span multiple major US companies? It seems that the majority of the “testing” is centered around functional testing to ensure the application does not have any critical bugs, BUT the detail of the security vulnerability and penetration testing rarely expands beyond the traditional scripted tests that very seldom can go above and beyond to hone in on potential vulnerabilities for the specific application.
Walmart claims to have used services like Veracode and White Hat Security, but if they were only using the generic scripts for testing, this often leads to a false sense of security (pun intended) as additional detailed testing is required to identify unique mobile application vulnerabilities.
If exposing customer sensitive data wasn’t bad enough, credentials for the internal development server at Walmart were available within the app. To make matters even worse, the username was “Mobile” and the password was “1111” (the account has been recently been disabled). Wood also found the cleverly named “DeveloperCredentials.plist” file where the username was “developer@walmartlabs.com” and password was “password” (also disabled). This means that the development team didn’t clean up the app and removed development-specific items, leading to major security vulnerabilities to Walmart’s servers. A hacker’s literal goldmine, this type of poor security practice and processes could have led to huge implications for Walmart that could have ended very poorly in servers going down, hacked customer credit card information, and company wide rolling social engineered attacks.
The resolution? Wood notes the “need to utilize certificate pinning. As a developer, you can either pin the Web service’s certificate within the app itself, which takes the Certificate Authority out of the picture, or ‘pin’ the CA’s certificate that was used to sign the sever’s certificate on the back end, limiting trust to only certificates signed by the CA. This is important because it reduces the threat against a malicious user being able to introduce their rogue certificate into the mix and prevent an attacker from utilizing a proxy server to masquerade as the server. While not an end-all, it helps defend against intercepting on the server side.”
Bottom line, there’s still a lot of progress to be done when it comes to mobile security practice and testing. If giant companies like Walmart and Walgreens still have difficulty delivering applications that protect user data, the mobile industry has a long road ahead of it before a ubiquitous adoption of security best practices.
