Misconfigured S3 Bucket Access Controls to Critical Vulnerability

Amazon S3 (Simple Storage Service) is one of the popular and widely used storage services. Many companies are using S3 buckets to store their assets such as user profile pictures, static resources, and anything as per their business logic and needs. However, if the buckets are not configured properly, or are unclaimed, an attacker can probably perform some mischievous actions such as S3 Bucket Takeover or S3 Content Takeover.

Hi Fellow Hackers & Enthusiasts, In this article, I will be talking about one of the recent encounters where a misconfigured S3 Bucket allowed me to perform any of the CRUD operations resulting in a critical vulnerability.

You can read more about Amazon S3 here.


The application I was testing had a huge scope. The finding is related to one of the subsidiaries of the program. Let’s call the subsidiary “subtarget.com”.

I started with subdomain enumeration and resolving unique subdomains with the following command:

subfinder -d subtarget.com -silent | httpx -follow-redirects -status-code -vhost -threads 300 -silent | sort -u | grep “[200]” | cut -d [ -f1 > resolved.txt

From there, I found a subdomain named: “https://qa-assets-us.subtarget.com” while navigating to this, I observed that the **Bucket is Open and I am presented with the “**ListBucketResult”

Now, the bucket is being used for static resources so there is no point to report this because sometimes the buckets are open intentionally (at least that’s what they say).

Next step was to look at the following entry which provided the name of S3 Bucket:

some-name-here

Now, the next process is to test for the access controls of the S3 Bucket. Usually, the bucket shall not provide an unauthorized user following permissions:

  • Create something on the bucket
  • Modify something on the bucket
  • Delete something on the bucket
  • Read some sensitive data on the bucket (case-by-case basis)

#infosec #bug-bounty #hacking #security #appsec

What is GEEK

Buddha Community

Misconfigured S3 Bucket Access Controls to Critical Vulnerability
Wilford  Pagac

Wilford Pagac

1596834000

Critical Bugs in Utilities VPNs Could Cause Physical Damage

Gear from Secomea, Moxa and HMS Networks are affected by remote code-execution flaws, researchers warn.

Remote code-execution vulnerabilities in virtual private network (VPN) products could impact the physical functioning of critical infrastructure in the oil and gas, water and electric utilities space, according to researchers.

Researchers at Claroty found that VPNs used to provide remote access to operational technology (OT) networks in industrial systems are vulnerable to an array of security bugs, which could give an attacker direct access to field devices and cause physical damage or shut-downs.

The security vulnerabilities affect three vendors specifically, Secomea, Moxa and HMS Networks, and any of their white-label partners.

“These dedicated remote-access solutions are mainly focused on the industrial control system (ICS) industry, and their main use case is to provide maintenance and monitoring to field controllers and devices including programmable logic controllers (PLCs) and input/output (IO) devices,” analysts said in a posting issued on Wednesday. “Apart from connectivity between sites these solutions are also used to enable remote operators and third-party vendors to dial into customer sites and provide maintenance and monitoring for PLCs and other Level 1/0 devices. This kind of access has become especially prioritized in recent months due to the new reality of COVID-19.”

The Flaws

A critical bug in Secomea GateManager (CVE-2020-14500) occurs due to improper handling of HTTP request headers provided by the client. This could allow an attacker to remotely exploit GateManager to achieve remote code execution without any authentication required.

“If carried out successfully, such an attack could result in a complete security breach that grants full access to a customer’s internal network, along with the ability to decrypt all traffic that passes through the VPN,” according to Claroty.

GateManager is an ICS component located at the perimeter of a customer network, which accepts connections from remote sites/clients. It’s deployed worldwide as a cloud-based software-as-a-service solution, both in branded and white-label instances; these cloud servers are multi-tenant but can also be installed and configured as on-premise solutions.

According to Secomea’s website, the GateManager cloud server is designed to “deliver the convenience of fast and easy web access, while avoiding server setups.” However, the cloud-based nature of the product could mean a wider attack surface for cybercriminals looking to exploit this bug, researchers said.

“In recent years we have seen a shift toward cloud-based remote access solutions, which typically enable rapid deployment and reduce cost,” according to Claroty’s post. “Usually, they also offer white-labeled solutions that large-scale companies can purchase to have their own personal cloud while the underlying software is exactly the same. Thus, finding bugs in one instance could mean that all other instances would be affected, too.”

In addition to the critical bug, other flaws found in GateManager include CVE-2020-14508, an off-by-one error, which may allow an attacker to remotely execute arbitrary code or cause a denial-of-service condition. Another (CVE-2020-14510) arises from the use of a hard-coded credential for telnet, allowing an unprivileged attacker to execute commands as root. And CVE-2020-14512 is due to a weak hash type, which may allow an attacker to view user passwords.

Secomea issued patches on July 16 (in GateManager versions 9.2c / 9.2i).

Meanwhile, a stack-based overflow vulnerability, is present in the Moxa EDR-G902/3 industrial VPN server (CVE-2020-14511). This product is meant to provide a secure connection between remote industrial sites and a main data center where the SCADA/data collection server is located.

“Exploiting this security flaw, an attacker could use a specially crafted HTTP request to trigger a stack-based overflow in the system web server and carry out remote code execution without the need for any credentials,” according to the writeup. “An attacker can provide a large cookie and trigger a stack-based overflow in the system.”

Moxa made a patch available on June 9; users should update EDR-G902/3 to version v5.5 by applying the respective firmware updates available for the EDR-G902 series and EDR-G903 series, the vendor said.

And finally, a critical stack-buffer overflow (CVE-2020-14498) is present in the eWon product by HMS Networks.

eWon is a VPN device that allows machine builders and factory owners to remotely monitor the performance of their equipment. Remote clients can connect to it using a proprietary VPN client on their computer, named eCatcher, which is where the vulnerability lies.

“The bug can be exploited to achieve remote code execution [on a target’s computer] by [convincing a user to visit] a malicious website or [open] a malicious email which contains a specifically crafted HTML element which is able to trigger the vulnerability in eCatcher,” explained Claroty researchers.

Gaining control of an authorized user’s computer grants attackers access to that user’s VPN credentials, which they can then use to expand their foothold within an organization’s internal network.

In a proof-of-concept exploit, researchers showed that sending socially engineered emails embedded with specifically crafted images could trigger the vulnerability if the user simply opened and viewed the email. An attacker would then have the highest privileges and be able to completely take over a victim’s machine.

“The exploitation phase occurs immediately when the email client (e.g. Outlook) is loading the malicious images,” according to the post.

HMS Networks issued a patch on July 14 in eCatcher version 6.5.5.

ICS in the Crosshairs

Industrial installations have been ramping up in terms of adversary interest of late. Last week, the U.S. National Security Agency (NSA) and the Cybersecurity and Infrastructure Security Agency (CISA) issued an alert warning that cybercriminals could be targeting critical infrastructure across the U.S.

And separately, ICS-CERT issued an advisory on a critical security bug in the Schneider Electric Triconex TriStation and Tricon Communication Module. These safety instrumented system (SIS) controllers are responsible for shutting down plant operations in the event of a problem and act as an automated safety defense for industrial facilities, designed to prevent equipment failure and catastrophic incidents such as explosions or fire. They’ve been targeted in the past, in the TRITON attack of 2017.

“We expect that in the COVID-19 reality of working from home, the increased use of [VPN] platforms will drive increased interest both from the operational side, as they become more process-critical, and from the security side, as they become more common,” according to Claroty. The researchers added, “Denial-of-service attacks on these components of the enterprise infrastructure could potentially emerge as a new tactic used by financially motivated attackers.”

Complimentary Threatpost Webinar: Want to learn more about Confidential Computing and how it can supercharge your cloud security? This webinar “Cloud Security Audit: A Confidential Computing Roundtable_” brings top cloud-security experts together to explore how Confidential Computing is a game changer for securing dynamic cloud data and preventing IP exposure. Join us Wednesday Aug. 12 at 2pm ETfor this** FREE _**live

#cloud security #critical infrastructure #vulnerabilities #web security #bugs #claroty #coronavirus #covid-19 #critical #denial of service #hms networks #ics #industrial control systems #infrastructure #moxa #operational technology #ot #physical damage #remote access #remote code execution #secomea #security flaws #triton #utilities #vpns #vulnerability #work from home

Hollie  Ratke

Hollie Ratke

1597683600

NSA Urgently Warns on Industrial Cyberattacks, Triconex Critical Bug

The U.S. National Security Agency (NSA) and the Cybersecurity and Infrastructure Security Agency (CISA) have issued an alert warning that adversaries could be targeting critical infrastructure across the U.S.

Separately, ICS-CERT issued an advisory on a critical security bug in the Schneider Electric Triconex TriStation and Tricon Communication Module. These safety instrumented system (SIS) controllers are responsible for shutting down plant operations in the event of a problem and act as an automated safety defense for industrial facilities, designed to prevent equipment failure and catastrophic incidents such as explosions or fire. They’ve been targeted in the past, in the TRITON attack of 2017.

“Over recent months, cyber-actors have demonstrated their continued willingness to conduct malicious cyber-activity against critical infrastructure (CI) by exploiting internet-accessible operational technology (OT) assets,” said the NSA/CISA joint advisory, released on Thursday. “Due to the increase in adversary capabilities and activity, the criticality to U.S. national security and way of life and the vulnerability of OT systems, civilian infrastructure makes attractive targets for foreign powers attempting to do harm to U.S. interests or retaliate for perceived U.S. aggression.”

Vulnerable OT Systems

The advisory goes on to point out that OT systems often consist of legacy equipment that was never designed to be connected to the internet nor defend against malicious cyberactivities. At the same time, more and more utilities, petrochemical installations, factories and so on are looking to increase remote operations. This means conducting various activities over the web using an IT network to connect to the OT side, enabling monitoring, instrumentation and control, OT asset management/maintenance, and in some cases, process operations and maintenance.

Generally, adversaries are using spearphishing efforts to obtain initial access to the organization’s IT network, before pivoting to the OT network, the advisory added.

“Combined with readily available information that identifies OT assets connected via the internet (e.g., Shodan, Kamerka), are creating a ‘perfect storm’ of easy access to unsecured assets, use of common, open-source information about devices, and an extensive list of exploits deployable via common exploit frameworks,” the agencies warned.

The NSA/CISA advisory also detailed that in the wild, several cyberattack attempts have been observed. These include attempts to: Deploy of commodity ransomware on both IT and OT networks; communicate with controllers and downloading modified control logic; use vendor engineering software and program downloads; and modify control logic and parameters on programmable logic controllers (PLCs). PLCs are responsible for directly reading and manipulating physical processes in industrial environments.

If successful, these efforts could result in an OT network going down, a partial loss of view for human operators, lost productivity and revenue, or, in the worst-case scenario, adversary control and disruption to physical processes.

“Cyber campaigns are an ideal way for nation-states to apply pressure on the global stage, because they offer the advantage of plausible deniability plus the rules of engagement are undefined,” Phil Neray, vice president of industrial cybersecurity at CyberX, said via email. “This NSA/CISA advisory is particularly interesting because it appears to be tied to ongoing campaigns targeting industrial control systems, and it explicitly mentions the need for organizations to protect against sophisticated living-off-the-land tactics such as modifying the control logic in process controllers, which is exactly what we saw in the TRITON attack.”

Two partial-loss-of-view incidents have been recorded in the U.S. before: One was a ransomware attack on a pipeline in February that knocked it offline for two days; and the other was an attack on a wind-and-solar power plant last November. Loss of view means that the organization loses the ability to monitor the current status of its physical systems.

Neray said in an interview with Threatpost at the time that “if an attacker wanted to shut down parts of the grid, one of their first steps might be precisely this loss-of-view step, because it would leave utility operators ‘blind’ to subsequent disruptive actions the attackers would take, such as switching relays off to halt the flow of electricity.”

#critical infrastructure #government #hacks #vulnerabilities #advisory #alert #cisa #critical security vulnerability #cve-2020-7491 #cyberattacks #factories #foreign adversaries #ics-cert #industrial control systems #nsa #oil and gas refineries #power plants #schneider #triconex #warning

Misconfigured S3 Bucket Access Controls to Critical Vulnerability

Amazon S3 (Simple Storage Service) is one of the popular and widely used storage services. Many companies are using S3 buckets to store their assets such as user profile pictures, static resources, and anything as per their business logic and needs. However, if the buckets are not configured properly, or are unclaimed, an attacker can probably perform some mischievous actions such as S3 Bucket Takeover or S3 Content Takeover.

Hi Fellow Hackers & Enthusiasts, In this article, I will be talking about one of the recent encounters where a misconfigured S3 Bucket allowed me to perform any of the CRUD operations resulting in a critical vulnerability.

You can read more about Amazon S3 here.


The application I was testing had a huge scope. The finding is related to one of the subsidiaries of the program. Let’s call the subsidiary “subtarget.com”.

I started with subdomain enumeration and resolving unique subdomains with the following command:

subfinder -d subtarget.com -silent | httpx -follow-redirects -status-code -vhost -threads 300 -silent | sort -u | grep “[200]” | cut -d [ -f1 > resolved.txt

From there, I found a subdomain named: “https://qa-assets-us.subtarget.com” while navigating to this, I observed that the **Bucket is Open and I am presented with the “**ListBucketResult”

Now, the bucket is being used for static resources so there is no point to report this because sometimes the buckets are open intentionally (at least that’s what they say).

Next step was to look at the following entry which provided the name of S3 Bucket:

some-name-here

Now, the next process is to test for the access controls of the S3 Bucket. Usually, the bucket shall not provide an unauthorized user following permissions:

  • Create something on the bucket
  • Modify something on the bucket
  • Delete something on the bucket
  • Read some sensitive data on the bucket (case-by-case basis)

#infosec #bug-bounty #hacking #security #appsec

Edison  Stark

Edison Stark

1598982960

Access Control in Nebula Graph: Design, Code, and Operations

Access Control List (ACL) is not alien to database users and it is a significant part of data security. Like other database vendors, Nebula Graph takes data security seriously and now supports role-based access control.

In this article, we will detail user management with roles and privileges of Nebula Graph.

The Authentication Workflow

Nebula Graph is composed of three parts: the query engine, the storage layer and the meta service. The console, API and the web service are collectively referred to as Client API. See the figure below:

The account and role data will be stored in the meta engine. When query engine is started, the meta client through which the query engine communicates with the meta service will be initialized.

When users connect to query engine through the client API, the query engine will check the user information on the meta engine via the meta client, determining the existence of the requesting account and the correctness of the password. Once the verification is passed, the connection succeeds. Users can then perform data operations in this session.

Once a query is received, the query engine will parse it, which involves identifying the command type and verifying user’s authority based on the operation and the user’s role. If the authority is invalid, the command will be blocked in the query engine and an error is returned to the client API. In the entire permission check process, Nebula Graph caches the meta data. We will detail this in the next chapter.

The Access Control Logic

In general, access control is realized through roles and privileges granted to each role. However, in Nebula Graph, permissions are also granted at graph space level.

Nebula Graph supports creating multiple graph spaces in the database. The schema and graph data are managed in each space independently and the spaces are psychically isolated from each other. In addition, Nebula Graph also provides a set of advanced commands for managing the cluster globally.

Therefore, the ACL of Nebula Graph will be managed in three dimensions: graph spacesroles and operations.

Role Types

Nebula Graph provides five built-in roles: GOD, ADMIN, DBA, USER and GUEST. These roles have covered all the scenarios in data security. An account can have different roles in different spaces. But it can only have one role in the same space.

Descriptions for the roles:

  • GOD
  • The initial root user similar to the Root in Linux.
  • Has the highest management access to the cluster.
  • When a cluster is initialized, a GOD account named root is created by default.
  • ADMIN
  • Advanced administration at the graph space level.
  • Full management access to a specific graph space.
  • No management access to the cluster.
  • DBA
  • Database administration.
  • Access to its authorized graph space. For example, alter or query the schema and data.
  • Not able to assign roles to users compared to ADMIN.
  • USER
  • Read/write access to the graph data limited to its authorized space.
  • Read-only access to the schema limited to its authorized space.
  • GUEST
  • Read-only access to both the schema and graph data limited to its authorized space.

#database #graph database #access control #nebula graph #access control logic

Delbert  Ferry

Delbert Ferry

1623925190

GraphQL Access Control

A GraphQL schema defines types. Each type — except for scalar types like Int, Float or String — has fields which define the relationship between this type and other types (one to one, or one to many). If you think about your schema in terms of a graph, types are the nodes of your graph, and fields are edges. Scalar types have no fields, so they form the leaf nodes of your graph. A GraphQL query is just an instruction for traversing the graph in a specific way, resulting in a tree.

When traversing a tree, you would start at the root, but a graph has no root so there is no logical starting point! That’s why every GraphQL schema needs to have a root query type: it’s the entry point into the graph. The fields of the root query type are links to the actual queries that your GraphQL server supports. This may sound confusing at first, but don’t worry about it, you can start using GraphQL just fine without understanding this detail.

#graphql #control #access control