The huge theft of data from the controversial — and now almost homeless — social media app Parler was accomplished in part through a common web development mistake, according to one expert.
“Essentially the Parler [software] engineers made a mistake in that they allowed an endpoint [a web address] to exist that people could sequentially query,” says Matt Warner, CTO and co-founder of Blumira, an Ann Arbor, Mich.-based a cloud-based threat detection provider. “And if you can stand up enough people looking at different blocks of numbers you can essentially scrape nearly unlimited amounts of data through that endpoint.”
In short, the URLs Parler developers created included sequential numbers, like “ID=12345.” Knowledgeable people could guess the next numbered page was 12346 and would get a hit if access wasn’t protected.
That’s all right if the page is public. If it’s not — for example, it’s a page only logged in bank customer “Jane” is only allowed to access — then once anyone is logged in they can see other pages/accounts just by changing the page number.
Software developers call this an insecure indirect object reference (IDOR), and for years it was one of the Open Web Application Security Project’s (OWASP) Top 10 vulnerabilities. To be exploited, OWASP says, an IDOR issue must be combined with an access control problem, which gives an attacker access to a web page. Warner suggested the researchers or activists might have gained that access after several providers like Twilio dropped Parler after last week’s mob attack on the U.S. Congress. That may have made it impacted email verification, making it easier for new users to subscribe, opening the door to the IDOR expoit.
The data scraping happened shortly after it was revealed that Parler would be de-listed by providers because people involved in last week’s mob attack on the U.S. Congress used it to communicate. Apple and Google dropped Parler from their app stores, and Amazon stopped allowing Parler to use its hosting facilities. Parler is now suing Amazon.
In what Warner calls “probably the most co-ordinated hactivism we’ve seen in a while,” some 15 people who were told of Parler’s vulnerabilities quickly copied apparently almost every users’ post and attachment. According to the news site Gizmodo, 56 terabytes of data has been captured.
A question of timing
One interesting question is whether the IDOR vulnerability was discovered after the incident in Washington, or if it’s been known for some time, according to Warner.
IDOR is “a really common risk” among developers who build their own websites and application programming interfaces (APIs), Warner said. “It used to be a lot more common five or 10 years ago when people were standing up early database-driven web sites. It’s not that common these days with the prevalence of UUIDs (universally unique identifier, sometimes called a globally unique identifier), which are long and complex [URL] IDs, but for whatever reason on this specific endpoint, which was associated with their mobile app, they weren’t doing that. And because of that it essentially exposed all of Parler’s attachments and metadata.”
It’s one of the reasons why application security and testing is essential, Warner said. Parler more than likely didn’t have their application tested from a web application point of view. And it’s one of those things that can cascade very quickly just because it indicates other areas of risk within the environment — if you’re missing checks in this area you’re probably missing other areas in the application.”
IDOR vulnerabilities can be avoided if website designers make sure authentication and authorization of URLs are included early in development, says Warner. Otherwise, “if you have a lot of complex code you have to figure out where to jam that authentication check.”
Another way is to make sure sequential IDs are not part of page numbering so people can’t guess brute force access to pages.