Bit of a race condition leading to a lock screen bypass on Pixel devices.

The process of exploiting is to

1. Lock the phone
2. Hot-Swap SIM Card with a SIM locked with a PIN
3. Enter an incorrect SIM PIN three times, leading to the SIM being locked until the Personal Unlock Key is used (PUK)
4. Enter the PUK key
5. Set a new SIM PIN
6. Security dialogs will be dismissed and you will land on the homescreen

What happens here is made a bit more clear from the commit message. After the successful PUK unlock there are multiple dismiss() calls occur. At the same time, other parts of the system listening for SIM events recognize the PUK unlock and update which security screen should come next. If any of the dismiss() calls from the PUK controller happen after that update, they will end up dismissing the lock-screen.

Oversecured pointed their code-scanning tool at discovering issues in vendor patches to the Android System APIs and found a number of places where Samsung introduces vulnerabilities.

1. The BackupManagerService’s isBackupEnabled() method in stock Android would perform a android.permission.BACKUP check before returning. Samsung simply added a semIsBackupEnabled() method which does the same but skips the permission check.
2. The StorageManagerService added support for a broadcast action (com.samsung.intent.action.RESTART_OF_SDCARDBADREMOVED_HASAPK) that could be sent by any application and would reboot the device without any permission check.
3. Inside of Settings application as it handles intends, an application can include a boolean from_search_trampoline. Which would then startup the specified activity. As the Settings application runs as System user, they can startup non-exposed activities from any application.

A long chain of issues going from blind SSRF to new-line injection to a blind Livestatus Query Language (LQL) injection to arbitrary file deletion and finally a race condition leading to authentication bypass.

Blind Server-Side Request Forgery - The SSRF existed on the agent-receiver which is basically a thin-client, exposed on port 8000 and most endpoints just pass things along to the Checkmk REST API running on port 80. The /register_with_hostname endpoint takes a host_name parameter and uses it in crafting the path on the REST API (objects/host_config_internal/{host_name}). With no sanitization its possible to hit other endpoints on the REST API, specifically those endpoints that are unauthenticated but only for requests originating from localhost.

New Line Injection in ajax_graph_images.py - The ajax graph images endpoint is meant to generate an image showing the performance data for a particular host. It does this by crafting a LQL query. Part of this query is an AuthUser: header which is used to restrict the results to what that particular user could see. An attacker controlled this value has it comes from the force_authuser URL parameter. This value is reflected into the query without any sanitization, allowing an attacker to inject new-lines and arbitrary content.

LQL Injection - The new-line is particularly important here as much of the query is in the form of Key: value\n. Injecting a new-line allows an attacker to craft the rest of the query. Or, by injecting a KeepAlive: on\n\n the connection won’t be closed after the first empty line, and instead the attacker can inject a completely arbitrary query.

Arbitrary File Deletion - The LQL could be exploited to extract monitoring data in a way similar to a time-based boolean blind SQL injection, but another ability is to execute COMMAND requests. Despite the name, the command interface is fairly restrictive and doesn’t enable shell command injection. What it does ovver is a PROCESS_FILE command taking two parameters a filename, and a boolean indicating if the file should be deleted once processed. Processing a file doesn’t open any new attack surface, its the same commands available elsewhere, but the deletion happens even if parsing the file, or any of the commands fail. So an attacker can use this to delete any file.

NagVis Authentication Bypass - To understand the bypass first lets touch on the authentication system itself. the login.py file on the Checkmk GUI validates a session cookie. This session cookie is made up of three items: <username>:<session_id>:<hash> and the <hash> is a SHA256 hash made from four items: <username><session_id><serial><secret>. The Username and session ID are attacker controlled, the serial is an incrementing value that increments every time the password is changed or account is locked. The <secret> is read from auth.secret,

One obvious attack would be to delete auth.secret and hope to get an empty value used. However the file will be regenerated if it does not exist so that will not work. There is an alternative login route though, the NagVis integration will parse the same session cookie and does the same validation of the hash. The key difference is that if the file does not exist it will error out.

The final attack is to abuse a race window. For a short window of time, on the Checkmk GUI when regenerating the auth.secret after it was deleted it will create a new file. That new file with briefly be empty, if at that same moment the NagVis auth system attempted to read auth.secret it would get an empty value, allowing a valid session cookie to be crafted by an attacker.

An interesting look at an overlooked vulnerability, client-side path traversal. A client-side path traversal is when the path traversal attack lands on the client side rather than the more traditional attack against server-side files.

In this case, we have Acronis which allows for users to specify a color scheme to use as a url parmater. The application then reads that parameter in JavaScript and tries to fetch the theme.{color_scheme_value}.css file. In doing so, it does not sanitize the color_scheme at all, so any directory traversals will be included and resolved when the request is made allowing this request to hit other endpoints, but not other domains.

The author combines this with an open redirect issue where on the callback URL being executed it will redirect based on the state value. So if a victim is logged in with the oauth identity provider, when they access the page with the vulnerable color_scheme, it will attempt to load the CSS file, path traversal taking it to the oauth redirect, the oauth provider redirecting it back to the legitimate callback URL, and the callback redirecting to the attacker controlled location. Ultimately loading attacker controlled CSS which can be used for exfiltration.