Search This Blog

Powered by Blogger.

Blog Archive

Labels

Showing posts with label SSRF. Show all posts

SRF: Investigation Links Qatar to FIFA Hacking and Ex-CIA Operative’s Firm

 

Qatar reveals to have launched a large-scale and long-standing operation against FIFA officials via ex-CIA operatives. With Switzerland serving as a key operator, the highest circles of the Qatari government were as well involved in the espionage operation that was working in secret. 

With the intelligence agents involved planned on swaying the world events in the operation and hackers stealing controversial information and data, the operation was in fact funded by an anonymous client with hundreds of millions of dollars. 

The issue came to light when an investigation by Swiss media SRF’s investigative team ‘SRF Investigativ’ shared details of how the state of Qatar had officials of the world football spied on. Additionally, the investigations showed how the non-FIFA critics of the upcoming World Cup were targeted as well. 

According to the English- version of the report by Tariq Panja from The York Times, The SRF News revealed that Qatar hired an ex-CIA operative Kevin Chalker’s “Global Risk Advisors” firm for “predictive intelligence” on FIFA officials who would attempt on moving the World Cup from the country, via their predictive intelligence efforts allegedly involving computer hacking through intermediaries. 

The ultimate goal of the said efforts is to prevent Qatar from losing the World Cup bid, following the massive criticism that was raised when FIFA awarded the tournament to the authoritarian country in 2010. 

The scope of the covert activities remains considerable, since at least 66 operators were expected to be deployed over the course of one sub-operation alone for over nine years. Moreover, a budget of $387 million was allocated for the operation, with the activities spanning five continents. 

The SRF investigations dig the credentials against the ex-CIA agent Chalker. The investigation deduces that initially, before the World Cup awarding in December 2010, Chalker apparently served as an espionage operator for various bids. But as the criticism raised regarding corruption and human rights violation after the 2010 World Cup was awarded, the target was eventually changed. Now, the goal shifted to preventing FIFA, from taking the World Cup from Qatar, at all costs. 

The investigation showed that Switzerland was the most prominent factor to Qatari intelligence operation. Since, Chalker travelled to Zurich at the demand of Qatar with the intention of bugging the hotel rooms of journalists and members of the Executive Committee. One of the documents revived, included photos taken covertly as a part of surveillance operation. These photographs were reportedly taken at Zurich’s plush Baur au Lac hotel, and showed individuals connected to FIFA meeting with officials and journalists. 

Apparently, FIFA mostly remined oblivious to the spy operation. Sepp Blatter, FIFA’s former President, commented in an interview with SRF, “That there was an organized espionage affair in FIFA, that surprised me. And it's alarming.” Although, several documents indicate that Blatter was of great interest to the spies. The documents mention, for instance, that Blatter’s “plans and intentions” ought to be known in advances. 

Besides, Chalker and Global Risk Advisors are currently dealing with a civil lawsuit, in regard to connection to similar alleged activities. The lawsuit was filed by former US president Donald Trump ally Elliot Broidy. Broidy accused Chalker and his company of a hacking attack on behalf of Qatar, after Broidy’s personal data was leaked to newspapers in 2018. Although, Chalker denies all allegations. The lawsuit is still pending.

SSRF Attacks can be Used to Compromise Java RMI Services

 

According to a detailed analysis of the problem by security researcher Tobias Neitzel, Java RMI services can be targeted using server-side request forgery (SSRF) attacks. Server-side request forgery (SSRF) is a type of attack that allows attackers to send fraudulent requests to other systems by exploiting a vulnerable web server. 

Requests between HTTP servers can be initiated by web applications. These are commonly used to retrieve remote resources such as software updates or to import metadata from a URL or another web application. Such inter-server requests are not inherently harmful, but if not performed correctly, they can expose a server to server-side request forgery. When user-controllable data is utilized to construct the target URL, an SSRF vulnerability is introduced. An attacker can then use an SSRF attack to initiate or control requests from the vulnerable server by changing a parameter value in the vulnerable web application.

Java RMI is an object-oriented Remote Procedure Call (RPC) mechanism that is included in the vast majority of Java installations. The technology can be used by software developers to make functionality available through a network. Java RMI relies on serialized Java objects for communication, a mechanism that attackers can exploit despite the fact that the technology has been hardened and tempered in recent years, according to Neitzel.

“As with all SSRF techniques, the major problem is that attackers may be able to attack RMI services that are supposed to only be accessed from trusted networks,” Neitzel explained. “Securing RMI properly is not that intuitive and there is a lot of hidden attack surface. Instead of configuring it properly, administrators often take the easy route and only allow access from trusted networks or clients.” 

JMX is the most often utilized RMI service. Neitzel demonstrated that SSRF can be used to compromise a backend JMX service, but only if the system delivers responses from the backend service and accepts arbitrary bytes inside them. Similarly, SSRF-based attacks on default RMI components like the RMI registry are conceivable, but only if the system enables arbitrary bytes to be delivered to the backend service. 

The German researcher goes on to list security best practices and counter-measures for RMI services against potential attacks in his blog post. These include enabling TLS-enabled communication for all RMI endpoints, employing deserialization filters, and implementing stricter authentication controls.

A URL Parsing Bug Left an Internal Google Cloud Project Open to SSRF Attacks

 

According to security researcher David Schütz, a URL parsing flaw exposed an internal Google Cloud project to server-side request forgery (SSRF) attacks. The bug, which Schütz detailed in a video and blog post, might have allowed an attacker to gain access to sensitive resources and perhaps launch harmful code.

Server-side request forgery is a web security flaw that allows an attacker to force a server-side application to send HTTP requests to any domain the attacker chooses. The attacker may cause the server to connect to internal-only services within the organization's infrastructure in a conventional SSRF attack. They may also be able to force the server to connect to arbitrary external systems, exposing sensitive data such as authorization credentials. 

Unauthorized activities or access to data within the company can often arise from a successful SSRF attack, either in the vulnerable application itself or on other back-end systems with which the programme can interface. The SSRF vulnerability could allow an attacker to execute arbitrary commands in some circumstances. An SSRF vulnerability that establishes connections with external third-party systems could lead to malicious attacks that appear to come from the company that hosts the vulnerable application. 

While researching Discovery Documents, data structures that give specifications for Google API services, Schütz discovered the problem. While looking through the Discovery Documents, Schütz came upon an intriguing service named Jobs API, which had the appearance of being an internal service. The Jobs API led him to an application on the Google App Engine that acted as a proxy, allowing him to access the API through Google's public product marketing pages. The proxy acted as an intermediate between the user and the API, which meant it had an access token that could be used to launch SSRF attacks. 

Request URLs were run via a whitelist to restrict access to internal Google resources. Schütz, however, was able to fool the URL parser and bypass the whitelist, allowing him to send requests to any server he wanted. This allowed him to send requests from the proxy app to a Google Cloud VPS server. The request revealed the proxy app's access token, which he could then use to send requests to other Google Cloud projects.

“This issue feels like an industry-wide problem since different applications are parsing URLs based on different specifications,” Schütz said. “After disclosing the initial issue in the Google JS library, I have already seen this getting fixed in products from different companies as well. Even though, this issue still keeps popping up even at Google. This SSRF is a great example of it.”

278,000 GitHub Repositories Affected by a Critical Networking Flaw in Netmask

 

Security researchers have unearthed a critical networking flaw CVE-2021-28918 in a popular npm library netmask. Netmask is commonly utilized by tons of thousands of applications to analyze IPv4 addresses and CIDR blocks or compare them. 

Netmask usually gets over 3 million weekly downloads, and as of today, has scored over 238 million complete downloads over its lifetime. Apart from this, nearly 278,000 GitHub repositories depend on the netmask. Due to improper input validation flaw, netmask sees a different IP and this flaw could allow hackers to achieve server-side request forgery (SSRF) in downstream applications.

 Security researchers Victor Viale, Sick Codes, Nick Sahler, Kelly Kaoudis, and John Jackson were responsible for tracking down the vulnerability in the popular netmask library. The flaw was initially detected when security researchers including Codes were designing a patch for a separate, critical, SSRF flaw (CVE-2020-28360) in downstream package Private-IP, which helps in preventing personal IP addresses from communicating with an application’s internal resources.

According to a GitHub advisory published by Sick Codes, “the primary cause of the problem turned out to be Netmask’s incorrect evaluation of individual IPv4 octets that contain octal strings as left-stripped integers, leading to an inordinate attack surface on hundreds of thousands of projects that rely on Netmask to filter or evaluate IPv4 block ranges, both inbound and outbound.”

Security researchers initially discovered the flaw on March 16 and advised node js developers to examine their projects for use of Netmask and upgrade immediately if they identify the package in use. Sick Codes stated that the 30 billion nodejs packages downloaded last week were mostly installed by automated CI/CD pipelines and with no manual runtime inspections.

Olivier Poitrey, netmask developer and director of engineering at Netflix, released a series of patches [1,2,3] for the bug to GitHub, containing test cases validating that IPv4 octets with 0 prefixes are treated as octal and not decimal numbers. Earlier this month, the Perl component Net::Netmask also suffered from this bug.

Critical SSRF vulnerability in Paypal's subsidiary allows to access Internal Network

Shubham Shah, a web application pentester from Australia, has discovered a critical Server Side Request Forgery(SSRF) vulnerability in the Bill Me Later website, a subsidiary of Paypal. The vulnerability exists in the subdomain(merchants.billmelater.com).

"The vulnerability itself was found within a test bed for BillMeLater’s SOAP API, which allowed for queries to be made to any given host URL." researcher explained in his blog post.

An attacker is able to send request to any internal network through the API and get the response.  Some internal admin pages allowed him to query internal databases without asking any login credentials.

Researcher says that a successful exploitation may result in compromising the customers data.

The bug was reported to Paypal on October 2013 and he got reward from them on Jan. 2014.

Paypal has partially fixed the bug by restricting the SOAP API to access the internal servers.  However, researcher says that it still act as proxy to view other hosts.

If you would like to know more details about SSRF vulnerability and how it can be exploited for port scanning or internal network finding, you can refer the Riyaz Waliker blog post and this document.