В поисках секретов. Используем силу регулярок при атаке и защите

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

Кста­ти, мно­гие отрасли тре­буют соб­людения стро­гих стан­дартов безопас­ности: GDPR, HIPAA, PCI DSS и дру­гих. Поиск и защита сек­ретов — одна из сос­тавля­ющих соот­ветс­твия этим стан­дартам.

Какие методы автоматизации выбрать?

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

Регулярные выражения

Ре­гуляр­ные выраже­ния (regular expressions, regex, регуляр­ки) — это мощ­ный инс­тру­мент для манипу­ляций с тек­стом, исполь­зующий спе­циаль­ный син­таксис шаб­лонов, что­бы искать, менять и вытас­кивать дан­ные.

Сре­ди плю­сов:

1. Точ­ность и воз­можность тон­кого кон­тро­ля. Мы можем задавать любые спе­цифи­чес­кие пат­терны для обна­руже­ния строк, что миними­зиру­ет количес­тво лож­ных сра­баты­ваний. Это осо­бен­но полез­но для поис­ка кон­крет­ных типов сек­ретов, таких как клю­чи API, пароли и токены дос­тупа.
2. Гиб­кость. Пос­коль­ку регуляр­ные выраже­ния под­держи­вают слож­ные шаб­лоны, мы можем искать самую раз­ную инфу, вклю­чая email-адре­са, IP-адре­са, номера кре­дит­ных карт и любую дру­гую чувс­тви­тель­ную информа­цию.
3. Прос­тота внед­рения. Мно­гие сре­ды раз­работ­ки и редак­торы кода име­ют встро­енную под­дер­жку regex, так­же есть биб­лиоте­ки поч­ти для любых язы­ков прог­рамми­рова­ния. Это поз­воля­ет лег­ко интегри­ровать регуляр­ки в любой про­ект.
4. Ав­томати­зация. С исполь­зовани­ем сис­тем CI/CD regex мож­но нас­тро­ить для авто­мати­чес­кого ска­ниро­вания кода при каж­дом ком­мите, что помога­ет быс­тро обна­ружи­вать и устра­нять уяз­вимос­ти. Некото­рые инс­тру­мен­ты, нап­ример Gitleaks, поз­воля­ют исполь­зовать pre-commit hook, что повыша­ет уро­вень защиты от уте­чек.

Так в чем под­вох? Если все так прек­расно, то зачем вооб­ще исполь­зовать что‑то еще? Дело в том, что у это­го метода так­же есть и минусы.

1. За­виси­мость от шаб­лонов. Регуляр­ки эффектив­ны толь­ко для поис­ка извес­тных шаб­лонов и могут про­пус­кать сек­реты, которые им не соот­ветс­тву­ют. Если фор­мат меня­ется или исполь­зует­ся уни­каль­ный, то инс­тру­мент на базе регуляр­ных выраже­ний может ничего не обна­ружить.
2. Слож­ность соз­дания регуляр­ных выраже­ний и управле­ния ими. Написа­ние эффектив­ных и безопас­ных регуля­рок может быть неп­ростой задачей, осо­бен­но для нес­тандар­тных шаб­лонов.
3. Лож­ные сра­баты­вания. Если шаб­лон слиш­ком общий, он обна­ружи­вает стро­ки, которые не явля­ются сек­ретами. Поэто­му филь­тро­вать и ана­лизи­ровать при­дет­ся допол­нитель­но и уже руч­ками.
4. Про­изво­дитель­ность. Слож­ные регуляр­ные выраже­ния могут мед­ленно работать на боль­ших фай­лах или мно­жес­тве фай­лов.

Анализ энтропии

По­мимо регуляр­ных выраже­ний, при поис­ке сек­ретов при­меня­ют еще один эффектив­ный метод — ана­лиз энтро­пии. Для начала давай раз­берем основные тер­мины.

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

Для рас­чета энтро­пии стро­ки есть матема­тичес­кая фор­мула Кло­да Шен­нона. Общий про­цесс вычис­ления энтро­пии выг­лядит так:

1. Чте­ние стро­ки: сна­чала берет­ся стро­ка из кода или фай­ла, нап­ример a9$L2@xZ.
2. Под­счет сим­волов: под­счи­тыва­ется количес­тво каж­дого сим­вола в стро­ке.
3. Вы­чис­ление веро­ятности: опре­деля­ется, как час­то каж­дый сим­вол появ­ляет­ся в стро­ке. Нап­ример, a встре­чает­ся один раз из вось­ми сим­волов.
4. Рас­чет энтро­пии.

Для рас­чета энтро­пии исполь­зует­ся фор­мула Шен­нона:

где

• H(X) — энтро­пия стро­ки X;
• P(x_i) — веро­ятность появ­ления сим­вола x_i;
• n — количес­тво уни­каль­ных сим­волов в стро­ке.

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

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

А теперь о пре­иму­щес­твах и недос­татках это­го метода. Пре­иму­щес­тва:

1. Об­наруже­ние неиз­вес­тных шаб­лонов. Исполь­зование энтро­пии поз­воля­ет выяв­лять слу­чай­ные стро­ки, которые могут не соот­ветс­тво­вать извес­тным шаб­лонам сек­ретов.
2. Ав­томати­чес­кое обновле­ние. Метод не тре­бует пос­тоян­ного обновле­ния пра­вил или шаб­лонов при изме­нении фор­мата сек­ретов.
3. Ши­рокий охват. Мож­но выяв­лять раз­ные типы сек­ретов без соз­дания спе­цифи­чес­ких шаб­лонов.

Ана­лиз энтро­пии удоб­ный, но не иде­аль­ный метод. Вот какие у него есть минусы:

1. Лож­ные сра­баты­вания. Увы, пока что не сущес­тву­ет ни одно­го метода без это­го косяка. Высокая энтро­пия может быть у строк, которые не явля­ются сек­ретами (нап­ример, хеши, слу­чай­ные дан­ные), что при­водит к лож­ным сра­баты­вани­ям.
2. Слож­ность нас­трой­ки. Спо­соб тре­бует тща­тель­ной нас­трой­ки порогов энтро­пии, что­бы сба­лан­сировать точ­ность и количес­тво лож­ных сра­баты­ваний.
3. Про­изво­дитель­ность. Ана­лиз энтро­пии может быть вычис­литель­но зат­ратным, осо­бен­но для боль­ших объ­емов дан­ных.

Как видишь, слож­ность нас­трой­ки и зат­рата ресур­сов — неиз­бежные минусы в любом слу­чае. Но детали могут отли­чать­ся в зависи­мос­ти от реали­зации того и дру­гого метода.

Какие есть инструменты?

По­иск сек­ретов — один из про­цес­сов раз­работ­ки безопас­ного прог­рам­мно­го обес­печения. По ГОСТ 56939 здесь мы так­же можем исполь­зовать инс­тру­мен­ты ста­тичес­кого ана­лиза. Одна­ко прак­тика показы­вает, что его качес­тво оставля­ет желать луч­шего. Поэто­му в рам­ках иссле­дова­ния рас­смот­рим три инс­тру­мен­та:

• Gitleaks;
• TruffleHog;
• Detect Secrets.

Gitleaks — это инс­тру­мент для обна­руже­ния сек­ретов пре­иму­щес­твен­но в репози­тори­ях Git, но при нор­маль­ной нас­трой­ке он так­же может ска­ниро­вать локаль­ные исходные дан­ные. Этот инс­тру­мент исполь­зует как регуляр­ные выраже­ния, так и ана­лиз энтро­пии для поис­ка кон­фиден­циаль­ной инфы, что дела­ет его неверо­ятно полез­ным для пре­дот­вра­щения уте­чек информа­ции.

Gitleaks под­держи­вает мно­жес­тво шаб­лонов для раз­ных сек­ретов, име­ет воз­можность гиб­кой нас­трой­ки — поль­зователь сам может редак­тировать пра­вила и шаб­лоны для более точ­ного обна­руже­ния. Gitleaks лег­ко интегри­рует­ся с пай­плай­нами CI/CD, обес­печивая авто­мати­чес­кое ска­ниро­вание на эта­пе раз­работ­ки. А еще он бес­плат­ный и у него активное сооб­щес­тво, что спо­собс­тву­ет его раз­витию и улуч­шению. Но здесь есть недос­таток: ана­лиз энтро­пии не всег­да может быть точ­ным и тре­бует тща­тель­ной нас­трой­ки порогов.

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

Пос­ледний в нашем обзо­ре — Detect Secrets. Что­бы обна­ружить сек­ретную информа­цию, он исполь­зует ком­бинацию регуляр­ных выраже­ний, ана­лиза энтро­пии и спец­пла­гинов. Бла­года­ря сво­ей гиб­кости и воз­можнос­ти интегра­ции с CI/CD Detect Secrets поль­зует­ся популяр­ностью сре­ди раз­работ­чиков и спе­циалис­тов по безопас­ности. Но имей в виду: что­бы все работа­ло эффектив­но, при­дет­ся попотеть на эта­пе нас­трой­ки и филь­тра­ции лож­ных сра­баты­ваний.

Краткая характеристика базовых инструментов

Оцениваем эффективность инструментов на практике

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

Пос­мотрим, что най­дут инс­тру­мен­ты, если мы не будем тро­гать нас­трой­ки по умол­чанию.

Gitleaks

• Про­ект на GitHub

Для запус­ка инс­тру­мен­та исполь­зовалась сле­дующая коман­да:

Здесь пап­ка с исходни­ками локаль­ная, поэто­му исполь­зует­ся ключ --no-git. В резуль­тате ска­ниро­вания мы получи­ли файл gitleaks_report.json, содер­жащий 20 най­ден­ных сек­ретов. Из них 9 сек­ретов приз­наны лож­но положи­тель­ными.

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

И сно­ва получим 20 най­ден­ных сек­ретов, из которых 9 — лож­ные сра­баты­вания.

TruffleHog

• Про­ект на GitHub

Этот инс­тру­мент запус­кался сле­дующей коман­дой: