[](#Unauthenticated-SSRF-with-regex-bypass "Unauthenticated-SSRF-with-regex-bypass")Unauthenticated SSRF with regex bypass
--------------------------------------------------------------------------------------------------------------------------

Source file: inc/functions.php

### [](#Description "Description")Description

The url to fetch is parsed and then checked with `my_validate_url`


Inside `my_validate_url`, url is checked with

'_^(?:(?:https?|ftp)://)(?:\S+(?::\S*)?@)?(?:(?!(?:10|127)(?:\.\d{1,3}){3})(?!(?:169\.254|192\.168)(?:\.\d{1,3}){2})(?!172\.(?:1[6-9]|2\d|3[0-1])(?:\.\d{1,3}){2})(?:[1-9]\d?|1\d\d|2[01]\d|22[0-3])(?:\.(?:1?\d{1,2}|2[0-4]\d|25[0-5])){2}(?:\.(?:[1-9]\d?|1\d\d|2[0-4]\d|25[0-4]))|(?:(?:[a-z\x{00a1}-\x{ffff}0-9]-*)*[a-z\x{00a1}-\x{ffff}0-9]+)(?:\.(?:[a-z\x{00a1}-\x{ffff}0-9]-*)*[a-z\x{00a1}-\x{ffff}0-9]+)*(?:\.(?:[a-z\x{00a1}-\x{ffff}]{2,}))\.?)(?::\d{2,5})?(?:[/?#]\S*)?$_iuS';


No internal IP/Hostname is permitted, but could be bypassed with the `@` character


As a result, attacker could send a request to external IP/Hostname. The second check is `get_ip_by_hostname`, the hostname is resolved to an IP and then checked with the `disallowed_remote_addresses` config


There are 2 problems here:

* 0.0.0.0, 127.0.0.2 could be used when listen on all interface
* the hostname is resolved once and checked, and then the original hostname is then resolved the second time for a request made by `libcurl`, which will lead to a `DNS rebinding bypass`

The vulnerability could be exploited via a avatar upload from URL, low privilege is required. The only limit is that the port is restricted to \[80, 443, 8080\], still, lot’s of webservice run in these port, internal endpoints could be invoked via a single GET request.

Payload: `http://127.0.0.2:443/?@aaa.com`



In case server us libcurl < 7.54, a full SSRF with unrestricted port range could be used using a bypass presented by Orange Tsai


[](#Code-injection-lead-to-leaking-database-password "Code-injection-lead-to-leaking-database-password")Code injection lead to leaking database password
--------------------------------------------------------------------------------------------------------------------------------------------------------

Source file: admin/inc/functions.php

The regex wasn’t strict enough to prevent the password database from being leaked by an authorized user




payload: `{$mybb->config['database']['password']}`

[](#errorloglocation-settings-to-write-to-arbitrary-file "errorloglocation-settings-to-write-to-arbitrary-file")`errorloglocation` settings to write to arbitrary file
----------------------------------------------------------------------------------------------------------------------------------------------------------------------

Source file: inc/class\_error.php

Due to the `str_replace` on line 371, i can’t find a way to escalate this to an RCE, but being able to write to arbitrary file is dangerous enough, the path to the error log should be set via a manual file edit by a user that has file access to the server only. By setting `errorloglocation` to `index.php` an attacker could just break the website.

[](#backup-file-delete-to-htaccess-deletion "backup-file-delete-to-htaccess-deletion")backup file delete to .htaccess deletion
------------------------------------------------------------------------------------------------------------------------------

Source file: admin/modules/tools/backupdb.php

In case of an deletion, the `file` parameter go through a `basename` call and thus prevent path traversal


But there is a `.htaccess` file in the backup directory


In case of enabling directory listing in apache2, all backups could be listed because there is no `.htaccess` to protect it anymore

To exploit this simply place `.htaccess` in the `file` parameter


`.htaccess` is now gone