This page is still under construction.

In the meantime, you can still peruse what is currently available while additional content is slowly populated here.

Humble beginnings

Courtesy of homelabhero.com

What can you do with what you have

Broccoli-top and Blinky Lights

vSphere is not cheap

Time to retire the bookshelf

And that's when I started tripping circuit breakers

So I got a battery

And moved

Twice

And I learned a lot about sustainable power delivery

But there was still one thing left to do


Apple ID Account Takeover

apple While I was working as the lead on-site technician for Safebit Solutions, I discovered a way to perform a full account takeover on an Apple device running the latest version of iOS, then change the Apple ID password without entering it first, and access the contents of the secure enclave using only the means provided by the default configuration of iOS.

Context

Considering a clean desk policy, if you were to swipe an iPhone from a desk, and the victim had no passcode set on a device running iOS 12.4.1 (the latest version when this bug was discovered) and that same device was signed into an Apple ID as a trusted device, you could go into the Settings area of the iPhone and attempt to set a passcode. Doing so would elicit the "Enter Apple ID password" prompt, where a race condition lives that you can bypass with the single click of a button.

Exploitation

  1. We begin with a swiped iPhone.
  2. If no passcode is set, you theoretically cannot set one without the Apple ID password, which you will not know.
  3. Enter the "set passcode" area and attempt to set a new passcode.
  4. When you click "OK" you will encounter the "Enter Apple ID password" prompt.
  5. Click the physical lock button on the side of the device. You have just exploited a race condition.
  6. When unlocking the phone, it will now ask you for the passcode you just set.
  7. Navigate to the App Store and attempt to access the Purchase History.
  8. Fail to enter the Apple ID password until it asks you to reset the password using the device passcode.
  9. Set a new Apple ID password using the new passcode you just set.
  10. Enjoy full access to the Apple ID, including Secure Enclave, stored payment methods and passwords.

Impact

According to Apple Product Security, this bug was dismissed as "intended functionality" because according to them, iOS forces you to set a passcode during setup. However, upon testing against this claim, it was found that you can choose to "skip" passcode creation during the intial setup phase of an iPhone. Although the scope is very limited, upon latent testing, this race condition still exists today in iOS 26.

In the POC video submitted to Apple, the only device tied to the Apple ID is the one being used to perform the exploit. This device is then removed, and the Apple ID password is changed. At this point, the device should not be able to make any changes to the Apple ID until it has been re-added to the account with the new password. However, by exploiting a race condition in the iOS software, we are able to force a new passcode onto the iOS device! Even though the device has been removed from the Apple ID and the password has been changed, the exploit chain still functions if performed correctly.

The passcode does a lot for an iOS device— it is actually part of the cryptosystem. Here, I have used a race condition to take over the exact moment the iPhone creates its cryptographic keys, and bypassed the Apple ID password check, eg, time of check vs time of use. When the passcode is set, the device can be used to force a new password onto the Apple ID. This worked with untrusted devices, devices with MFA, and devices with MDM. This would be a lot harder if a passcode was set beforehand (but not impossible).

Triaged
Yes — October 2019 (Abraham) and again in July 2021 (Brent) @ Apple Product Security
Patched
No
Recognized
No
Compensated
No

Apple Private Relay AirBnB Bounty

apple While I was testing Apple's new "Private Relay" feature, I discovered an SSO bug that grants Apple company affiliation to your AirBnB account, allowing visibility into restricted areas of the platform meant only for employees.

Context

When signing into a service, Apple developed a product they call Private Relay that assigns a proxy address to your account, allowing you to sign up for things using the proxy address instead of your actual email address, and gives you the option to delete the proxy address at a later date without affecting your original email address.

Exploitation

  1. We begin with a "Sign In with Apple" button on the target service.
  2. Opt in to use Apple Private Relay to sign in.
  3. Go through the motions and wait for your "Welcome to [service_name]" email.
  4. Pay attention to the string at the end of your proxy alias. This will be useful later.
  5. Sign in to the service again, but truncate the trailing string at the end of your proxy address.
  6. The email still works, only now you are recognized as an Apple employee.
  7. Wait for the "Your company is on [service_name]!" email.
  8. Follow the links in the email to view restricted areas meant for Apple employees.
  9. Iterate the characters in the trailing string on your Private Relay address to access other people's accounts.
  10. Enjoy full account takeovers to anything behind any Private Relay with a matching string connected to the servce.

Impact

According to AirBnB, this bug was dismissed as "not a security vulnerability" because my initial disclosure only included the part about truncating the string and did not include the part about iterating the characters in the trailing string to access other people's accounts.

On May 15th 2020, I chose to close my own report on the HackerOne platform per the advice of AirBnB staff and to keep a positive signal. Due to another researcher disclosing a different report citing the last two points of my initial foothold regarding iteration of strings and account takeover, when they were awarded a $100,000 bounty from AirBnB, the staff re-opened my case, triaged the bug and awarded me the maximum payout of $1,500 after I successfully demonstrated the problem and then exploited it again after they attempted to patch it.

The trailing string on a Private Relay address was not necessarily random, and because proper security measures were not in place, you could simply change the characters until you landed on someone else's account. The researcher that discovered the iteration points above also discovered a means to exploit additional crticial bugs in the Apple ecosystem, warranting the huge payout. Because my disclosure was the first demonstration of the foothold that led to more critical problems, I was awarded the Trailblazer badge on the HackerOne platform.

Triaged
Yes — May 21, 2020 (Maxb, still, and glassofbeer) @ AirBnB via HackerOne
Patched
Yes — May 22, 2020
Recognized
Yes — Thanks received by AirBnB, +32 reputation points on HackerOne
Compensated
Yes — $1,500 awarded on May 26, 2020.

Placeholder

example-image Placeholder text here.

Context

Placeholder text here.

Exploitation

  1. Step one.
  2. Step two.
  3. Step three.

Impact

Results of disclosure.

Scope, constraints, and outliers.

Final thoughts.

Triaged
Yes — Date month year (Rep name) @ Department or bounty platform
Patched
Yes — Date, software version
Recognized
Yes — Date, public link or in private
Compensated
Yes — Date, amount