How a fake job offer took down the world’s most popular crypto game 1
A senior engineer at Axie Infinity was duped into applying for a job at a company that, in reality, did not exist. This led to Ronin, the Ethereum-linked sidechain that underpins play-to-earn game Axie Infinity, being hacked in March.
Staff at Axie Infinity developer Sky Mavis were approached by people purporting to represent the fake company and encouraged to apply for jobs. One engineer was offered a job with an extremely generous compensation package, which he downloaded, allowing spyware to infiltrate Ronin's systems.
The hackers infiltrated Ronin's systems through a fake job ad, and managed to steal cryptoassets after obtaining the private cryptographic keys of five of the nine validators.
The hacker managed to use the Axie DAO, a group set up to support the gaming ecosystem, to complete the heist. Sky Mavis had asked the Axie DAO for help dealing with a heavy transaction load in November 2021.
Sky Mavis raised $150 million in a round led by Binance in early April and said it would begin returning funds to users on June 28.
SOC2: The Screenshots Will Continue Until Security Improves · Fly 2
It assures some things pentests don't: Consistent policies for who gets access to what, 2FA, alerts for weird things in logs, severed employees reliably have their access terminated.
We started preparing for SOC2 more than a year before engaging an auditor, and it worked out well.
Single Sign-On is one of the first things newly-minted CSOs get worked out when they take the position. We moved everything we could to our Google SSO, and use a certificate-based SSH access control system called Teleport.
There is an "SSO tax" that companies pay to get access to SAAS accounts that support SAML or OIDC. I have opinions about the SSO tax.
Protected branches make it harder to push commits directly to main, which is what our auditors worried about. We also reviewed all changes to production with another developer, and ran a Github bot that flagged unreviewed PRs automatically.
Centralized logging is a feature of our platform, and we got off easy with this one, because we run very large ElasticSearch and VictoriaMetrics clusters, fed from Vector and Telegraf, and we're generally a single ElasticSearch query away from any event happening anywhere in our infrastructure.
CloudTrail: We barely use anything in AWS other than storage, but SOC2 audit firms added a whole bunch of AWS-specific line-items to their DRLs.
Your auditor will probably know about Terraform and CloudFormation, and will want you to document how your own deployment system is similar to Terraform. You will also need to document your host inventory and your MDM and endpoint management strategy.
We had to have a formal org chart posted where employees could find it, and we had to do pro-forma annual performance reviews because the AICPA can't give assurances that an employee who exfiltrated our production database to Pastebin would be terminated.
Background checks are performative and intrusive, and for us they're illegal in some jurisdictions. We got out of it by tracking down another company our auditors had worked with, and stealing their process.
You're going to write a bunch of policies. It's up to you how seriously you're going to take this, but I recommend you read Ryan McGeehan's "Starting Up Security" site before you start writing your own policies.
We wrote an Information Security Policy, a Data Classification Policy, a Document Retention Policy, a Risk Assessment Policy, a Vulnerability Management Policy, an Access Request Policy, a Vendor Management Policy, an Incident Response Policy, a Business Continuity Plan, and an Employee Handbook.
We use Slab as our company wiki / intranet. Slab's "verifying" feature gave us the screenshots we needed for our DRL line items about "recertifying" policies annually.
We didn't run endpoint software, vulnerability scanners, collect SOC2 reports, clear any Prototype Injection vulnerability alerts, install any agent software on any server anywhere, or run antivirus on our servers.
If you talk to people who've done SOC2 before, you'll hear a lot of joking about screenshots. SOC2 audits are essentially a series of screenshots, and the evidence collection stage is divided up into a series of calls over the course of a week.
AMD, Intel chips vulnerable to 'Retbleed' Spectre variant • The Register 3
Older AMD and Intel chips are vulnerable to Retbleed, a Spectre-based speculative-execution attack that can be exploited by branch target injection. This allows an attacker to obtain secrets from kernel memory despite defenses already in place.
Retbleed exploits return instructions, which bypasses some of the current Spectre-BTI defenses, including kernel page-table isolation (KPTI), retpoline, user pointer sanitization, and disabling unprivileged eBPF.
Wikner and Razavi found that all return instructions that follow sufficiently deep call stacks can be hijacked on Intel processors, and that any return instruction can be hijacked on AMD processors.
Wikner, Razavi, and another ETH Zurich researcher discovered that AMD CPU cores perform phantom jumps, which allow speculative execution of code originating from arbitrary instruction boundaries.
The technique's severity is somewhat reduced by the fact that it applies to older silicon, but Wikner and Razavi said some of the affected chips are of fairly recent vintage.
Intel and AMD have improved their chip architectures to make speculative execution attacks more difficult.
The researchers have posted a video showing Retbleed in action, and said the fixes may hinder performance significantly.
Retbleed is a security vulnerability that has been designated CVE-2022-29900 for AMD, CVE-2022-29901 and CVE-2022-28693 for Intel, and AMD is also using CVE-2022-23825 to track Retbleed. AMD is recommending software suppliers take additional steps to help guard against Spectre-like attacks.
Intel and AMD have released microcode updates that may prevent Retbleed, and system software can also flip a control register bit to prevent Retbleed.
Corrupting memory without memory corruption | The GitHub Blog 4
A vulnerability in the Arm Mali GPU kernel driver allowed me to gain arbitrary kernel code execution and root on a Pixel 6 with ease.
The GPU driver on Android is a very attractive target for an attacker, because it can be accessed from the untrusted app domain and because most Android devices use either Qualcomm's Adreno GPU or the Arm Mali GPU.
Of the seven Android 0-days that were exploited in 2021, five targeted the GPU driver, and three targeted the Qualcomm GPU, and three targeted the Arm Mali GPU.
In this post, I exploited CVE-2022-20186 in the Mali GPU driver. This bug causes arbitrary physical memory access, without involving control flow hijacking, and does not involve the usual type of memory corruption associated with memory safety.
The bug was reported to the Android security team on January 15, 2022, and was fixed in the June update for Pixel on June 6, 2022.
The patch for this bug was publicly visible before an official release. This highlights the complexity of the branching system in the Android kernel and the potential for exploiting one day vulnerabilities via patch gapping.
“ParseThru” – Exploiting HTTP Parameter Smuggling in Golang 5
Consider the following scenario: A Golang-based service decides whether to pass through an HTTP request based on a parameter supplied by the user, and another Golang-based backend service.
If a user appends a semicolon to the name parameter, the first service ignores its existence and forwarded the request to the second service, which treats the parameter without the semicolon.
Harbor case study:
Harbor is an open source registry that secures artifacts with policies and role-based access control. It lets you manage your application artifacts and centralize multiple image registries under one roof.
Oxeye found that Bitnami's Harbor microservice runs on Golang 1.17, but its Docker registry microservice runs on Golang 1.15. With that, the Harbor authorization checks can be bypassed.
Oxeye discovered other projects, such as Traefik and Skipper, that use the same unsafe method.
Acknowledgement: The above summaries are automatically generated by Wordtune.
- Linus Torvalds says Linux kernel has addressed ‘Retbleed’ • The Register (www.theregister.com)
- Retpoline: A Branch Target Injection Mitigation (www.intel.com)
- RETBleed: Leaking root password hash from /etc/shadow - YouTube (www.youtube.com)
- Retbleed: Arbitrary Speculative Code Execution with Return Instructions - Computer Security Group (comsec.ethz.ch)
- comsec-group/retbleed: Arbitrary Speculative Code Execution with Return Instructions (github.com/comsec-group)