Опасная разработка. Изучаем уязвимости в сервисах поставки кода

Стан­дар­тный сов­ремен­ный цикл раз­работ­ки сос­тоит из мно­жес­тва эта­пов: пла­ниро­вание, ана­лиз, дизайн, раз­работ­ка, тес­тирова­ние, интегра­ция, под­дер­жка... На каж­дом эта­пе раз­работ­чики, адми­ны, DevSecOps и дру­гие спе­циалис­ты исполь­зуют раз­ные инс­тру­мен­ты. От гра­мот­ности нас­тро­ек этих инс­тру­мен­тов может зависеть безопас­ность про­дук­та. Часть из них впол­не мож­но рас­кру­тить до уяз­вимос­тей.

Я возь­му нес­коль­ко популяр­ных сер­висов, которые исполь­зуют­ся на раз­ных эта­пах, и покажу на их при­мере, как такое слу­чает­ся. Боль­шую часть перечис­ленно­го я обна­ружил в 2019 году, так что не жди, что про­делан­ное мной мож­но будет пов­торить на акту­аль­ных вер­сиях перечис­ленных прог­рамм. Боль­шинс­тво уяз­вимос­тей уже зак­рыты, но моя цель в дан­ном слу­чае — про­демонс­три­ровать, как нуж­но думать, что­бы их обна­ружи­вать.

Jira

Jira — это мощ­ный таск‑тре­кер, раз­работан­ный ком­пани­ей Atlassian. Его мож­но исполь­зовать в качес­тве баг‑тре­кера, сис­темы рас­пре­деле­ния задач меж­ду сот­рудни­ками и еще мно­го чего, но сей­час не об этом. Jira исполь­зует­ся в мил­лионах орга­низа­ций — вну­шитель­ное поле для атак! Само собой, не все адми­ны задумы­вают­ся о безопас­ности, а мно­гие вооб­ще счи­тают, что их орга­низа­ции никому не нуж­ны и ник­то их ата­ковать не будет. Это обманчи­вое ощу­щение!

На­ходок у меня мно­го, и нач­нем мы с самого прос­того, но не такого уж и безобид­ного.

Data disclosure

До­пус­тим, ты нашел сер­вис Jira по адре­су jira.company.hack. Тог­да обра­щение по урлу https://jira.company.hack/rest/api/2/[]/ вызовет выпаде­ние стек­трей­са, как на скрин­шоте ниже.

Чем оно нам может быть инте­рес­но? Как минимум тем, что мы можем пос­мотреть, какие пла­гины уста­нов­лены в Jira. А пла­гины, как ты зна­ешь, зачас­тую куда более уяз­вимы, чем само при­ложе­ние. Кста­ти, в Jira тоже час­тень­ко попада­ются раз­ной сте­пени серь­езности баги, так что из логов мож­но дос­тать вер­сию и про­верить, нет ли удоб­ной RCE.

Как и любая про­мыш­ленная сис­тема, Jira уме­ет мас­шта­биро­вать­ся. Дела­ется это за счет пла­гинов, которые пишут как офи­циаль­ные раз­работ­чики — Atlassian, так и сто­рон­ние.

Один из дос­таточ­но час­то исполь­зуемых таких ком­понен­тов — Agile Board.

Agile — это один из под­ходов к раз­работ­ке, а Jira Agile Board поз­воля­ет выс­тра­ивать даш­борды для Agile и работать с ними коман­дой или нес­коль­кими коман­дами над раз­ными про­екта­ми. Идея прос­тая: есть дос­ка, на ней есть тикеты, мы можем смот­реть, ког­да и кем они выпол­няют­ся, какие на них сро­ки, какие сприн­ты и тому подоб­ное.

Зву­чит не осо­бо инте­рес­но, но, ког­да я начал иссле­довать Jira в нашей ком­пании, заметил, что все это дос­тупно безо вся­кой авто­риза­ции. То есть пла­гин офи­циаль­ного раз­работ­чика живет сво­ей жизнью и ни с кем догова­ривать­ся не обя­зан, а в нем содер­жится чувс­тви­тель­ная информа­ция. Мы можем прос­то прой­ти по URL вида https://jira.company.hack/secure/ManageRapidViews.jspa и пос­мотреть любую дос­ку любого про­екта.

IDOR

Здесь даже наш­лась уяз­вимость типа IDOR — небезо­пас­ные ссыл­ки на объ­екты. Она поз­воля­ет зай­ти вооб­ще в любой про­ект, пос­мотреть задачи и прог­ресс их выпол­нения, и при этом не важ­но, при­ват­ный это про­ект или пуб­личный.

Са­мо собой, переби­рая параметр в URL, мож­но получить вооб­ще все дос­ки, которые заведе­ны в Jira.

Blind JQL

Еще один доволь­но инте­рес­ный баг — сле­пой JQL. Экс­плу­ати­ровать его тоже мож­но без авто­риза­ции и читать любые тикеты.

В ядре Jira, оче­вид­но, есть API. Нас инте­ресу­ют сле­дующие адре­са:

• https://jira.company.hack/jira/rest/api/2/mypermissions
• https://jira.company.hack/jira/rest/api/2/issue/1
• https://jira.company.hack/jira/rest/api/2/search?jql=status%3Dopen and description="12345"

Как ты заметил, на эндпой­нте поис­ка в парамет­ре jql переда­ется зап­рос, но инте­рес­но не это, а то, что на сущес­тву­ющие и несущес­тву­ющие зап­росы выда­ются раз­ные отве­ты. Таким обра­зом мож­но пол­ностью вос­ста­нав­ливать содер­жимое тикетов, исполь­зуя те же спо­собы, что и при сле­пых SQL-инъ­екци­ях.

Для успешно­го поис­ка сто­ит подоб­рать поле id в тек­сте зап­роса. Это целое чис­ло, которое обоз­нача­ет номер тикета в Jira. Теперь мы можем пол­ностью вос­ста­нав­ливать содер­жимое тикета брут­форсом поля description.

Од­на из проб­лем с ID зак­люча­ется в том, что идут они не по поряд­ку. Для под­бора ID мож­но исполь­зовать такой вот прос­той скрипт:

На скри­не ты видишь, что тикеты 10000 и 10001 сущес­тву­ют, но к ним нет дос­тупа, а 10002 не сущес­тву­ет, зна­чит, работать с помощью blind JQL мы можем толь­ко на 10000-м и на 10001-м тикете.

В некото­рых слу­чаях это может не сра­ботать. У Atlassian есть два режима раз­дачи дос­тупов: пер­сональ­ный и груп­повой. Груп­повой при­меня­ется сра­зу к целой груп­пе раз­работ­чиков, а пер­сональ­ный — к одно­му кон­крет­ному. Так вот, ата­ку нель­зя вос­про­извести при уста­нов­ленном пер­сональ­ном режиме дос­тупа.

Confluence

Confluence — это прос­транс­тво для коман­дной работы, осо­бен­но удоб­ное при уда­лен­ке. Здесь мож­но сов­мес­тно накап­ливать зна­ния.

Глав­ное для нас — то, что здесь при­мер­но та же исто­рия, что с Jira: пер­вые две проб­лемы (stack trace и управля­ющие пор­ты) оди­нако­вые, а об еще одной я сей­час рас­ска­жу.