Threat actors can take over victims' cloud accounts to steal data, or use them for command-and-control for phishing attacks, denial of service, or other cyberattacks.

Attackers can compromise a new feature in Amazon Web Services (AWS) to hijack cloud accounts' static public IP addresses and abuse them for various malicious purposes, researchers have found.

Threat actors can use the Amazon Virtual Private Cloud (VPC) Elastic IP (EIP) transfer feature to steal someone else's EIP and use it as their own command-and-control (C2), or to launch phishing campaigns that impersonate the victim, researchers from cloud incident response firm Mitiga revealed in a blog post on Dec. 20.

Attackers also can use the stolen EIP to attack a victim's own firewall-protected endpoints, or to serve as the original victim’s network endpoint to extend opportunities for data theft, the researchers said.

"The potential damage to the victim by hijacking an EIP and using it for malicious purposes can mean using the victim’s name, jeopardizing the victim’s other resources in other cloud providers/on-premises, and \[stealing the\] victim’s customers' information," Or Aspir, software engineer at Mitiga, wrote in the post.

Threat actors must already have permissions on an organization's AWS account to leverage the new attack vector, which the researchers call "a post-initial-compromise attack."

However, because the attack was not possible before the feature was added and is not yet listed in the MITRE ATT&CK Framework, organizations may be unaware that they are vulnerable to it, as it's not likely to be picked up by existing security protections, the researchers said.

"With the right permissions on the victim’s AWS account, a malicious actor using a single API call can transfer the victim’s used EIP to their own AWS account, thus practically gaining control over it," Aspir wrote. "In many cases it allows greatly increasing the impact of the attack and gaining access to even more assets."

**How Elastic IP Transfer Works**

AWS introduced EIP in October as a legitimate feature to allow transfer of Elastic IP addresses from one AWS account to another. An Elastic IP (EIP) address is a public and static IPv4 address that can be reached from the Internet and can be allocated to an Elastic Compute Cloud (EC2) instance for Web-facing activities, such as website hosting or communicating with network endpoints under a firewall.

AWS introduced the feature to make it easier to move Elastic IP addresses during AWS account restructuring by transferring the EIP to any AWS account — even AWS accounts that are not owned by someone or his or her organization, the researchers said.

With the feature, the transfer is a mere "two-step handshake between AWS accounts — the source account (either a standard AWS account or an AWS Organizations account) and the transfer account," Aspir explained.

**Abuse of Elastic IP Transfer**

The ease with which EIPs can now be transferred creates an unintentional issue, however — while it certainly facilitates the process of transferring IP for legitimate account owners, it also makes it easier for malicious actors as well, the researchers said.

Researchers described a basic scenario to illustrate how attackers can take advantage of EIP transfer, assuming that attackers already have permissions that allow them to "see" existing EIPs and their status, or whether or not they are associated with other computer resources.

Typically, EIPs are associated, but sometimes an organization keeps dissociated EIP for later use, or as a result of an unmanaged environment that keeps unused resources, the researchers said. "Either way, the attacker only needs to enable the EIP transfer, and the IP address is theirs," Aspir wrote.

Attackers can do this in two ways with the correct permissions: either transfer a dissociated EIP or remove the association of an associated EIP and then transfer it, the researchers said.

For the former, an adversary must have the following action in its attached Identity and Access Management (IAM) policy on AWS: "ec2:DisassociateAddress" action on the elastic IP addresses and the network interfaces that the IP addresses are attached to.

To transfer an EIP, a threat actor must have the following actions in its attached IAM policy: "ec2:DescribeAddresses" on all the IP addresses and "ec2:EnableAddressTransfer" on the EIP address that the attacker wants to transfer, the researchers said.

**Leveraging a Stolen EIP**

There are a wide range of attack scenarios that a threat actor can engage in after successfully transferring someone else's EIP to their own control.

In external firewalls used by the victim, for example, an attacker can communicate with the network endpoints behind the firewalls if there is an allow rule on the specific IP address, the researchers said.

Moreover, in cases in which a victim uses DNS providers such as a Route53 service, there could be DNS records of an "A" type in which the target is the transferred IP address. In this case, an attacker can abuse the address for hosting a malicious Web server under a legitimate victim’s domain, then launch other malicious actions, such as phishing attacks, the researchers said.

Attackers also can use the stolen IP address as C2, using it for malware campaigns that appear legitimate and thus fly under the radar of security defensives. A threat actor can even cause denial of service (DoS) to a victim's public services if they dissociate an EIP from a running endpoint and transfer it, the researchers said.

**Who's at Risk and How to Mitigate It**

Anyone using EIP resources in an AWS account is at risk, and thus must treat the EIP resources like other resources in AWS that are in danger of exfiltration, the researchers advised.

To protect themselves from an EIP transfer attack, Mitiga recommends that enterprises use the principle of least privilege on AWS accounts and even disable the ability to transfer EIP entirely if it's not a necessary feature on their environment.

To do this, an organization can use native AWS IAM features such as service control policies (SCPs), which offer central control over the maximum available permissions for all accounts in an organization, the researchers said, providing an example in their post of how this works.

AWS Elastic IP Transfer Feature Gives Cyberattackers Free Range

Elon Musk claims plane-tracking data is a risky privacy violation. But the world loses a lot if this information disappears—and that's already happening.

I woke up Friday morning to the message I’d been expecting: “Your account, @Justin\_Ling has been locked for violating the Twitter Rules.”

Below was the offending tweet: a link to one of the few websites that provide real-time private jet flight data that “chief twit” Elon Musk, I wrote, “hasn't bullied into suppressing his flight data.”

Musk has accused these flight trackers of providing “basically assassination coordinates.” He has launched a crusade against these apps and anyone who shares them on his recently acquired social media platform. Accounts like mine were locked, while others were banned entirely—from the @ElonJet bot, which shared the location of Musk’s private plane, to reporters who picked up on his campaign. Twitter rules were rewritten on the fly to forbid publishing anyone’s “physical location.”

The chaotic few days prompted the European Union to warn Musk that silencing journalists would likely result in sanctions from EU regulators. US Representative Adam Schiff demanded that Musk reinstate the suspended accounts and explain to Congress why he decided to retaliate against the press in the first place.

As of Monday, following a poll asking users when he should lift the account suspensions, Musk reinstated some—but not all—of those accounts. 

Lost in the chaos is just how successful Musk has been at suppressing that real-time flight data on the internet. In so doing, he’s taking aim at an incredibly valuable source of information—which has helped researchers, journalists, and experts with everything from tracking Russian oligarchs to investigating the fate of missing aircraft to tracking down international hitmen. Musk isn’t the only one trying to keep this type of information out of the public’s hands. 

Both real-time and historical information on Musk’s main private jet—a 2015 Gulfstream G650ER, tail number N628TS—is conspicuously missing from the two main flight-tracking platforms: FlightAware and FlightRadar24.

FlightAware reports that its real-time data on Musk’s jet is unavailable “due to European government data rules,” while its historical data about the plane’s comings and goings was removed “per request from the owner/operator.” Looking up Musk’s jet on FlightRadar24 returns the message: “we could not find data.”

Even smaller tracking platforms, like AirportInfo—the account that led to my Twitter being locked—have taken Musk’s flight information offline.

“The ongoing hullabaloo about the location of Elon Musk’s airplane has caused us to stop displaying his plane at the moment,” says Christian Rommes, an AirportInfo administrator. “Because Musk is threatening legal action, we don’t want to take any risks.”

While Rommes says his office hasn’t heard from Musk’s legal team, they took the step as a precaution. “Don’t mess with the (former) richest man of the world,” he says.

Aircraft operators are required to report detailed information on their flight path to various national regulators, including the Federal Aviation Administration. That data is generally a matter of public record and is published to various websites popular amongst airline enthusiasts. 

Some companies, like FlightAware, augment government data with their own sources of real-time flight information. Other websites, like planespotters.net and airliners.net, allow users to submit photos taken of aircraft as they come and go around the world.

These services have proved incredibly useful for journalists and independent researchers in recent years.

When Malaysian Airlines flight 370 disappeared in 2014, these trackers provided the public with the same data investigators were puzzling over—a flight path that cut straight across Malaysia before stopping abruptly over the South China Sea. Those websites would become critical tools for independent researchers in the years that followed.

Journalists and the general public again turned to these services after Malaysia Airlines flight 17 and Ukrainian International Airlines flight 752 were shot down in 2014 and 2020, respectively. As early reports suggested disaster had struck, these websites showed clearly that the flights were interrupted in mid-air.

But the utility of real-time flight tracking goes far beyond disasters.

In more lighthearted examples, diehard soccer fans have used FlightRadar24 to figure out where prospective trades are heading ahead of a possible signing. In 2015, tens of thousands of football fanatics correctly identified star manager Jurgen Klopp’s private jet as it made its way to Liverpool, preempting the team’s announcement.

The availability of this data has made it possible to track everything from a shipment of US weapons to Ukraine to Nancy Pelosi’s tense visit to Taiwan, in defiance of Chinese warnings.

Some pilots have leaned into this new visibility. One made headlines after drawing a penis in the sky over Florida.

The websites have also contributed to embarrassment for some private jet owners. Thanks to @CelebJets, a bot account set up by 20-year-old programmer Jack Sweeney, who also created @ElonJet, scrutiny over the pace at which the rich and famous galavant around in their CO2\-intensive private planes reached a fever pitch in 2022. Marketing agency Yard calculated just how much environmental damage was caused by these private jet trips—particularly short-haul flights, where driving or taking public transit would take only marginally longer. That report led to a massive public shaming of celebrities like Taylor Swift, whose private jet addiction put 1,184 times more CO2 into the atmosphere than the average person produces in a whole year. 

A single Elon Musk flight from February burned nearly 4.5 tonnes of CO2.

Sweeney’s jet-tracking bots, which scraped that public flight data and sent it directly to Twitter, also published real-time information on Russian oligarchs. That bot helped open source investigators keep tabs on a cohort of the ultra-rich Russians mainly responsible for keeping Vladimir Putin’s regime running amid a costly war against Ukraine.

Investigative outlet Bellingcat recommends FlightRadar24 for open source investigators, and its researchers have relied on the tool to track likely Russian intelligence operatives, understand political tumult in Kazakhstan, follow the Venezuelan government’s semi-secret private jet, and keep tabs on NATO planes as they conduct operations. Other investigative outlets, like the Organized Crime and Corrupting Reporting Project, have similarly leveraged the data to hunt down shady dealings the world over.

But as Musk’s effort to suppress the information has shown, not everyone wants this data to remain public.

For starters, some planes can turn off their transponders, which relay their coordinates to flight regulators. That option is generally not available for private civilian aircraft.

More useful to someone like Musk is the FAA’s Limiting Aircraft Data Displayed list. Introduced by a 2018 act of Congress, it allows private jet owners to block their data from being disseminated by the FAA. A spokesperson for FlightRadar24 confirmed to WIRED that, as they rely primarily on the FAA’s data, they respect the block list.

Not everyone relies on the FAA, however. Planes regularly transmit basic information mid-flight, through Automatic Dependent Surveillance-Broadcast technology (ADS-B). 

ADS-Bexchange, which describes itself as the “world’s largest source of unfiltered flight data,” has continued reporting real-time information on Musk’s Gulfstream using that technology. Sweeney relies on that website for his bots—which have since moved over to Instagram and Mastodon.

“The position data shown by ADSBexchange is available to anyone who can spend $50 on Amazon and put the parts together,” reads a Q&A on its website. “It’s not secret.”

Users on the site’s Discord channel have spent recent days mocking Musk’s attempt to go after this information and have been clear that they do not intend to remove his jet from the platform. “ADSBx does no blocking or hiding for any reason,” one moderator wrote.

Anyone keeping tabs on Musk’s jet would have known that the Twitter CEO was heading to Qatar for the World Cup finale on Sunday. Doha was a key player in Musk’s Twitter takeover. While there, Musk snapped a selfie with a Russian state broadcaster. (Musk has also relied on a Dubai-based financier with ties to Russian oligarchs to finance his $44 billion purchase of the social network.)

Given how much scrutiny this type of flight data has brought on him and his business dealings, perhaps it’s no surprise that Musk has taken some desperate measures to hide this information. He reportedly offered Sweeney $5,000 to take the @ElonJet bot down. Sweeney countered, asking for $50,000—but the pair do not appear to have ever made a deal. Despite vowing to respect Sweeney’s right to publish the information, Musk banned all of his bots and his personal Twitter account earlier this month, while ADS-B’s Twitter account was similarly removed.

Steffan Watkins is a Canadian Osint researcher who has spent years tracking planes and ships using this kind of publicly available data. Last year, he worked with a United Nations panel of experts to identify planes smuggling weapons into Libya.

“Simply put, because flight data is publicly available through many different flight trackers, the public is empowered to fact-check any statement from any source, government or private,” he says. “Unsurprisingly, there are powerful people who don’t want the transparency that provides.”

Knowing more about where government planes and private jets are going to and coming from can yield surprising results. Watkins points out that the CIA’s extraordinary rendition program, which enabled the arbitrary detention and torture of suspected terrorists—many of whom were innocent—was exposed with the help of open source flight data.

“As the CIA kidnapped and flew citizens of other countries to black sites around the world for integration and torture on government-chartered bizjets, they left a trail of data in their wake that was used to unravel the routes used to ship their abductees,” Watkins told WIRED.

More recently, in 2018 researchers used ADS-B data to trace the route that a Saudi kill squad took on its way to murder _Washington Post_ journalist Jamal Khashoggi.

Earlier this year, the Saudi government submitted a proposal to the International Civil Aviation Organization to encrypt and restrict access to this data. “The uncontrolled access to detailed/accurate ADS-B data on the internet raised concerns by aircraft operators and owners on safety, security, and privacy of flights,” the Saudis wrote to the Montreal-headquartered UN body.

“Oh, the country that flies assassins around the world wants to hide aviation info from the public because of ‘security’?” Watkins says. “How quaint.”

A Saudi prince, Alwaleed bin Talal bin Abdulaziz, is the second-largest shareholder in Twitter. The site’s largest owner, Musk, is similarly relying on security concerns as he moves to ban this flight data from his platform.

In announcing the ban on real-time flight data last week, he alleged that a “crazy stalker” followed a car carrying one of his children. “Legal action is being taken against Sweeney & organizations who supported harm to my family,” he tweeted.

The Los Angeles Police Department sees no link between his private jet’s coordinates and the alleged stalking, according to _Washington Post_ reporters Drew Harwell and Taylor Lorenz—two journalists Musk banned on Twitter. A Bellingcat contributor geolocated the incident, which Musk recorded and published to Twitter (possibly in violation of his own rules), to a gas station miles away from the airport and nearly a full day after Musk’s jet had last been in the air.

Seeing how few—if any—of Musk’s critics and online tormentors have air-to-air intercept capabilities, and given that airports continue to be some of the most secure places in modern society, the Tesla owner’s security concerns appear overblown.

“Safety, security, and privacy sound like noble goals, but there isn’t a rash of violent attacks on private planes—or any planes—and no indication there will be,” Watkins says. “Musk’s gripes are almost Musk-specific; few people have a jet they themselves can call on and fly anywhere with on a whim.”

Elon Musk and the Dangers of Censoring Real-Time Flight Trackers

Definitive solution is ‘non-trivial’ since behavior arises from customers processing non-RFC compliant requests

Definitive solution is ‘non-trivial’ since behavior arises from customers processing non-RFC compliant requests

A vulnerability in how Akamai retrieves Amazon Web Services (AWS) S3 resources could allow attackers to stage web cache poisoning attacks against websites.

Web cache poisoning involves malicious clients forcing content delivery networks (CDN) or web servers to cache malicious content and later serve it to other clients requesting the same resource.

**Double misconfiguration**

Akamai can map various HTTP requests to their corresponding S3 bucket and cache them for later retrieval. Security researcher Tarunkant Gupta discovered that he could trick the Akamai server into caching files from malicious buckets.

“A few months back I encountered a non-exploitable AWS S3 misconfiguration and I was just revisiting it to check if that still exists or not, but this time I wanted to explore all attack possibilities,” he told The Daily Swig. After trying different attack vectors, Gupta ran into a misconfiguration in Akamai’s cache servers that could be leveraged to exploit the S3 bug.

RELATED Akamai WAF bypassed via Spring Boot to trigger RCE

Akamai said creating “a blanket ‘patch’” was “not trivial, as that may have a big negative impact on legitimate internet traffic”, according to a technical writeup from Gupta. In the meantime, Gupta said users can protect themselves by not accepting any headers containing Unicode characters at the Akamai level. 

**Tampering header commands**

To exploit the vulnerability, an attacker must send a web request for a benign file, but modify the header directives to add a header preceded by a hex value (e.g. ) and followed by the malicious S3 address.

If the request results in a cache hit, then the Akamai server will prioritize the header with the Unicode value over the original header and cache the malicious file to serve it to future users who request the same path.

“Because of the S3 misconfiguration, it prioritizes the first header over the target origin and Akamai’s incorrect parsing on the inclusion of Unicode character let me pass exactly what I wanted to the S3 buckets, a malicious host on the first occurrence of the header,” Gupta explained.

**Attacking at scale**

The attack will only work if benign and malign files are stored in S3 buckets located in the same region. The attacker can create S3 buckets in all available regions and upload the malicious file to all of them.

Exploiting the bug would then be a matter of brute-forcing the web cache poisoning attack on the target web resource to see which bucket works.

Gupta tested the attack with an SVG file, which is usually a cached file type and can contain JavaScript code – making it especially dangerous. But the attack can also work with any other file type cached by the server.

Gupta also developed a pair of Python scripts that can find targets stored in S3 buckets and cached by Akamai.

“This issue is very easy to exploit, and one simple cURL can create a malicious cache,” Gupta said. “An automation script was created to exploit at scale. This issue can result in various types of attacks such as XSS, JavaScript injection, open redirection, DoS, spoofing, etc.”

**RFC non-compliance**

Akamai told Gupta that the configuration issue “results from certain customers’ needs to process non-RFC compliant requests for their applications to function correctly, and therefore cloud vendors offering features to support such traffic unless explicitly instructed not to do so.”

Kaan Onarlioglu, senior infosec architect at Akamai, told The Daily Swig: “By default, Akamai edge servers allow certain invalid HTTP headers to pass through, treating them as custom headers.”

Catch up with the latest hacking techniques news and analysis

This feature is necessary to support large volumes of legitimate traffic flows and origin applications that rely on invalid headers to function correctly, he said. However, it could sometimes lead to unexpected interactions between Akamai and origin servers, depending on the origin’s request processing behavior.

“Akamai provides a strict header parsing configuration option to block traffic containing invalid headers, and we strongly urge our customers to utilize it unless that interferes with their operations,” Onarlioglu continued.

According to Onarlioglu, Akamai is currently working on making strict header parsing a default behavior instead of offering an opt-out mechanism for customers. The work is expected to be finalized early in 2023.

Gupta advised web developers to always follow RFC and its recommendations. “Many companies don’t follow them and also don't put any countermeasures around it, which sometimes becomes a serious issue,” he said.

RECOMMENDED Researcher discovers 70 web cache poisoning vulnerabilities, nets $40k in bug bounty rewards

Akamai wrestles with AWS S3 web cache poisoning bug 

Large vendors are commoditizing capabilities that claim to provide absolute security guarantees backed up by formal verification. How significant are these promises?

There is no software without bugs, right? While this is a common sentiment, we make assumptions that rely on the premise that software has no bugs in our day-to-day digital life. We trust identity providers (IDPs) to get authentication right, operating systems to perfectly comply with their specs, and financial transactions to always perform as intended. Even more vividly, we trust software with our physical safety by going on planes, driving a car that actively corrects our adherence to traffic lanes or our distance from the car in front of us, or undergoing certain surgeries. What makes this possible? Or to put it another way, why aren't planes falling out of the sky due to bad software?

Software quality assurance borrows from scientific and engineering tools. One way to ensure and improve software quality is to publicize it and give as many people as possible an incentive to try to break it.

Another is using design patterns or well-architecture frameworks rooted in engineering. For example, while not every software project can be put under the same level of scrutiny as the Linux kernel, which has been under scrutiny for decades, software projects can open source code to invite scrutiny or submit code for audits in hopes to gain some of the security guarantees.

And of course, there's testing. Whether static, dynamic, or real-time, done by the developer or by a dedicated team, testing is a major part of software development. With critical software, testing is usually an entirely separate project handled by a separate team with specific expertise.

Testing is good, but it doesn't claim to be comprehensive. There are no guarantees we found all the bugs because we don't know which bugs we don't know about. Did we already find 99% of Linux kernel bugs out there? 50%? 10%?

**The 'Absolute' Claim**

The research field of formal methods is looking at ways to assure you that there are no bugs in a certain piece of software, such as your stockbroker or certificate authority. The basic idea is to translate software into math, where everything is well-defined, and then create an actual proof that the software works with no bugs. That way, you can be sure that your software is bug-free in the same way you can be sure that every number can be decomposed to a multiplication of prime numbers. (Note that I don't define what a bug is. This will prove to be a problem, as we will later see.)

Formal method techniques have long been used for critical software, but they were extremely compute- and effort-intensive and so applied only to small pieces of software, such as a limited part of chip firmware or an authentication protocol. In recent years, advanced theorem provers like Z3 and Coq have made it possible to apply this technology in a larger context. There are now formally verified programming languages, operating systems, and compilers that are 100% guaranteed to work according to their specifications. Applying these technologies still requires both advanced expertise and a ton of computing power, which make them prohibitively expensive to most organizations.

Major cloud providers are performing formal verification of their fundamental stacks to reach high levels of security assurance. Amazon and Microsoft have dedicated research groups that work with engineering teams to incorporate formal verification methods into critical infrastructure, such as storage or networking. Examples include AWS S3 and EBS and Azure Blockchain. But the really interesting fact is that in the past few years, cloud providers have been trying to commoditize formal verification to sell to their customers.

**Decisively Solving Misconfiguration?**

Last year, AWS released two features that leverage formal verification to address issues that have long plagued their customers, namely network and identity and access management (IAM) misconfigurations. Network access and IAM configurations are complex, even for a single account, and that complexity grows drastically in a large organization with distributed decision-making and governance. AWS addresses it by giving its customers simple controls — such as "S3 buckets should not be exposed to the Internet" or "Internet traffic to EC2 instances must go through a firewall" — and guaranteeing to apply them in every possible configuration scenario.

AWS is not the first to address the misconfiguration problem, even for AWS-specific issues such as open S3 buckets. Cloud security posture management (CSPM) vendors have been addressing this issue for a while now, analyzing virtual port channel (VPC) configuration and IAM roles and identifying cases where privileges are too lax, security features are not properly used, and data can be exposed to the Internet. So what's new?

Well, this is where the absolute guarantee comes in. A CSPM solution works by creating a known-bad or known-good list of misconfigurations, sometimes adding context from your environment, and producing results accordingly. Network and IAM analyzers work by examining every potential IAM or network request and guaranteeing that they will not result in unwanted access according to your specification (such as "no Internet access"). The difference is in the guarantees about false negatives.

While AWS claims that there is no way it has missed anything, CSPM vendors say they are always on the lookout for new misconfigurations to catalog and detect, which is an admission that they did not detect these misconfigurations previously.

**Some Flaws of Formal Verification**

Formal verification is great for finding well-defined issues, such as memory security issues. However, things become difficult when trying to find logical bugs because those require specifying what the code is actually supposed to do, which is exactly what the code itself does.

For one thing, formal verification requires specifying well-defined goals. While some goals, like preventing access to the Internet, seem simple enough, in reality they are not. The AWS IAM analyzer documentation has an entire section defining what "public" means, and it's full of caveats. The guarantees it provides are only as good as the mathematical claims that it has coded.

There's also the question of coverage. AWS analyzers cover only a few major AWS services. If you route traffic into your network through an outbound connection channel, the analyzer wouldn't know. If some service has access to two IAM roles and can combine them to read from a confidential public bucket and write to a public one, the analyzer wouldn't know. Nevertheless, on some well-defined subset of the misconfiguration problem, formal verification provides stronger guarantees than ever before.

Getting back to the relative advantage question posed above, the difference is that the IAM and network analyzer claims that its list of issues detected is comprehensive, while CSPM claims that its list covers every misconfiguration known today. Here's the key question: Should you care?

**Should We Care About Absolute Guarantees?**

Consider the following scenario. You own a CSPM and look at the AWS network and IAM analyzer. Comparing the results of the two, you realize that they've identified the exact same problems. After some effort, you fix every single problem on that list. Relying only on your CSPM, you would feel you are in a good place now and could dedicate security resources elsewhere. By adding AWS analyzers to the mix, you now know — with an AWS guarantee — that you are in a good place. Are these the same results?

Even if we neglect the caveat of formal verification and assume that it catches 100% of issues, measuring the benefits over detection-based services like CSPM would be an exercise for every individual organization with its own security risk appetite. Some would find these absolute guarantees groundbreaking, while others would probably stick to existing controls.

These questions are not unique to CSPM. The same comparisons could be made for SAST/DAST/IAST web application security testing tools and formally verified software, to name one example.

Regardless of individual organization choices, one exciting side effect of this new technology would be an independent way to start measuring security solutions' false negative rates, pushing vendors to be better and providing them with clear evidence where they need to improve. This in and of itself is a tremendous contribution to the cybersecurity industry.

Are 100% Security Guarantees Possible?

Softr v2.0 was discovered to be vulnerable to HTML injection via the Name field of the Account page.

**Build custom apps for your business, as easy as lego**

|

Turn your Airtable or Google Sheets into client portals, partner apps or internal tools.

**Trusted by 80,000+ teams worldwide**

**Create apps powered by your data**

**Client Portals**

Create client or employee portals with self-service account creation and secure access to content.

**Internal Tools**

Enable your team to create internal apps like employee directories, CRM, and company wikis, in minutes.

**Marketplaces**

Create two sided marketplaces like Airbnb, Upwork and the like. Sell services, goods, pay securely with Stripe and run your entire business from one tool.

**Online Communities**

Supercharge your community and bring them together in one platform, with memberships, free and premium content. Share resources, sell courses, connect with each other and more.

**Resource Directories**

Curate resources of any kind and let users search, filter, and explore. Launch online courses, company wikis or upvoting sites directly from Airtable.

**Websites**

Quickly create multi-page marketing sites or high-converting landing pages. Add your custom domain for free.

**Softr is the easiest, fastest way to build a professional web app on Airtable. Zero learning curve.**

**80,000+ companies and creators use Softr**

I had already tried other tools, so when I started using Softr, it was clear immediately that the capabilities were beyond what I found elsewhere.

**Yohei Nakajima**

General Partner, Untapped Capital

Softr helps you take action on your ideas quickly by allowing you to leverage your Airtable data and build powerful websites and web apps. I was blown away by how user-friendly and well-documented the entire product was! I was able to create an app within hours without any external help.

**Karthik Puvvada (KP)**

Program Director, On Deck No-Code Fellowship

Softr’s ease and speed of use is it’s standout characteristic. No tool is faster to create with. Although there is limited design customizability, this should be viewed as a strength of Softr as it acts as a positive restraint to help you ship things more quickly than you ordinarily would.

**Max Haining**

Founder, 100DaysOfNoCode

They say that if you can’t explain it in a simple way, you don’t understand it well enough. I say the same thing about any software. If you can’t figure it out in the first 10 min by yourself without any tutorial, it’s probably not for you. Since the first moment we discovered Softr, we started the work.

**Akiki Rachid**

COO, Bookzdoctr Inc

It took me one day to build the product, learn the integrations, and see how the customer service acts. I was completely flashed that it is so easy, and that everything is working really well. So, I quickly decided 3 weeks later to set up our main page and transferred it to Softr.

**Sabine Wildemann**

Co-Founder, KidsCircle

I have been impressed with the flexibility of Softr. The ability to pull data from different Airtable bases into different blocks and display them on one page was one of the main reasons I chose Softr.

**Dan Smith**

Director, DS Automotive

As a small business, we needed to use a tool that could grow with us, and we feel that this is what Softr offers us. After wasting time and money trying every web builder under the sun, Softr came to save the day. We cannot recommend this platform enough – it's perfect, easy to use even for a non-technical person like me.

**Lucia Borraccino**

Founder, Nanny Network

I like the diversity of templates that are available and the thoughtfulness that has been taken in making the building process as simple as possible for non-coders.

**Kwaku Dapaah-Danquah**

Entrepreneurship Manager, YSYS

I used Softr to build the MVP for my company www.tallsize.com.When I discovered how easy it was to use Softr to create a frontend interface for our users, my mind was blown!!! It was so easy to set up that I literally launched my site in a single weekend. Their support team was incredible throughout this journey and the ability to customize everything the way I wanted was very intuitive and easy to accomplish.

**Nicole Murphy**

Founder, Tall Size

I have been using Softr for a few months now, and the list of new features & improvements is PHENOMENAL. A no-brainer pick for now and a really good bet for the future!

**Nic Touron**

Founder, ToolMeUp

With Softr, I’m able to create beautifully intuitive and responsive front-ends that integrate directly with Airtable and Stripe. Softr allows me to create and iterate at least twice as fast as traditional web platforms.

**Connor Gustafson**

Founder, LendingApp

Softr is THE no-code website builder to use. From SEO and site responsiveness to database backends and customer support, Softr is the deal of the century!

**Patrick Ford**

Founder, Adastacks

**Simple, yet powerful**

**As simple as building lego**

Start from a template or from 100+ pre-built blocks and customize any element on the page. No design or coding skills needed.

**Build platforms, not just sites**

Turn your Airtable data into a full-stack web-app with out-of-the-box memberships, payments and business logic, all in one place.

**Turn into a mobile app, with one click**

Immediately made available on both Apple and Android devices, without the extra effort.

**Start now, go live today**

Don't spend hours learning new tools. Softr is the quickest way to put a product in the hands of your customers. Changing things later is easy and instant.

**This website is built on Softr**

Join 80,000+ companies already using Softr.

**Powerful pre-built functionality out of the box**

Softr does the heavy lifting of all technical work for you, so you can focus on your business.

**Secure user accounts**

Keep yours and your customers' data safe with server-side password protection.

**Free custom domain**

Our free tier includes hosting on custom domains. No credit card required.

**Team Collaboration**

Invite your teammates to manage the application and set granular permissions

**Easy online payments**

Enable one-off purchases or subscriptions in seconds.

**Optimized for SEO**

Pages built with Softr are automatically indexed by search engines.

**Performant, safe, and scalable**

Enjoy Amazon AWS-powered security and performance.

**Integrate with the tools you love**

Seamlessly integrate your Softr app with the modern and trusted tools of your workflow like Zapier, Google Analytics, Stripe, Hotjar, Mailchimp and more.

**Run your business on Softr + Airtable**

**For Companies**

Explore how SMBs and startups use Softr to manage and grow their business.

LEARN MORE

**For Creators**

Learn how entrepreneurs of all sizes are starting new ventures in days with Softr.

LEARN MORE

**For Non-Profits**

Organizations of all kinds can run their operations online, saving time and money.

**Learn about companies and creators using Softr**

CVE-2022-40434: Build website, web app & portals on Airtable without code | Softr

By Waqas
In total, 117 million files were exposed due to two misconfigured Amazon Web Services S3 buckets.
This is a post from HackRead.com Read the original post: Top American Online Ed Platform Leaks 22TB of Data

The incident took place when two misconfigured AWS S3 buckets belonging to McGraw Hill, one of the “big three” educational publishers in the US, were left exposed without any security authentication.

The cyber security researchers at vpnMentor discovered a couple of **misconfigured Amazon Web Services (AWS) S3 buckets** containing a massive trove of data belonging to a USA-based education publishing firm, McGraw Hill.

The platform is among the top three educational content publishers in the United States, and it is also widely used by educational institutions across Canada for facilitating online classes. It builds educational software for students who can access lectures and upload homework on its portal.

**Findings Details**

Researchers discovered two misconfigured Amazon Web Services S3 buckets, the owner of which was identified to be **McGraw Hill**. The researchers discovered one non-production bucket containing over 69 million documents and 10TB+ of data and one production bucket containing 12TB+ of data.

In total, 22TB of data was exposed, and the buckets contained 117 million files. The buckets were discovered on 12 June 2022. vpnMentor’s researchers contacted McGraw Hill first on 13 June, 2022 then again on 15 June and 20 June 2022.

They contacted them the fourth time on 27 June 2022 and finally reached USA CERT several times between 27 June and 4 July 2022. In total, vpnMentor tried to contact McGraw Hill nine times. On 7 July 2022, vpnMentor contacted Amazon Web Service, and finally, they received a response on 9 July 2022.

**What Data Got Exposed?**

According to vpnMentor’s **blog post**, around 100,000 students could be exposed to numerous online attacks due to this data breach. Their private data, such as personal details and grades, could be at risk, and anyone could access it using a web browser.

Further, the exposed data included excel sheets containing student data such as email IDs, names, and grades, documents featuring students’ assignments, performance reports, and grades, and documents containing syllabi for the teachers.

Screenshot taken from one of the exposed files (Credit: vpnMentor)

Moreover, the data included reading material for different courses, source code for McGraw Hill, and private digital keys from McGraw Hill. The leaking of source code is dangerous as it can help threat actors to search for other flaws.

Reportedly, the breach or incident impacted students from the following universities:

1.  McGill University
2.  University of Illinois
3.  University of Toronto
4.  University of Michigan
5.  Johns Hopkins University
6.  Washington University in St Louis
7.  University of California, Los Angeles

**What Caused the Exposure?**

Researchers noted that McGraw Hill was using AWS S3 buckets for storing data from their online education service since the exposed data belonged to the company’s online learning portal that was connected to the AWS account.

Researchers were certain that Amazon wasn’t responsible for the misconfigured database. After several failed attempts to bring the issue to the company’s notice, vpnMentor could contact them, and the sensitive files were removed from public exposure on 20 July.

The data exposure might have a far-reaching impact because users worldwide are affected by this exposure. However, it is unclear whether the servers were accessed by a **third party with malicious intent** or not.

Nevertheless, at the time of publishing this article, both exposed servers had been secured, thanks to vpnMentor’s non-stop alerts to concerned authorities.

1.  **AWS bucket exposed 421GB of Artwork Archive data**
2.  **350 million email addresses exposed in AWS S3 bucket**
3.  **S3 Cloud Bucket Exposed 100GB of Classified NSA Data**
4.  **Pegasus Airlines Leaked 6.5TB of Data in AWS S3 Bucket**
5.  **S3 bucket exposed 182GB of senior US, Canada citizens’ data**

I am a UK-based cybersecurity journalist with a passion for covering the latest happenings in cyber security and tech world. I am also into gaming, reading and investigative journalism

Top American Online Ed Platform Leaks 22TB of Data

Today, Talos is publishing a glimpse into the most prevalent threats we've observed between Dec. 9 and Dec. 16. As with previous roundups, this post isn't meant to be an in-depth analysis. Instead, this post will summarize the threats we've observed by highlighting key

Threat Round up for December 9 to December 16

It's time for on-the-record answers to questions about data destruction in cloud environments. Without access, how do you verify data has been destroyed? Do processes meet DoD standards, or do we need to adjust standards to meet reality?

These days, most big companies and many midsize ones have some form of a data-governance program, typically including policies for data retention and destruction. They have become an imperative because of increasing attacks on customer data and also state and national laws mandating protection of customer data. The old mind set of "Keep everything, forever" has changed to "If you don't have it, you can't breach it."

In some ways, managing data-retention policies has never been easier to implement in the cloud. Cloud vendors often have easy templates and click-box settings to retain your data for a specific period and then either move it to quasi-offline cold digital storage or straight to the bit bucket (deletion). Just click, configure, and move on to the next information security priority.

**Just Click Delete?**

However, I'm going to ask an awkward question, one that has been burning in my mind for a while. What really happens to that data once you click "delete" on a cloud service? In the on-premises, hardware world, we all know the answer; it would simply be deregistered on the disk it resides on. The "deleted" data still sits on the hard drive, gone from the operating system view and waiting to be overwritten when the space is needed. To truly erase it, extra steps or special software are needed to overwrite the bits with random zeros and ones. In some cases, this needs to be done multiple times to truly wipe out the phantom electronic traces of the deleted data.

And if you do business with the US government or other regulated entities, you may be required to comply with Department of Defense standard 5220.22-M, which contains specifics on data destruction requirements for contractors. These practices are common, even if not required by regulations. You don't want data you don't need any more coming back to haunt you in the event of a breach. The breach of the Twitch game-streaming service, in which hackers were able to gain access to basically all of its data going back almost to the inception of the company — including income and other personal details about its well-paid streaming clients — is a cautionary tale here, along with reports of other breaches of abandoned or orphaned data files in the last few years.

**Lack of Access to Verify**

So, while the policies are easier to set and manage in most cloud services versus on-premises servers, assuring it is properly done to the DoD standard is much harder or impossible on cloud services. How do you do a low-level disk overwrite of data on cloud infrastructure where you don't have physical access to the underlying hardware? The answer is that you can't, at least not the way we used to do it — with software utilities or outright destruction of the physical disk drive. Neither AWS, Azure, or Google Cloud Services offer any options or services that do this, not even on their dedicated instances, which run on separate hardware. You simply don't have the level of access needed to do it.

Outreach to the major services either was ignored or answered with generic statements about how they protect your data. What happens to data that is "released" in a cloud service such as AWS or Azure? Is it simply sitting on a disk, nonindexed and waiting to be overwritten, or is it put through some kind of "bit blender" to render it unusable before being returned to available storage on the service? No one, at this point, seems to know or be willing to say on the record.

**Adjust to New Reality**

We must develop a cloud-compatible way of doing destruction that meets the DoD standards, or we must stop pretending and adjust our standards to this new reality.

Maybe cloud providers can come up with a service to provide this capability, since only they have direct access to the underlying hardware. They have never been shy about inventing new services to charge for, and certainly plenty of companies would be eager to pay for such a service, if the appropriate certificates of destruction were provided. It would probably be cheaper than fees charged by some of the companies providing certified physical-destruction services.

Amazon, Azure, Google, and any major cloud service (even software-as-a-service providers) need to address these issues with real answers, not obfuscation and marketing-speak. Until then, we will just be pretending and hoping, praying some brilliant hacker doesn't figure out how to access this orphaned data, if they haven't already. Either way, the hard questions on cloud data destruction need to be asked and answered, sooner rather than later.

Data Destruction Policies in the Age of Cloud Computing

Attackers also could breach internal production data to compromise a corporate network using vulnerabilities found in the BrickLink online platform.

API flaws in a widely used Lego online marketplace could have allowed attackers to take over user accounts, leak sensitive data stored on the platform, and even gain access to internal production data to compromise corporate services, researchers have found.

Researchers from Salt Labs discovered the vulnerabilities in BrickLink, a digital resale platform owned by the Lego Group for buying and selling second-hand Legos, demonstrating that — technology-wise, anyway — not all of the company's toy pieces snap perfectly into place.

Salt Security's research arm discovered both vulnerabilities by investigating areas of the site that support user input fields, Shiran Yodev, Salts Labs security researcher, revealed in a report published on Dec. 15.

The researchers found each of the core flaws that could be exploited for attack in parts of the site that allow for user input, which they said is often a place where API security issues — a complex and costly problem for organizations — arise.

One flaw was a cross-site scripting (XSS) vulnerability that enabled them to inject and execute code on a victim end user’s machine through a crafted link, they said. The other allowed for the execution of an XML External Entity (XXE) injection attack, where an XML input containing a reference to an external entity is processed by a weakly configured XML parser.

**API Weaknesses Abound**

The researchers were careful to stress that they didn't intend to single out Lego as a particularly negligent technology provider — on the contrary, API flaws in Internet-facing applications are incredibly common, they said.

There is a key reason for that, Yodev tells Dark Reading**:** No matter the competency of an IT design and development team, API security is a new discipline that all Web developers and designers are still figuring out.

"We readily find these kinds of serious API vulnerabilities in all sorts of online services we investigate," he says. "Even companies with the most robust application security tooling and advanced security teams frequently have gaps in their API business logic."

And while both flaws could have been discovered easily through pre-production security testing, "API security is still an afterthought for many organizations," notes Scott Gerlach, co-founder and CSO at StackHawk, an API security testing provider.

"It usually doesn't come into play until after an API has already been deployed, or in other cases, organizations are using legacy tooling not built to test APIs thoroughly, leaving vulnerabilities like cross-site scripting and injection attacks undiscovered," he says.

**Personal Interest, Rapid Response**

The research to investigate Lego's BrickLink was not meant to shame and blame Lego or "make anyone look bad," but rather to demonstrate "how common these mistakes are and to educate companies on steps they can take to protect their key data and services," Yodev says.

The Lego Group is the world’s largest toy company and a massively recognizable brand that can indeed draw people's attention to the issue, the researchers said. The company earns billions of dollars in revenue per year, not only because of children's interest in using Legos but also as a result of an entire adult hobbyist community — of which Yodev admits he is one — that also collects and builds Lego sets.

Because of the popularity of Legos, BrickLink has more than 1 million members that use its site.

The researchers discovered the flaws on Oct. 18, and, to its credit, Lego responded quickly when Salt Security revealed the issues to the company on Oct. 23, confirming the disclosure within two days. Tests conducted by Salt Labs confirmed shortly after, on Nov. 10, that the issues had been resolved, the researchers said.

"However, due to Lego's internal policy, they cannot share any information regarding reported vulnerabilities, and we are therefore unable to positively confirm," Yodev acknowledges. Moreover, this policy also prevents Salt Labs from confirming or denying if attackers exploited either of the flaws in the wild, he says.

**Snapping Together the Vulnerabilities**

Researchers found the XSS flaw in the “Find Username” dialog box of BrickLinks' coupon search functionality, leading to an attack chain using a session ID exposed on a different page, they said.

"In the 'Find Username' dialog box, a user can write a free text that eventually ends up rendered into the webpage’s HTML," Yodev wrote. "Users can abuse this open field to input text that can lead to an XSS condition."

Though the researchers couldn't use the flaw on its own to mount an attack, they found an exposed session ID on a different page that they could combine with the XSS flaw to hijack a user's session and achieve account takeover (ATO), they explained.

"Bad actors could have used these tactics for full account takeover or to steal sensitive user data," Yodev wrote.

Researchers uncovered the second flaw in another part of the platform that receives direct user input, called "Upload to Wanted List," which allows BrickLink users to upload a list of wanted Lego parts and/or sets in XML format, they said.

The vulnerability was present due to how the site's XML parser uses XML External Entities, a part of the XML standard that defines a concept called an entity, or a storage unit of some type, Yodev explained in the post. In the case of the BrickLinks page, the implementation was vulnerable to a condition in which the XML processor may disclose confidential information that's typically not accessible by the application, he wrote.

Researchers exploited the flaw to mount an XXE injection attack that allows a system-file read with the permissions of the running user. This type of attack also can allow for an additional attack vector using server-side request forgery, which might enable an attacker to gain credentials for an application running on Amazon Web Services and thus breach an internal network, the researchers said.

**Avoiding Similar API Flaws**

Researchers shared some advice to help enterprises avoid creating similar API issues that can be exploited on Internet-facing applications in their own environments.

In the case of API vulnerabilities, attackers can inflict the most damage if they combine attacks on various issues or conduct them in quick succession, Yodev wrote, something the researchers demonstrated is the case with the Lego flaws.

To avoid the scenario created with the XSS flaw, organizations should follow the rule of thumb "to never trust user input," Yodev wrote. "Input should be properly sanitized and escaped," he added, referring organizations to the XSS Prevention Cheat Sheet by the Open Web Application Security Project (OWASP) for more information on this topic.

Organizations also should be careful in their implementation of session ID on Web-facing sites because it's "a common target for hackers," who can leverage it for session hijacking and account takeover, Yodev wrote.

"It is important to be very careful when handling it and not expose or misuse it for other purposes," he explained.

Finally, the easiest way to stop XXE injection attacks like the one researchers demonstrated is to completely disable External Entities in your XML parser’s configuration, the researchers said. The OWASP has another useful resource called the XXE Prevention Cheat Sheet that can guide organizations in this task, they added.

API Flaws in Lego Marketplace Put User Accounts, Data at Risk

Threat actors leak employee email addresses, corporate reports, and IT asset information on a hacker forum after an attack on an Uber technology partner.

Uber has suffered yet another high-profile data leak that exposed sensitive employee and company data. This time, attackers breached the company by compromising an Amazon Web Services (AWS) cloud server used by a third party that provides Uber with asset management and tracking services.

The incident happened over the weekend, when a threat actor named "UberLeaks" began posting data they claimed was stolen from Uber and Uber Eats. The data turned up on the BreachForums hacking forum, the successor of now-defunct RaidForums, media outlets reported, and included employee email addresses, corporate reports, and IT asset information stolen.

Hackers posted a number of archives that they said are source-code associated with various mobile device management (MDM) platforms used by Uber, as well as by Uber Eats and third-party vendor services, according to reports. While no user information appears to have been compromised in the breach — which appears to entirely have affected corporate assets — the personal information of 77,000 Uber employees was leaked.

**Hacker Breaches Tequivity AWS Server **

Uber acknowledged the incident and pointed the media to a breach notification by a company called Tequivity, which it uses for asset management and tracking services.

Tequivity explained that "customer data was compromised" due to "unauthorized access" to the company's systems by "a malicious third party," according Tequivity's release. Specifically, attackers gained access to the company's AWS backup server, which houses code and data files related to Teqtivity customers, the company said.

It's unclear if that access was due to a misconfiguration of the cloud bucket, or if there was an actual compromise to blame.

Information exposed by the attack included information housed on various Uber employees' IT devices, including serial number, make, models, and technical specifications, as well as employee information, including first and last names, work email addresses, and work location details, according to Teqtivity.

Teqtivity has notified affected customers and is currently investigating as well as working to contain the incident, according to the notification. It's unclear if the breach affects other companies beyond Uber.

**Ongoing Security Issues**

This latest incident is indeed not Uber's first rodeo when it comes to data breaches, as the company has experienced several highly publicized incidents over the past several years that have had significant ramifications for the company.

In fact, a previous third-party breach that occurred in 2016 and exposed the data of some 57 million customers and drivers turned into an absolute public-relations nightmare for Uber, the effects of which are still being felt.

That incident — in which attackers also gained access to Uber data stored in third-party cloud storage — resulted in the firing of its now-former CISO Joe Sullivan after it was discovered that the company engaged in a cover-up of the incident. Sullivan was even found guilty in federal court on charges related to the incident in October.

Uber also experienced a significant breach in September and was forced to take some of its operations offline due to the compromise of its own internal systems, when an attacker socially engineered his way into an employee's VPN account before pivoting deeper into the network.

**Is the Lapsus$ Gang Responsible for the Uber Breach?**

While no particular threat group has claimed responsibility or has yet been found to be the guilty party behind the latest breach, there are some initial clues that tie the incident to the well-known cybercriminal extortion group Lapsus$.

The post on BreachForums about the Uber leak reportedly mentions the threat group, while Lapsus$ is believed to be responsible for the Uber September breach as well, Robert Ames, threat researcher from SecurityScorecard, tells Dark Reading.

Ames also notes the responsibility of Lapsus$ for a January incident at Okta, another "major third-party service for many firms," as a potential clue that the threat group also is at play here. That incident was determined to have affected about 366 Okta customers, the company acknowledged.

Lapsus$ went quiet around July after a spate of incidents earlier in the year including not only the one against Okta, but also attacks on Microsoft and Nvidia. Its responsibility for the September attack on Uber could be a sign of another flurry of activity from the threat group, experts say.

**Time to Manage Third-Party and Cloud Cybersecurity Risk**

No matter who's responsible, the latest Uber incident, like the one in 2016, once again highlights the third-party risk that all enterprises face when partner companies are responsible for or have access to corporate data and assets, security experts say.

A core issue is that many organizations don't secure third-party access to internal data in the same way they secure it within organization IT assets, which leaves that data unnecessarily exposed to outside threats, Ames says.

"Vendors and other third-parties are often granted the same access as employees but with fewer security measures, making them a weak link and therefore a popular target for threat actors," he says. "When hackers access a third party’s systems, they can access whatever data that system stores, even if it belongs to other organizations."

Indeed, this is an issue not unique to Uber, but one that demonstrates that "companies everywhere must better prioritize their cybersecurity measures," especially when it comes to third parties, Stephan Chenette, co-founder and CTO at AttackIQ, says.

Some ways companies can do this include mapping organizational capabilities and security controls to specific attack scenarios to measure their preparedness to detect, prevent, and respond to these threats, he says.

"They should also continuously evaluate their existing security controls to uncover gaps before a hacker finds and exploits any weaknesses," Chenette says.

Enterprises also should be continuously monitoring their specific third-party cybersecurity posture to reduce the likelihood of attacks, Ames says. This will help give them a more complete picture of their entire attack surface as they seek ways to gain visibility into potential and existing vulnerabilities.

Ames adds that participating in tabletop exercises and threat emulation to ensure that security administrators and employees alike are familiar with countering and responding to threat actors also can help organizations better respond to third-party threats.

Tag

#amazon