Пен­тест, то есть про­вер­ка инфраструк­туры ком­пании на воз­можность хакер­ско­го про­ник­новения, — это рас­простра­нен­ная услу­га, которую пре­дос­тавля­ют ИБ‑ком­пании. Одна­ко пен­тесты быва­ют очень раз­ными. В этой статье я рас­ска­жу, как, на мой взгляд, дол­жны и как не дол­жны выг­лядеть резуль­таты таких работ. Думаю, мои советы при­годят­ся и заказ­чикам, и исполни­телям. На мысль написать такой текст меня навел ком­мента­рий заказ­чика, оставлен­ный пос­ле завер­шения про­екта. Он демонс­три­рует, какие, казалось бы, обыч­ные вещи могут впе­чат­лить и порадо­вать. У нас была уяз­вимая биб­лиоте­ка с высоким CVSS, и при этом она лег­ко экс­плу­ати­рова­лась. PoC не было, но сос­тавить его не проб­лема — кол­леги из Китая оста­вили очень хорошие опи­сания к CVE, за недель­ку мож­но заиметь боевой обра­зец. Но мы зна­ли, что бла­года­ря нашим уси­лиям эта уяз­вимость была неп­римени­ма. Мы жда­ли отчет с кри­чащи­ми тегами CRITICAL. Но уви­дели эту биб­лиоте­ку с мар­кером LOW. Исполни­тели прек­расно понима­ли, как мы защити­лись, сами же опи­сали при­чину, по которой эта уяз­вимость не может быть про­экс­плу­ати­рова­на, и кор­рек­тно отме­тили, что биб­лиоте­ка уяз­вима и ее нуж­но обно­вить, ког­да появит­ся патч. Пос­ле такого понима­ешь: Твое вре­мен­ное решение проб­лемы ком­петен­тно, раз сто­рон­няя коман­да приш­ла к тому же выводу. Ис­полни­тель не прос­то исполь­зовал какие‑то ана­лиза­торы, но осмыслил про­исхо­дящее, про­ана­лизи­ровал потоки дан­ных, сопос­тавил логику уяз­вимос­ти и биз­нес‑про­цес­сы. Получив такое, веришь, что он был нас­толь­ко же дотошен и в дру­гих парамет­рах оцен­ки. Программа минимум Итак, что же нуж­но делать, что­бы заказ­чики были счас­тли­вы и писали при­ятные отзы­вы? Са­мый важ­ный аспект — вни­кать в логику работы. Не прос­то ска­ниро­вать инфраструк­туру, валиди­ровать баги руками, что‑то тыкать и фаз­зить, но еще и понять, как работа­ет сер­вис, пос­мотреть потоки дан­ных и вза­имо­дей­ствие с осталь­ными мик­росер­висами и интегра­циями. Пок­рывать все сер­висы авто­мати­зиро­ван­ными средс­тва­ми. Ва­лиди­ровать все уяз­вимос­ти. Не прос­то отда­вать репор­ты ска­нера, обер­нутые в логоти­пы тво­ей ком­пании, а обя­затель­но про­верять, что каж­дая най­ден­ная уяз­вимость реаль­на. Кор­ректи­ровать уро­вень опас­ности уяз­вимос­тей сог­ласно кри­тич­ности сер­виса и воз­можнос­ти экс­плу­ата­ции. Даже если ска­неры пишут, что уяз­вимость кри­тич­на, нуж­но учи­тывать обсто­ятель­ства: мож­но ли ее про­экс­плу­ати­ровать, есть ли реаль­ные уяз­вимос­ти с PoC, кри­тич­ный ли сер­вис и так далее. Весь чек‑лист прой­ден в руч­ном режиме. 90% работы над про­ектом дол­жно занимать руч­ное тес­тирова­ние, ресерч, попыт­ки экс­плу­ата­ции имен­но в руч­ном режиме. Как писать отчет От­чет — это резуль­тат про­екта, ради него все и дела­ется, поэто­му пере­оце­нить его зна­чение вряд ли воз­можно. В хорошем отче­те дол­жны быть: Еди­ный стиль изло­жения, отсутс­твие грам­матичес­ких и сти­лис­тичес­ких ляпов, опи­сание рисун­ков, схем, таб­лиц. Что­бы всем было при­ятно смот­реть на отчет и содер­жание было пре­дель­но ясным. Де­таль­ное опи­сание недос­татков. Не прос­то общее опи­сание, а для кон­крет­ных слу­чаев: где наш­ли уяз­вимость, в каком парамет­ре или модуле. При­меры экс­плу­ата­ции. Показа­ны най­ден­ные баги, прик­репле­на кар­тинка как пруф. Чита­ющий может пов­торить дей­ствие с кар­тинки. Так­же не помеша­ет деталь­ное опи­сание про­цес­са тес­тирова­ния, ссыл­ки на базы уяз­вимос­тей ФСТЭК Рос­сии или тех­ник MITRE. Ре­комен­дации так­же про­писа­ны для кон­крет­ных слу­чаев, опи­саны точеч­ные советы, имен­но для того фрей­мвор­ка и сте­ка тех­нологий, который исполь­зует заказ­чик. Нет двус­мыслен­ности. Есть раз­ные вари­анты устра­нения. Нап­ример, ты нашел уяз­вимость, которая поз­воля­ет переби­рать поль­зовате­лей. Сис­тема реаги­рова­ла по‑раз­ному в тех слу­чаях, ког­да поль­зователь сущес­тву­ет и ког­да его нет. Мож­но дать общую рекомен­дацию — внед­рить CAPTCHA-тест. Но если зна­ешь, что у заказ­чика исполь­зует­ся, нап­ример, Django, то мож­но дать рекомен­дации имен­но для это­го фрей­мвор­ка. Ре­зюме работы с циф­рами, рекомен­даци­ями и выводом. От­чет офор­млен на осно­ве воп­росов, задан­ных заказ­чиком перед про­ектом. Затем идет то, что спе­циалис­ты счи­тают важ­ным и релеван­тным. Если воп­росов не было, то по иерар­хии кри­тич­ности всех находок. При­веде­на ана­лити­ка: количес­тво уяз­вимос­тей, хос­тов, которые были про­вере­ны, или топ уяз­вимос­тей в ком­пании, или динами­ка по пре­дыду­щим пен­тестам и вре­мени жиз­ни уяз­вимос­тей, если есть такая воз­можность. Мо­дели­рова­ние угроз поведе­ния зло­умыш­ленни­ка. Нуж­но показать, что слу­чит­ся, если зло­умыш­ленник про­экс­плу­ати­рует уяз­вимость. Нап­ример, уяз­вимость с SMS-спа­мом, как пра­вило, заказ­чики не понима­ют. Поэто­му нуж­но показать, в чем ее риск, объ­яснить, что про­вай­дер поз­воля­ет круп­ным ком­пани­ям отправ­лять до 3 тысяч SMS в секун­ду. На отправ­ку 200 зап­росов ком­пания тра­тит 400 руб­лей в секун­ду. Если ата­ка длит­ся час, то зло­умыш­ленник сож­жет поч­ти 1,5 мил­лиона руб­лей с балан­са ком­пании. Что важно обсудить