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:
#burp_suite #account_bypass #elabFTW #CVE-2022-31007
About Version 2 Digital
Version 2 Digital is one of the most dynamic IT companies in Asia. The company distributes a wide range of IT products across various areas including cyber security, cloud, data protection, end points, infrastructures, system monitoring, storage, networking, business productivity and communication products.
Through an extensive network of channels, point of sales, resellers, and partnership companies, Version 2 offers quality products and services which are highly acclaimed in the market. Its customers cover a wide spectrum which include Global 1000 enterprises, regional listed companies, different vertical industries, public utilities, Government, a vast number of successful SMEs, and consumers in various Asian cities.
About VRX
VRX is a consolidated vulnerability management platform that protects assets in real time. Its rich, integrated features efficiently pinpoint and remediate the largest risks to your cyber infrastructure. Resolve the most pressing threats with efficient automation features and precise contextual analysis.
