Пентесты в Group-IB. Разбор полетов и три истории из практики

К сожале­нию, дос­таточ­но раз­верну­тых и пол­ных отве­тов не приш­ло, а некото­рые пись­ма содер­жали все­го пару абза­цев тек­ста в ответ на все воп­росы. Это­го, увы, недос­таточ­но, что­бы получить приг­лашение на работу!

Сра­зу обоз­начим, что на некото­рые воп­росы нет однознач­но пра­виль­ного отве­та. Был инте­ресен ско­рее спо­соб мыш­ления отве­чающе­го. Ниже ребята из Group-IB опи­шут, как сами отве­чали бы на задан­ные воп­росы, и дадут ком­мента­рии.

Вопрос 1. Токены JWT

Есть мобиль­ное бан­ков­ское при­ложе­ние, которое выда­ет такой единс­твен­ный сес­сион­ный токен:

Пред­ложи, какие могут воз­никнуть сце­нарии атак на это при­ложе­ние. Как их пре­дот­вра­тить?

Ком­мента­рий: Все отве­тив­шие пра­виль­но ска­зали, что это JWT на Hash-based-алго­рит­ме про­вер­ки целос­тнос­ти (HS256). Дей­стви­тель­но, если ты час­то изу­чаешь при­ложе­ния, эти токены лег­ко узна­ваемы. Мно­гие начали перечис­лять типич­ные ата­ки на такие JWT — воз­можность обма­нуть при­ложе­ние, сме­нив алго­ритм под­писи, брут­форс сек­рета под­писи.

Ес­ли отбро­сить в сто­рону пред­ска­зуемые и ожи­даемые типовые ата­ки на JWT, тем более в иссле­дуемом при­ложе­нии они не работа­ли, у нас оста­ется сле­дующее. Мобиль­ное при­ложе­ние выда­ет единс­твен­ный сес­сион­ный токен, в котором вся наг­рузка — это один чис­ловой параметр user_id. Кто‑то начал писать, что тут вид­но ID, его мож­но под­менять, переби­рать, бру­тить. Но в этом токене есть рабочая про­вер­ка под­писи, и такие ата­ки, естес­твен­но, не прой­дут. У читате­лей, кста­ти, была воз­можность проб­рутить сек­рет, но это ни у кого не получи­лось сде­лать.

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

Нас­чет пре­дот­вра­щения — надо как минимум добавить уни­каль­ный иден­тифика­тор устрой­ства, вре­мя исте­чения токена и чер­ный спи­сок ском­про­мети­рован­ных токенов на сер­вере. Короче, взять от стан­дарта и рекомен­даций по JWT луч­шее. Здесь мы вплот­ную подош­ли к холива­ру о целесо­образнос­ти JWT-токенов для сес­сий, но это сов­сем дру­гая исто­рия...

Вопрос 2. IPv6

Пред­ставь, что весь текущий мир одно­момен­тно перешел на IPv6. IPv4 боль­ше не исполь­зует­ся. Как это изме­нит сетевую безопас­ность, с уче­том сов­ремен­ных под­ходов к нас­трой­ке сетей и тех­ник атак на сети?

Ком­мента­рий: Это, разуме­ется, воп­рос, на который невоз­можно дать единс­твен­но пра­виль­ный ответ. Лич­но мы счи­таем важ­ным в пер­вую оче­редь сле­дующее.

• От­пада­ет необ­ходимость в Network Address Translation, NAT. В мире IPv4 выходит, что NAT кос­венно выпол­няет фун­кции меж­сетево­го экра­на, даже если нас­тро­ен толь­ко NAT и не нас­тро­ена сама филь­тра­ция. Если скрыть целую под­сеть за единс­твен­ным адре­сом, мож­но сде­лать невоз­можным пря­мое обра­щение к любому IP/пор­ту в этой сети, без явной пуб­ликации сер­виса «наружу». Сле­дует понимать, что NAT воз­ник в том чис­ле из‑за нех­ватки адре­сов IPv4 и проб­лем воз­можно­го пересе­чения адресно­го прос­транс­тва раз­ных сетей. IPv6 гаран­тиру­ет, что адре­сов хва­тит всем и NAT не нужен — это пус­тая тра­та ресур­сов. В ито­ге те, кто при­вык нас­тра­ивать NAT, но не нас­тра­ивать фай­рвол, вне­зап­но обна­ружат, что их сеть целиком дос­тупна из интерне­та. Автор воп­роса сам видел подоб­ные кон­фигура­ции на пен­тестах и пару раз раз­бирал механиз­мы работы домаш­них роуте­ров — там эта проб­лема тоже при­сутс­тву­ет.
• С дру­гой сто­роны, гигант­ское адресное прос­транс­тво IPv6 боль­ше не поз­волит вот так прос­то взять и прос­каниро­вать все адре­са за пару часов, как сей­час при­нято делать. «Слу­чай­ная безопас­ность» от это­го выиг­рает.
• Обя­затель­но най­дет­ся мно­жес­тво адми­нов или прог­раммис­тов, которые напишут пар­сер с ошиб­кой или неточ­ную регуляр­ку на адрес IPv6. Такой адрес име­ет новые нотации, и в пер­вую оче­редь инте­рес­на воз­можность сок­ратить окте­ты. Сам факт того, что адрес в hex по умол­чанию, добавит воз­можность пен­тесте­рам играть шриф­тами регис­тром. IPv6 перес­танет вле­зать в при­выч­ное всем 32-бит­ное целое и даже в 64 бита не вле­зет. Где‑то нач­нутся «велоси­педы» с его раз­мещени­ем в памяти, с вытека­ющи­ми ошиб­ками ариф­метики. В совокуп­ности появят­ся новые век­тора атак с бай­пасом средств защиты.
• ICMPv6 — это зна­читель­но боль­шая сущ­ность, чем ICMPv4. В шес­той вер­сии фун­кции ARP перене­сены на ICMPv6-NDP. Все для того, что­бы сеть работа­ла сама. Но теперь адми­нис­тра­торам при­дет­ся вни­кать в каж­дый код ICMP, что­бы понять, опа­сен он или нет, или прос­то раз­решить все — с пред­ска­зуемы­ми пос­ледс­тви­ями.
• Не­кото­рые хорошо извес­тные ата­ки поменя­ли уро­вень или про­токол, но при этом не меняли свою суть, а зна­чит, ста­ли нез­накомы­ми для адми­нис­тра­торов, ранее защищен­ных сетевых кон­фигура­ций и некото­рых средств защиты. Появил­ся NDP, который по сути явля­ет собой эта­кий мини-DHCP и ARP в одном фла­коне, он поз­волит ата­кующе­му делать MITM и на роутер, и на соседей, и на DNS-про­токол. За это рань­ше отве­чали ата­ки ARP spoofing и DHCP spoofing. Инте­рес­но, что DHCPv6 при этом тоже есть.
• Су­щес­тво­вание работа­ющих авто­мати­чес­ких link-local-адре­сов парал­лель­но с гло­баль­ными адре­сами будет при­носить мно­го радос­ти сетеви­кам и адми­нис­тра­торам. Вот толь­ко что ими был написан ACL на гло­баль­ный адрес, но уже нуж­но что‑то делать с адре­сами link-local. И хотя такие адре­са работа­ют до бли­жай­шего роуте­ра, все рав­но тре­буют отдель­ного ACL или явно­го зап­рета.
• Про­токол под­держи­вает IPSec по умол­чанию. Если его под­дер­жка в ОС будет пол­ноцен­ной, прог­раммис­ту не сос­тавит тру­да вклю­чить эта­кий TLS с двус­торон­ней про­вер­кой под­линнос­ти и шиф­ровани­ем на любую L4-сетевую служ­бу, и даже на UDP!

Здесь мы перечис­лили толь­ко основные изме­нения, но их зна­читель­но боль­ше. Есть и новые DoS-век­торы, и дру­гая боль адми­нис­тра­торов.

Вопрос 3. Усиленная аутентификация AD

Ты находишь­ся внут­ри кор­поратив­ной сети и про­водишь тес­тирова­ние на про­ник­новение. У тебя име­ется хеш NT домен­ного поль­зовате­ля. В Active Directory нас­тро­ены смарт‑кар­ты (USB-токены) для основной аутен­тифика­ции на рабочее мес­то (через непос­редс­твен­ное вза­имо­дей­ствие с компь­юте­ром) и в RDP. Есть так­же механиз­мы вхо­да по паролю, но они защище­ны одно­разо­выми кодами. Мож­но ли обой­ти эту уси­лен­ную аутен­тифика­цию?

Ком­мента­рий: Важ­но понимать, что общие механиз­мы аутен­тифика­ции в домене Active Directory (AD), какими бы мега­уси­лен­ными они ни были, рано или поз­дно при­дут к двум сетевым про­токо­лам — NetNTLMv2 и Kerberos, через которые один хост будет аутен­тифици­ровать­ся на дру­гом. Оба про­токо­ла в базовом вари­анте исполь­зуют тот самый NT-хеш как исходный матери­ал для аутен­тифика­ции на хос­тах. Таким обра­зом, мож­но проз­рачно аутен­тифици­ровать­ся на дру­гих хос­тах при помощи атак pass-the-hash и overpass-the-hash через NetNTLMv2 и Kerberos соот­ветс­твен­но. Но толь­ко при усло­вии, что адми­нис­тра­торы не сумели зап­ретить NetNTLMv2 и Kerberos все еще работа­ет на ста­рых алго­рит­мах (то есть RC4, где в качес­тве клю­ча выс­тупа­ет все тот же NT хеш).

Воз­ника­ет логич­ный воп­рос: а что же тог­да вооб­ще дела­ют эти уси­лен­ные средс­тва защиты, если аутен­тифика­ция оста­ется той же?

В Windows сущес­тву­ет локаль­ная сис­тема — служ­ба аутен­тифика­ции, LSA. Та самая, которая пред­став­лена про­цес­сом lsass.exe, куда нацеле­ны и mimikatz, и средс­тва защиты. При этом к LSA мож­но добав­лять рас­ширения, которые дают раз­ные спе­цэф­фекты при вхо­де в сис­тему — в виде одно­разо­вых кодов, токенов, пуш‑уве­дом­лений на телефон и про­чего. Для безопас­ности это важ­но с той точ­ки зре­ния, что поль­зователь не смо­жет пос­тавить пароль Qwerty123 (паролей‑то боль­ше нет!), а адми­нис­тра­торы и сами поль­зовате­ли получа­ют уве­дом­ления о том, что акка­унт сей­час про­шел началь­ную аутен­тифика­цию на рабочей стан­ции. Что‑то из этих уси­лен­ных средств под­держи­вает­ся в AD «из короб­ки», нап­ример некото­рые смарт‑кар­ты. Одна­ко цель у них одна — сде­лать обер­тку над все теми же NTLM/Kerberos. Нап­ример, для некото­рых средств защиты может быть задей­ство­ван про­вай­дер на кон­трол­лере домена, при­нима­ющий «уси­лен­ное» сооб­щение аутен­тифика­ции от поль­зовате­ля и отсы­лающий поль­зовате­лю из базы AD все тот же NТ хеш. В «исходном» же вари­анте, без этих уси­лен­ных средств защиты, этот хеш NT генери­рует­ся непос­редс­твен­но на компь­юте­ре поль­зовате­ля из пароля при его вво­де.

Еще мож­но отме­тить, что в «уси­лен­ном» вари­анте средс­тва защиты дела­ют NT-хеш таким обра­зом, что­бы было мак­сималь­но зат­рудни­тель­но подоб­рать к нему кол­лизию, то есть най­ти соот­ветс­тву­ющий ему пароль. Поэто­му бру­тить име­ющий­ся NT-хеш в «уси­лен­ной» сре­де, веро­ятнее все­го, бес­полез­но.

Вопрос 4. Бинарная эксплуатация

Exploit-db.com ког­да‑то был запол­нен экс­пло­ита­ми, нацелен­ными на пов­режде­ние памяти в бинар­ных при­ложе­ниях 2000-х годов. Но все поменя­лось, и там сей­час пре­обла­дают экс­пло­иты, нацелен­ные на веб, логичес­кие баги, мис­конфи­ги. Сто­имость бинар­ных экс­пло­итов в час­тной про­даже сей­час воз­росла до сотен тысяч дол­ларов. Как ты дума­ешь, почему?

Ком­мента­рий: Здесь все более‑менее прос­то. Возь­мем для при­мера архи­тек­туру x86. В какой‑то момент ата­ки на «бинарь» надо­ели «защища­ющей­ся» сто­роне, и про­изво­дите­лями опе­раци­онных сис­тем сов­мес­тно с про­изво­дите­лями про­цес­соров были реали­зова­ны меры про­тив этих атак — DEP, ASLR, Canaries, Control Flow Guard, SMEP, SMAP. Про­цесс был дол­гим и пос­ледова­тель­ным, и сей­час для успешной ата­ки, в зависи­мос­ти от ее типа и ата­куемо­го при­ложе­ния, нуж­но обой­ти какие‑то из этих механиз­мов. Где‑то в это же вре­мя парал­лель­но про­изо­шел переход с x32 на x64, что важ­но с точ­ки зре­ния, нап­ример, того же ASLR, где одни из тех­ник обхо­да — это «уга­дыва­ние» адре­сов или запол­нение мусором адресно­го прос­транс­тва про­цес­са. Оче­вид­но, что на x32 это делать про­ще.

И самое глав­ное. При­ложе­ния, где тре­бует­ся пря­мая, «руч­ная» работа с памятью (нап­ример, написан­ные на С), пос­тепен­но начали вытес­нять­ся при­ложе­ниями, где есть менед­жеры памяти (C#, Java, Python, PHP и так далее). Ошиб­ки пов­режде­ния памяти в них сош­ли на нет, зато на пер­вое мес­то выш­ли ошиб­ки дру­гого рода — логичес­кие. А бинарь оста­лась толь­ко там, где тре­бует­ся исклю­читель­но про­изво­дитель­ность и низ­коуров­невость, — это что‑то сов­сем близ­кое к ОС, ее натив­ному API или железу. Круг при­ложе­ний сузил­ся, слож­ность атак вырос­ла, и поэто­му бинар­ные экс­пло­иты ста­ли очень слож­ными и дороги­ми.

Вопрос 5. Какие алгоритмы выгоднее взломать?

Пред­ставь, что у тебя появи­лась супер­спо­соб­ность — ты теперь можешь момен­таль­но взло­мать что‑то одно на твой выбор:

• ли­бо все сим­метрич­ные (блоч­ные, потоко­вые) алго­рит­мы шиф­рования (то есть рас­шифро­вать любой текст, зашиф­рован­ный сим­метрич­ными алго­рит­мами);
• ли­бо все асим­метрич­ные алго­рит­мы (то есть вос­ста­новить любой при­ват­ный ключ по пуб­лично­му клю­чу);
• ли­бо все хеш‑фун­кции (то есть подоб­рать кол­лизию для любого хеша).

Что бы ты выб­рал и почему?

Ком­мента­рий: Естес­твен­но, на этот воп­рос так­же нет еди­ного и тем более пра­виль­ного вари­анта. Мы хотели уви­деть, нас­коль­ко отве­ты уве­дут в глу­бину про­токо­лов. Мно­гие отве­чали исхо­дя из сво­их пред­почте­ний: хотим вскры­вать зашиф­рован­ное — выбира­ем взло­ман­ные алго­рит­мы сим­метрич­ного шиф­рования. Хотим под­делать под­пись — выбира­ем взло­ман­ное асим­метрич­ное. Хотим взло­мать базу паролей — выбира­ем хеширо­вание.

Од­нако тут есть некото­рые неоче­вид­ные темы для раз­мышле­ния. И свя­заны они как раз с кон­крет­ными про­токо­лами или реали­заци­ями алго­рит­мов. Покажем на при­мере.

Очень час­то нам писали: хочу читать зашиф­рован­ный тра­фик, поэто­му выбираю сим­метрич­ные алго­рит­мы. Сов­сем рядом вто­рой вид отве­та — хочу читать тра­фик (ну кто бы сом­невал­ся, в тра­фике куча инте­рес­ностей), но уже хочу асим­метрич­ные алго­рит­мы. Если с пер­вым спо­собом все понят­но, вто­рой спо­соб чуть более хит­рый. Он осно­ван на том, что очень час­то ключ шиф­рования тра­фика выбира­ется на осно­ве про­токо­лов обме­на клю­чами, нап­ример того же TLS, где исполь­зуют­ся сер­тифика­ты и асим­метрич­ные алго­рит­мы. Получив при­ват­ный ключ на осно­ве сер­тифика­та, мож­но было бы вос­ста­новить и сес­сион­ный сим­метрич­ный ключ, а затем и рас­шифро­вать тра­фик.

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

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

Бонус: три истории из практики

Что­бы ты луч­ше пред­ста­вил, чем занима­ются пен­тесте­ры в Group-IB, мы под­готови­ли для тебя три занима­тель­ные исто­рии из прак­тики их работы.

История #1. Про восхождение от подножия протухшего вайфая к жерлу ДБО

В рам­ках ред­тим‑про­екта для бан­ка сто­яла свер­хза­дача получить дос­туп к сег­менту ДБО. Ите­рация ред­тимин­га была уже далеко не пер­вой, и более клас­сичес­кие фор­маты вро­де пен­теста и ауди­тов при­ложе­ний заказ­чик про­водил регуляр­но. Соот­ветс­твен­но, периметр не изо­било­вал дыр­ками. Мы решили про­верить раз­ные гипоте­зы, в том чис­ле свя­зан­ные с невер­но нас­тро­енным вай­фаем в отде­лени­ях.

Мы про­вели раз­ведку в нес­коль­ких фили­алах «треть­его эше­лона», выб­рали наибо­лее под­ходящий с самым инте­рес­ным ради­оэфи­ром и наиме­нее серь­езны­ми сот­рудни­ками. Один из них и купил­ся на леген­ду нашего спе­циалис­та о том, что ему сроч­но нуж­но зай­ти в онлайн‑бан­кинг при нулевом балан­се мобиль­ного сче­та. Логич­но: что­бы опла­тить интернет, нужен дос­туп в интернет. Сот­рудник выдал пароль от Wi-Fi, спе­циалист потыкал в телефон, поб­лагода­рил и ушел. Ушел, конеч­но же, в локал­ку!

Для горизон­таль­ного прод­вижения мы исполь­зовали информа­цию, получен­ную в про­цес­се внеш­ней раз­ведки: в лич­ном бло­ге одно­го из адми­нис­тра­торов БД не слиш­ком надеж­но хра­нил­ся пароль неп­ривиле­гиро­ван­ного поль­зовате­ля от сер­веров Linux. С этой учет­кой мы получи­ли SSH и на одном из сер­веров наш­ли билет Kerberos — уже с при­виле­гиями адми­на.

По­выси­лись на хос­те и получи­ли поль­зовате­лей адми­нис­тра­торов Linux. К нашему удив­лению, при­виле­гий текуще­го поль­зовате­ля уже хва­тило для дос­тижения цели. Про­фит: дос­туп к сер­веру с ДБО и про­ектная ачив­ка!

История #2. Про социнженерию, жадность и внезапную помощь

Ког­да заказ­чик про­сит про­вес­ти «соци­алку» в фор­мате awareness (про­веря­ется реак­ция на пись­мо поль­зовате­лей, а не средств защиты), мы заранее зна­ем, что сред­ний КПД таких воз­дей­ствий (количес­тво попав­шихся к количес­тву получив­ших пись­ма поль­зовате­лей) сос­тавит 20–25%. Так­же зна­ем, что как минимум такая же часть получив­ших не перей­дет по ссыл­кам или не запус­тит исполня­емый файл не по при­чине нас­торожен­ности, а из лени.

Ес­ли отпра­вить еще одно пись­мо, КПД сущес­твен­но вырас­тет, если проз­вонить с напоми­нани­ем о необ­ходимос­ти реак­ции — вырас­тет в разы. Но при­мер­но раз в год мы видим исто­рию, ког­да эффектив­ность рас­сылки шка­лит и уве­рен­но про­бива­ет 100%. Как это про­исхо­дит? Очень прос­то. То получа­тель решит поделить­ся с друзь­ями из дру­гих отде­лов ком­пании, то боль­шой началь­ник переш­лет на под­кон­троль­ное ему под­разде­ление. Толь­ко успе­вай под­став­лять лог‑фай­лы под льющи­еся пру­фы и кре­ды.

В пос­ледний раз такое было сов­сем недав­но. Сот­рудни­кам заказ­чика отправ­лялся документ с пред­ложени­ями о скид­ках на покуп­ку гад­жетов в круп­ной тор­говой сети. Зак­рытая пар­тнерская рас­про­дажа, низ­кие цены, огра­ничен­ное количес­тво — такое работа­ет всег­да. Халява манит так силь­но, что глаз не цеп­ляет­ся за кучу спе­циаль­но оставлен­ных арте­фак­тов, кри­чащих: «Мошен­ничес­тво! АЛЯРМ‑АЛЯРМ!»

Поль­зовате­лю, открыв­шему документ, пред­лагалось выб­рать позиции, на которые он хотел бы узнать акту­аль­ные цены, нажать на кноп­ку (в докумен­те!), что­бы яко­бы получить акту­аль­ные дан­ные с сер­вера тор­говой сети. При нажатии на кноп­ку выпол­нялась наг­рузка, а поль­зовате­лю выводи­лось сооб­щение о вре­мен­ной недос­тупнос­ти сер­вера в свя­зи с боль­шим количес­твом обра­щений.

В пер­вый час было тихо: ни одно­го сра­баты­вания. Затем нам приш­ло пись­мо с адре­са, которо­го в рас­сылке изна­чаль­но не было. Сот­рудник пред­ста­вил­ся спе­циалис­том PR-депар­тамен­та заказ­чика, ска­зал, что пись­мо ему отпра­вил один из сот­рудни­ков, посето­вал на то, что пар­тнерские рас­сылки не сог­ласова­ны с PR, ска­зал, что текст пись­ма содер­жит ошиб­ки и пло­хо офор­млен, а спи­сок получа­телей вооб­ще стран­ный и кро­шеч­ный. Так­же нам сооб­щили, что поп­равлен­ный пиар­щиками текст с нашим вло­жени­ем кра­сиво офор­млен и разос­лан на всю ком­панию. Боль­шое спа­сибо!

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

История #3. Про лень, хитрость и китайский опенсорс

На про­екте про­води­ли иссле­дова­ние ERP-сис­темы. Активное учас­тие в про­екте при­нимал пред­ста­витель раз­работ­чика, соз­давше­го для боль­шой ком­пании ERP с нуля. Пол­ностью кас­томная раз­работ­ка.

Пред­ста­витель раз­работ­чика выражал боль­шие сом­нения в том, что на про­екте будет най­дена хотя бы одна серь­езная уяз­вимость, силь­но сом­невал­ся в воз­можнос­ти экс­плу­ата­ции обна­ружен­ных дыр и обсуждал рас­четы CVSS. В общем‑то, типич­ное поведе­ние раз­работ­чика от отри­цания к при­нятию! Прох­ладная часть исто­рии зак­люча­ется в том, что уже в самом начале про­екта, изу­чая отве­ты при­ложе­ния, мы по спе­цифи­чес­кому тек­сту ошиб­ки выш­ли на инте­рес­ный GitHub-репози­торий. Обна­ружен­ный про­ект был нес­коль­ко мень­ше иссле­дуемо­го, но слиш­ком час­то выдавал пол­ные сов­падения.

Про­ведя неболь­шое рас­сле­дова­ние, мы обна­ружи­ли, что най­ден­ный репози­торий содер­жал кон­цепт ERP-сис­темы, раз­работан­ный китай­ски­ми сту­ден­тами как дип­ломный про­ект. Далее откры­тый репози­торий наш­ли извес­тные нам раз­работ­чики и прев­ратили дип­ломный экспе­римент в ком­мерчес­кий про­дукт, дорабо­тав который успешно про­дали нашему заказ­чику как свою раз­работ­ку. Бра­во!

Часть исходно­го кода про­дук­товой сис­темы все это вре­мя находи­лась в откры­тых источни­ках. В них же мы обна­ружи­ли в коде кон­трол­лер с говоря­щим наз­вани­ем — SpyController, метод которо­го поз­волял уда­лен­но исполнять про­изволь­ный код.

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