Insecure commercial and internal mobile app coding practices leave the door wide open to cyber attackers, a security researcher has discovered.
A lot emphasis is placed on the millions of mobile malware samples being detected, but insecure apps could represent an even greater threat, according to an analysis of the top 1,000 apps.
“A scan of just over 600 of the top apps so far shows a very obvious and alarming trend,” said James Lyne, global head of security research at Sophos.
“Programming practices are pretty bad despite there being ready-made security functionality available to consumers, but this is just not being used,” he told Computer Weekly.
Although the study includes relatively few in-house mobile apps, Lyne said that so far, most are lining up with the worst of the commercial applications.
The study compares the maturity of app development in the mobile and traditional desktop worlds, focusing on the use of encryption, data transmission, authentication and data storage.
“It is really no surprise that these two worlds are not in alignment, but it is quite shocking how many applications, including large brands, are failing to make use of the security features available on mobile devices,” said Lyne.
Despite the existence of easy-to- use application program interfaces (APIs) that will perform proper validation of the transport [layer], most app developers continue to use older, less secure methods of exchanging data.
The study shows that an alarming majority of apps are failing to do things such as certificate pinning or public key pinning to prevent man-in-the-middle attacks.
“Many developers seem to be using recycled code for making connections that they have simply copied from somewhere that will accept any certificate, enabling attackers to steal data easily on open Wi-Fi connections unless a VPN [virtual private network] connection is being used, but relatively few people do,” said Lyne.
Local storage of data
Another area of common failings is local storage of data. Although most of the latest iOS and Android devices will do volume-based encryption by default and provide very good functionality to store “secrets” that have extra encryption applied and are unlocked only if the app is authenticated, Lyne said this functionality is used very poorly and inconsistently by most mobile apps.
“Only around 3% of apps stick to an astonishing amount of best practice, like the Twitter app which has two-factor authentication, but then there is this cliff where all of the best standards and practices are not applied and all the data is put into the same unimportant bucket to be stored on the device,” he said.
The result is a very weak app ecosystem, where app A can see data from app B and there is a “flat” data model on the device, similar to that which was on PCs up until a few years ago.
The study also focuses on the use of credentials and authentication, and has found this to be another area of poor practice in about 90% of the apps analysed.
Credentials are often sent “over the wire” using just hashing, often with outdated mechanisms such as MD5 and SHA-1, without salting instead of using standards such as OAuth and SAML.
“The majority of the authentication we have seen uses models that are abysmally poor,” said Lyne. “Loads of MD5 passwords unhashed are being sent, which requires the user to have an incredibly strong password to avoid it being cracked.
Authentication poorly deployed
“Authentication, which should be a very solved problem in 2016 with all the wonderful program libraries available and all the functionality built into mobiles, is very poorly deployed,” he added.
In many cases, simply adding a single argument to the code would turn on the built-in functionality that would fix the problem, said Lyne.
In some of the latest Android releases, he said, Google has done some “amazing work” to implement security features in the operating system.
“We are seeing some really good generic exploit prevention in Android, but on top of that you have this layer of apps that are failing to do the security basics and check for basic flaws,” he added.
Lyne blames the huge focus on rapid app development over “quality solution engineering” and “almost no investment” in checking mobile apps for poor programming practices.
“Any rudimentary penetration testing or quality assurance processes as part of a software development lifecycle would catch stuff like this,” said Lyne.
The risk to the enterprise is that this failure to do rudimentary security controls can be picked up by attackers using any source code scanner, he said.
“At the same time, businesses are putting pretty much the same sensitive company data on mobiles as they have put on PCs in the past, and tend to trust mobiles more than PCs,” he said. “But this study shows that the mobile industry does not have the same checks and balances or the same maturity.”
This means the fear that mobiles will become an easy route for attackers into the enterprise is likely to be realised as the lines between PCs and mobiles continue to blur.
“The lack of security basics in mobile apps and processes for checking flaws is a really bad combination now, but in one or two years’ time, when there is even more data on mobiles and they have an even greater position of trust, we are likely to end up with a really nasty mess,” said Lyne.
Attackers are aware of this situation and could already be exploiting the fact that most mobile apps are “leaving the door wide open”, but it is hard to quantify that, he said.
And even if it is not being exploited yet, Lyne said: “We are building an ecosystem with massive trust on one side and a provable lack of integrity on the other, which is a terrible combination that could really burn us.”
We are building an ecosystem with massive trust on one side and a provable lack of integrity on the other, which is a terrible combination that could really burn us James Lyne, Sophos
He believes there is an urgent need for fundamental change, but says regulation is unlikely to deliver the necessary results.
“It is very difficult to create a regulatory framework that has sufficient specificity to drive the desired technical behaviours,” said Lyne.
However, he said some legal action could be taken in light of the fact that some failures are so great and tantamount to releasing a car to market without testing the brakes once, that they could be classified as “negligence” and challenged legally.
But even if regulators or others challenge the status quo on grounds of negligence, Lyne said it is unlikely to drive any significant change.
“What is really required would be a change in consumer or end-user values to believe that mobile application security is important, but that is unlikely given the trust people have in mobiles and the fact that most are completely unaware of the flaws,” he said.
“The only thing likely to break the back of it is a really, really bad or nasty series of incidents that force companies to make changes due to bad press and consumers becoming more wary and demanding in terms of security. But in the meantime, who knows how much data siphoning is occurring.”