История одного пентеста. Используем особенности STUN для проникновения во внутреннюю сеть

Все опи­сан­ное мы про­дела­ли в рам­ках пен­теста круп­ной ИТ‑ком­пании. Нашей целью было оце­нить воз­можность про­ник­новения во внут­реннюю сеть из внеш­ней и дать рекомен­дации, как устра­нить уяз­вимос­ти.

Разведка

Пер­вым делом, как обыч­но, ска­ниру­ем откры­тые сер­висы. Сама цепоч­ка экс­плу­ата­ции началась с веб‑при­ложе­ния IvaConnect — плат­формы для видео‑кон­ференц‑свя­зи.

Сер­вис поз­воля­ет под­клю­чить­ся к мероп­риятию по циф­ровому иден­тифика­тору. Путем перебо­ра ID мероп­риятия мы получи­ли дос­туп к тес­товой ком­нате 3333. Пос­ле это­го при­ложе­ние получа­ет учет­ные дан­ные STUN (логин — ivcs, пароль — ivcs) и под­клю­чает­ся к сер­веру STUN.

Про­токол STUN поз­воля­ет уста­нав­ливать соеди­нение меж­ду дву­мя узла­ми, находя­щими­ся за NAT, и активно исполь­зует­ся при уста­нов­лении соеди­нений в WebRTC. На этом эта­пе так­же мож­но получить внут­реннюю адре­сацию через прос­лушива­ние STUN-тра­фика в Wireshark.

В нашем слу­чае сер­вер не про­веря­ет, что адрес, по которо­му нуж­но под­клю­чить­ся, находит­ся в локаль­ной сети. Таким обра­зом зло­умыш­ленник может получить дос­туп ко внут­ренним ресур­сам, нап­ример исполь­зуя ути­литу Stunner.

Ес­ли ты обна­ружил неп­равиль­но скон­фигури­рован­ный STUN-сер­вер, Stunner поможет пос­тро­ить SOCKS-прок­си, который перенап­равля­ет весь тра­фик через про­токол TURN во внут­реннюю сеть.

Для это­го нуж­но прос­то выпол­нить коман­ду

Та­ким обра­зом уда­ется получить дос­туп к внут­ренней сети 10.1.1.0/24.

Первоначальный доступ

Во вре­мя ана­лиза внут­ренней сети мы обна­ружи­ли сер­вер PostgreSQL, исполь­зующий такие же учет­ные дан­ные, как и сер­вер STUN. Внут­ри базы мы наш­ли таб­лицу videoconference.lpad, в которой была запись для под­клю­чения к сер­веру LDAP.

Вос­поль­зовав­шись новыми зна­ниями, мы под­клю­чились к LDAP, где нас ждал еще один пароль (при­чем в откры­том виде) в поле description.

Учет­ная запись из LDAP ока­залась дей­стви­тель­ной, и мы получи­ли адми­нис­тра­тив­ный дос­туп к сер­веру А. Кро­ме того, по адре­су vcenter.company.local най­ден сер­вер vCenter, содер­жащий уяз­вимость Log4Shell. Она‑то и даст нам воз­можность выпол­нять код на сер­вере.

Для экс­плу­ата­ции необ­ходимо, что­бы целевой сер­вер не имел дос­тупа к интерне­ту и под­клю­чал­ся к внеш­нему LDAP. Поэто­му для экс­плу­ата­ции исполь­зуем получен­ный ранее сер­вер А.

Закрепление в системе

В фай­ловой сис­теме сер­вера vCenter мож­но най­ти файл data.mdb, он содер­жит в себе сер­тифика­ты, которые исполь­зуют­ся для под­писи зап­росов при SAML-аутен­тифика­ции любого поль­зовате­ля, вклю­чая адми­нис­тра­тора.

Для генера­ции сес­сии через SAML-аутен­тифика­цию мож­но вос­поль­зовать­ся ути­литой vcenter_saml_login:

С получен­ной сес­сией нам уда­лось про­ник­нуть на vCenter и зах­ватить кон­троль над вир­туаль­ной инфраструк­турой.

Внут­ри vCenter мы наш­ли вир­туаль­ную машину express c прой­ден­ной аутен­тифика­цией и дос­тупом в интернет.

Те­перь мож­но отка­зать­ся от STUN-тун­неля и вос­поль­зовать­ся нап­рямую этой вир­туаль­ной машиной для дос­тупа ко внут­ренним ресур­сам.