Как проходит этичный взлом. Колонка Юрия Гольцева

Преамбула

В рос­сий­ских реалиях ИБ при­нято раз­делять так называ­емый пен­тест на внеш­ний и внут­ренний, в зависи­мос­ти от рас­смат­рива­емой модели наруши­теля. Модель наруши­теля — это некие исходные/ввод­ные дан­ные, с которы­ми этич­ный хакер начина­ет модели­ровать и раз­вивать ата­ку. Внеш­нему пен­тесту харак­терна модель «внеш­него зло­умыш­ленни­ка», ата­кующе­го из внеш­ней сети — интерне­та и не обла­дающе­го какой‑либо информа­цией о сис­теме. Внут­ренний этич­ный хакер модели­рует дей­ствия потен­циаль­ного «инсай­дера», обла­дающе­го при­виле­гиями рядово­го поль­зовате­ля.

В боль­шинс­тве слу­чаев, ког­да говорят «пен­тест» без каких‑либо уточ­нений, под­разуме­вают работы, пок­рыва­ющие обе модели. В этом слу­чае модель внеш­него ата­кующе­го, который пре­одо­лел сетевой периметр орга­низа­ции, получил дос­туп в ее сеть и раз­жился минималь­ными при­виле­гиями, плав­но и изящ­но перете­кает в модель внут­ренне­го наруши­теля. Таким обра­зом, раз­деление на внеш­ний и внут­ренний пен­тест нап­рямую свя­зано с пот­ребнос­тями рын­ка. Кто‑то хочет лишь оце­нить воз­можность пре­одо­ления подот­ветс­твен­ного сетево­го перимет­ра и про­верить, нас­коль­ко орга­низа­ция готова к ата­ке извне. Кто‑то же, наобо­рот, пол­ностью уве­рен, что угро­зы со сто­роны интерне­та нет, и боль­ше все­го боит­ся про­фес­сиональ­ного «инсай­дера», охо­тяще­гося за кор­поратив­ными сек­ретами.

Другие статьи в выпуске:

Хакер #194. Car hacking!

• Содержание выпуска
• Подписка на «Хакер»-60%

Коротко о различиях

Да­вай выявим осо­бен­ности, харак­терные для так называ­емых внеш­него и внут­ренне­го пен­теста.

• Внеш­ний пен­тест под­разуме­вает в 99% слу­чаев плос­кую сеть как область работ, на внут­ренних работах это спра­вед­ливо лишь в 10% слу­чаев (нап­рочь отсутс­тву­ет сег­мента­ция сетей).
• В рам­ках внеш­него пен­теста нам­ного про­ще выб­рать цель для иссле­дова­ния на пред­мет уяз­вимос­тей. Это нап­рямую свя­зано с отсутс­тви­ем «левых» сер­висов на перимет­ре. Соот­ветс­твен­но, и вре­мени получа­ется уде­лить на такой ресерч боль­ше.
• Ата­ки на каналь­ном уров­не нам­ного дос­тупнее в рам­ках внут­ренне­го пен­теста.
• Ос­новная цель внеш­него пен­теста — пре­одо­ление внеш­него «сетево­го» перимет­ра орга­низа­ции.
• Пер­вооче­ред­ная цель внут­ренне­го пен­теста, если это явно не обго­воре­но, — заполу­чить мак­сималь­ные при­виле­гии на всех ком­понен­тах ИС.

Преодоление периметра

Как я уже отме­тил, при внеш­нем пен­тесте в боль­шинс­тве слу­чаев не так мно­го сер­висов, которые потен­циаль­но могут быть легитим­ной/нелеги­тим­ной точ­кой вхо­да во внут­реннюю сеть. В теории — чем мень­ше сер­висов на перимет­ре, тем боль­ше вре­мени этич­ный хакер уде­ляет каж­дому из них. На прак­тике это, естес­твен­но, не так: видя перед собой информа­цию обо всех дос­тупных на перимет­ре сер­висах, в пер­вую оче­редь выис­кива­ешь те, с которы­ми встре­чал­ся в лич­ной прак­тике и удач­но экс­плу­ати­ровал най­ден­ные уяз­вимос­ти, сле­дом идет изу­чение нез­накомых до дан­ного момен­та прог­рам­мных про­дук­тов, и, наконец, при­ходишь к ана­лизу авто­мати­зиро­ван­ных ска­нов на пред­мет наличия уяз­вимос­тей, информа­ция о которых дос­тупна в паб­лике. Про­цесс иссле­дова­ния по вре­мени при­мер­но так и раз­деля­ется: сна­чала треть на зна­комую область, треть на новые про­дук­ты, треть на автоска­ны. Но если вдруг быс­тро понима­ешь, что в пп. 1 ловить нечего, а в пп. 2 есть потен­циаль­ные инте­рес­ности, все вре­мя можешь уде­лить ему — иссле­дова­нию нез­накомых, но потен­циаль­но уяз­вимых про­дук­тов.

При­веду при­мер из лич­ной прак­тики, нап­рямую свя­зан­ном с сер­висами, вни­мание пен­тесте­ра на которые перек­люча­ется не сра­зу (то есть нез­накомы­ми до дан­ного момен­та прог­рам­мны­ми про­дук­тами). В моем слу­чае это был ManageEngine ServiceDesk. Нем­ного древ­ний, но хороший при­мер. Имен­но такие сер­висы ста­новят­ся темой ресер­чей и целями для не очень дол­го живущих 0day-экс­плой­тов. И имен­но на такие сер­висы ухо­дит боль­ше все­го вре­мени.

Ис­тория такова. На перимет­ре встре­тил­ся до это­го нез­накомый ManageEngine ServiceDesk (веб‑при­ложе­ние для служ­бы тех­поддер­жки, с тикета­ми и про­чими плюш­ками). В ходе иссле­дова­ния дан­ного про­дук­та было най­дено нес­коль­ко уяз­вимос­тей раз­ной сте­пени кри­тич­ности, которые в совокуп­ности поз­воляли заполу­чить пол­ный дамп БД. В том кон­крет­ном слу­чае веб‑при­ложе­ние было завяза­но на Active Directory и для при­вяз­ки был исполь­зован акка­унт адми­нис­тра­тора домена. Неяс­но, зачем это было сде­лано, но факт оста­ется фак­том — в даль­нейшем еще не раз такое встре­чалось. Пароль адми­нис­тра­тора домена хра­нил­ся в обфусци­рован­ном виде, но исходни­ки ServiceDesk помог­ли най­ти его исходное зна­чение. Исполь­зуя эту учет­ную запись и дос­тупный на перимет­ре сер­вис RDP, я получил дос­туп во внут­реннюю сеть. Выш­ло эле­ган­тно.
Ти­пич­ный при­мер того, как сер­вис, до некото­рого момен­та нез­накомый, перехо­дит в перечень сер­висов, которые в пер­вую оче­редь ищешь на перимет­ре.

Та­кие уяз­вимос­ти очень эффек­тно для заказ­чика экс­плу­ати­руют­ся в пери­од, ког­да адви­зори на уяз­вимость уже отправ­лены раз­работ­чикам, но патч, ее исправ­ляющий, еще не вышел. В рам­ках стан­дар­тной полити­ки раз­гла­шения информа­ции об уяз­вимос­тях этот пери­од занима­ет поряд­ка трех месяцев. Но в тот раз все пош­ло не так :). Через пару недель пос­ле завер­шения про­екта на exploit-db.com появи­лась информа­ция об уяз­вимос­ти за авторс­твом граж­данина Син­гапура, который дис­кре­дити­ровал наши обе­щания вен­дору соф­та и заказ­чику о нераз­гла­шении информа­ции об уяз­вимос­ти. Приш­лось сроч­но уве­дом­лять об этой ситу­ации и тех и дру­гих, дабы не запят­нать репута­цию ответс­твен­ных пен­тесте­ров :).

Переломный момент

Ус­ловное обоз­начение «перелом­ный момент» харак­терно имен­но для внут­ренне­го тес­тирова­ния на про­ник­новение. Если крат­ко, это получе­ние таких при­виле­гий в ИС / информа­ции об ИС, которые дают воз­можность получить мак­сималь­ные при­виле­гии в 100% слу­чаев.

В сов­ремен­ных реалиях каж­дый ува­жающий себя айтиш­ник, посети­тель того же Хаб­ра, обра­щает вни­мание на пуб­ликации о кри­тич­ных уяз­вимос­тях, поз­воля­ющих сра­зу же получить пол­ный кон­троль над каким‑либо ком­понен­том ИС. Подоб­ные пуб­ликации почему‑то зас­тавля­ют людей думать, что цепоч­ка, по которой этич­ный хакер идет шаг за шагом к сок­ровен­ным мак­сималь­ным при­виле­гиям, сво­дит­ся все­го лишь к экс­плу­ата­ции %famous_vuln_name_here%. Хочу тебя заверить — это совер­шенно не так.

Как раз таки серь­езные уяз­вимос­ти вро­де MS14-068, которые в один шаг пре­дос­тавля­ют спе­циалис­ту клю­чи от всех две­рей, обыч­но най­ти незак­рытыми куда слож­нее. Нап­ример, в тот момент, ког­да для MS14-068 появил­ся PoC, при­нося­щий про­фит, в окру­ге не ока­залось уже ни одно­го не пат­ченно­го кон­трол­лера домена. Сис­темные адми­нис­тра­торы ста­рают­ся устра­нить подоб­ные уяз­вимос­ти нас­толь­ко быс­тро, нас­коль­ко это вооб­ще воз­можно. Обыч­но опи­сание подоб­ных уяз­вимос­тей в отче­те пен­тесте­ра выг­лядит так: про­вери­ли на всех домен‑кон­трол­лерах, уяз­вимость вез­де устра­нена. Отличный при­мер того, как full disclosure вли­яет на количес­тво уяз­вимых сис­тем. Куда боль­шую угро­зу пред­став­ляют не такие пуб­личные, менее раз­рушитель­ные уяз­вимос­ти. Шанс рас­кру­тить цепоч­ку лоурис­ковых багов нам­ного выше, сле­дова­тель­но, и опас­ности от него куда боль­ше.

При­мер перелом­ного момен­та — сер­вис JBoss, дос­тупный толь­ко на локаль­ном интерфей­се тер­миналь­ной стан­ции, на которой работа­ют десят­ки поль­зовате­лей. Мно­гие забыва­ют, что по умол­чанию JMX console не тре­бует авто­риза­ции, — сек­ции кон­фигура­цион­ного фай­ла web.xml прос­то заком­менти­рова­ны, пре­дос­тавляя тем самым дос­туп к это­му при­ложе­нию любому локаль­ному поль­зовате­лю. Деп­лой прос­тей­шего веб‑шел­ла через JMX console поз­воля­ет получить при­виле­гии nt authority/system на тер­миналь­ной стан­ции и выжать из нее как минимум солид­ный спи­сок логинов и паролей авто­ризо­ван­ных в сис­теме поль­зовате­лей.

Бумага

Под­робное докумен­тирова­ние всех дей­ствий в рам­ках модели­рова­ния ата­ки — неотъ­емле­мая часть работы пен­тесте­ра. Ито­говые докумен­ты подоб­ного харак­тера очень час­то выг­лядят, как статьи в тво­ем любимом жур­нале из катего­рии «Исто­рия взло­ма ...». Помимо опи­сания дей­ствий, этич­ный хакер пре­дос­тавля­ет рекомен­дации по устра­нению най­ден­ных им уяз­вимос­тей, а так­же ведет обще­ние с вен­дором на тему выпус­ка пат­ча, если най­ден­ная им в ходе работ уяз­вимость еще не явля­ется пуб­личной. В слу­чае с ServiceDesk вен­дор поп­росил на выпуск пат­ча дос­таточ­но боль­шой отре­зок вре­мени, поэто­му вла­дель­цу уяз­вимой сис­темы было рекомен­довано огра­ничить дос­туп к уяз­вимому фун­кци­она­лу при­ложе­ния встро­енны­ми средс­тва­ми Apache Tomcat, обслу­жива­ющим уяз­вимое веб‑при­ложе­ние, и, конеч­но же, дожидать­ся офи­циаль­ного пат­ча от про­изво­дите­ля.

В рам­ках рекомен­даций по устра­нению уяз­вимос­ти, свя­зан­ной с ошиб­кой кон­фигура­ции JBoss, было рекомен­довано нас­тро­ить авто­риза­цию для всех при­ложе­ний, иду­щих по умол­чанию, попут­но пре­дос­тавив рекомен­дации, как избе­жать уяз­вимос­ти HTTP Verb Tampering.