![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
malyj_gorganСлухайте, а хтось може в парі абзаців пояснити, що то таке сабж і з чим його їдят? Дідько з нею, з його vulterability'ею, я хочу зрозуміти, чим був такий хороший чи зручний чи потрібний сам log4j, що та вульнерабіліті виявилася такою проблємною? Тільки пояснити так, на хлопский розум, без відсилань в непотрібні абревіатури.
Дякую!
Дякую!
no subject
Date: 2021-12-30 06:12 am (UTC)Сенсу нема. :)
Якщо хтось вкраде наш source code - то (а) нічого особливо секретного в 99% коду він не знайде, усі ідеї давно є публічними, (б) без відповідної інфраструктури (включно з людьми) фіг ти той код запустиш.
no subject
Date: 2021-12-30 11:00 pm (UTC)Сенсу багато. Краджений код не обов'язково запускати, краджений код -- джерело знань про слабкості систем. Тут, в першу чергу, власне діри в самому коді -- поганого коду в цьому житті більше, ніж хорошого. В другу -- такі набагато простіші до аналізу речі, як які бібліотеки десь в бекендах біжать (у кожного першого, ок, кожного другого бізнесу десь в продашені щось робить legacy код багаторічної давності, для чого регулярно підгружають то туди, то сюди, всякі старі версій бібліотек і знарядь, де були відомі діри, якому потрібні старіші бібліотеки, включно з тими, де є величезні задокументовані діри, залатані в пізніших версіях, але то в пізніших). Ну і, нарешті, найочевидніша і найсумніша дірка в безпеці -- в різних репозиторіях є надто багато різної інформації, якої там просто не може бути. В master гілці якогось софта такого майже нема, в якихось integration чи qa гілках уже менше, але в dev branches.... Там і адмін паролі, набрані прямим текстом, і забуті (спеціально залишені) service backdoor'и типу, і просто прописана текстом PII різного роду. Я впевнений, навіть в найращих компаніях, з двома рівнями code review, розділенням engineering і QA, просто хорошими програмістами і чіткими процедурами, навіть там можна знайти щось з вищезазначеного. А оскільки більшість бізнесів у цьому світі далеко не такі, то у більшості бізнесів можна знайти не щось одне, а всі перечислені класи проблем.
no subject
Date: 2021-12-30 11:44 pm (UTC)Для того, щоб отримати доступ до нашого системного коду нічого не треба ламати. Наприклад, Titus та Zuul лежать просто у вільному доступі. Заходь на гітхаб і качай.
Минулого року хакнули приватне репо майкрософту на гітахбі і що? а нічого. Ну знаєш ти, що є такий код і така дірка в ньому - і що далі? Доступа до environment'а в тебе нема, і не буде, бо критичні enviroments як раз і проєктуються з розрахунком на те, що в них будуть деплоїти неідеальний код.
А якщо в твоїй thread model є серйозні загрози, то (а) дірки в коді вони знайдуть навіть без доступа до сирців - просто по непрямим ознакам, (б) захист коду - це дуже вторинне. Бо якщо треба, то серйозні люди просто прийдуть в гості до твоїх SRE, завербують їх чи просто приставлять пістолет до голови (і тоді починати треба з фізичного захисту персоналу).
Часто, до речі, це є анті-паттерном. Є ситуації де це має сенс, але в більшості випадків від цього більше шкоди, ніж користі.
no subject
Date: 2021-12-31 01:28 am (UTC)Вона не "побудована" на obscurity, просто багато де "так склалося". Ну от, нема хорошої продуманої security моделі, але все якось працює, то і добре.
> ... хакнули приватне репо майкрософту на гітахбі і що? ...
і то, що можна гадати, яка кількість дірок в майкрософтівських кодах і/або сервісах, які експлуатували після цього інциденту досі і експлуатуватимуть в майбутньому, була знайдена чи зроблена в результаті цього хаку.
> (а) дірки в коді вони знайдуть навіть без доступа до сирців - просто по непрямим ознакам, (б) захист коду -
> це дуже вторинне. Бо якщо треба, то серйозні люди просто ....
Це все правда, але:
(a) захист власне коду -- лише один з аспектів, в репозиторія є багато всього іншого. Юзернейми/паролі, hash salt'и, порти/ReST-API-запроси для backdoor доступу, записані відкритим текстом в гілках розробників я не придумав, а бачив на власні очі. Не скажу, де і коли :)
(b) "серйозні люди" бувають. Тут як з замками/дверима, аналогія з захистом житла, яку ми недавно згадували, пасує ідеально. Від "серйозного" наїзду не врятують і металеві двері з десятком замків, бо серйозні люди, коли треба, зайдуть в твою хату чи квартиру разом з тобою. Але "серйозні люди" -- це лише частина можливих security-related проблем. Часто -- помітно менша частина. Від опортуністичного бомжа чи навіть боязливого злодія без конкретної наводки замок на міцніших дверях допоможе. Так і тут: значна частина проблем значної частини корпорацій йде не від серйозних людей, a від дрібніших шахраїв, які вичисляють ту чи іншу діру в системі, і потрохи її доять. Але це "потрохи" додається достатньо, щоби втрати ставали відчутчими. В результаті, шукаєш зовнішні сервіси, які будудь тебе берегти. Я в одному з таких сервісів якраз і працюю зараз: клієнт приходить, каже, що його обкрадають, ми дивимося, що можемо зробити, описуємо наші можливості і виставляємо цінник. Після чого якісь клієнти платять нам, якісь вирішують самі себе ремонтувати/охороняти, а якісь вирішують, що ті півмільйона на рік, які в ник крадуть через цю дірку, дешевше продовжувати платити, ніж хоч щось міняти. Я бачив усі три сценарії. Так от, в цьому смислі, security by obscurity працює, ще й як. Кількість онлайн шахрайства, якє стається навколо, просто неймовірна. Я собі навіть не уявляв! Але поки про ту чи іншу діру знають лише кілька зловмисників, ніхто не чухається. А коли і чухається, то дуже трошки. Оптимізують не TTF чи TTR, а EBITDAthisquarter; максимум -- EBITDAthisyear.
(c) не "по ознакам" а "за ознаками"
> Є ситуації де це має сенс, але в більшості випадків ...
Ця "більшість", вона у твоїх спостереженнях, чи за якимись об'єктивними вимірами? Я, як ти знаєш, в індустрії відносно недавно, не претендую, що бачив багато різноманітного софтверного продукту. Тобто, за останній рік з гаком бачив багатенько чужих проблем, але чужий код не читав, хоча часом можна було здогататися, звідки в коді ростуть ноги них проблем. Але навіть в тих трьох місцях, де я працював, спущена зверху всякими просвітленими менеджерами і cost-saving віцепрезидентами мантра "be your own QA" була абсолютно, категорично неправильною. Словом, не маю причин сумніватися, що можливі сценарії, де це працює, але я особисто таких сценаріїв не бачив :) Напевне, я бачив меншість.
Думаю (знову вбрав капітанську шапку), все залежить від області, де ти працюєш. Я стикався, переважно, з різного роду Data Product кодом (ETL / ML / visualizations) різних областей. Плюс, пару років працював в команді, яка, власне, розробляла збір логів в мережах (WAN), то бачив і власне log generation/transmission/processing/storage код, і весь код командування мережею. З тих пір і не можу позбутися глибинного цинізму стосовно всього, зв'язаного з мережами і просто комп'ютерами. Шукаю луддитів-однодумців :)))))
no subject
Date: 2021-12-31 02:15 am (UTC)Так ця мантра і є неправильною. Якщо просто говорити "be your own QA" і більше нічого не робити - то краще не буде, а буде гірше. Але і розподіляти "тут QA, а тут developers" - це теж гірше. Це ж не дихотомія. :)
Для типової розробки я б починав з CI. CD - це набагато важче, але в плані deployment цілком реальна мета - 1-3 деплоймента за добу, не більше 6 годин від коміту до продакшена, в ідеалі - не більше години. Теоретично це можно робити і з окремими QA, але на практиці від підходу "окремі команди перекидають код через паркан" доводиться відмовлятися.
Але це не значить, що ролі QA чи SRE зникають. Вони просто починають виконувати зовсім інші функції.
Контрприклади/edge cases:
* година до продакшену не завжди значить година до кінця деплойменту
* коли галузь технічно унеможливлює швидкі зміни (наприклад, firmware development, де прошивку в чипах не можна змінювати "просто так") - то потрібні інші підходи.
За вимірами. Якщо цікаво - можеш почати з Accelerate, це seminal work. (Там і про тестування, і про infosec є.) Якщо зайде - подивись на щорічні DORA reports.
І я б розрізняв "більшість випадків, які існують" та "більшість випадків, де та чи інша практика є доречною" - це множини, які слабо перетинаються, хоч про дієти мова, хоч про інфосек.
no subject
Date: 2021-12-31 02:37 am (UTC)На цьому можна зупинитися - це саме по собі яскравий antipattern, який вказує на існування більш суворіших antipatterns.
no subject
Date: 2021-12-31 05:13 am (UTC)Насправді, майкрософт доволі прозора в цьому плані корпорація, але то лірика.
Головне в тому, що ми можемо оцінити, як цій хак вплинув на БІЗНЕС майкрософту.
no subject
Date: 2021-12-31 07:45 am (UTC)Або я не розумію твоєї логіки, або ти якось виключно вузько сприйняв мою фразу прро "чекаю, коли хтось зламає гітхаб з бітбакетом" і доказуєш мені щось своє. Бо мені байдуже, як відіб'ється на самих бізнесах поширення їхнього коду. Проблеми від того, що хтось зламає гітхаб з бітбакетом це не проблеми того чи іншого бізнесу, це проблеми усіх. Дірки, які знайдуть в великих софтинах -- фігня. Вірніше, не лише фігня, їх будуть експлуатувати, але їх і так експлуатують, хай трішечки менше. Великі репозиторії -- це софт тисяч дрібніших бізнесів всяких ретейлерів, банків, телефонних провайдерів, виробників еппів, державних установ і т. п...., а ще сотень b2b компаній, які працюють з усіма цими ретейлерами, банками і т. п. і "чисто випадково" мають купу даних їхніх клієнтів. Людські імена, адреси, кредитки, явки, паролі, вотетовотвсьо.
no subject
Date: 2021-12-31 05:58 pm (UTC)Якихось помітних хаків Майкрософта завдяки цьому ліку не відбулося - і тут це можна міряти хоч впливом на бізнес, хоч Post Incident Reports, які Майкрософт регулярно друкує (це дуже прозора компанія, це вже не та evil corporation, якою ми її пам'ятаємо з 90-х).
А якщо хтось переймається за бізнес дрібних компаній, в яких нема адекватних сек'юріти практик - то я повторююсь, що їх і так хакають серйозні люди регулярно, навіть не докладаючи до того зусиль, чисто автоматично. (Я не жартую - більшість хаків реально автоматизована.)
І саме тому зайвий доступ до сорців ситуації суттево не змінить.
no subject
Date: 2021-12-31 08:08 pm (UTC)Чорт його знає. Я знаю, чому і як такі хаки можуть бути проблемними, знаю, що доступ до репозиторії охороняють, але, можливо, роблю неправильні висновки. Можливо, жоден з тих експойтів, які використовують, щоби красти і шахрувати, почався не від викрадення чужого коду. Так що, вважай, переконав.
> А якщо хтось переймається за бізнес дрібних компаній, в яких нема адекватних сек'юріти практик - то я повторююсь,
> що їх і так хакають серйозні люди регулярно, навіть не докладаючи до того зусиль, чисто автоматично.
> (Я не жартую - більшість хаків реально автоматизована.)
Tell me about it. Кажу ж, я зараз працюю в одній з топ компаній з боротьби з онлайн шахрайством, високо сиджу, далеко бачу :)) Всякі боти -- важлива компонента, хоча, як не дивно, не єдина. В шахрайстві ж що головне? Правильно, монетизація. А монетизацією займаються частіше таки люди.
> До речі, імена, адреси, SSN - це вже публічна інформація. Ховати її - це security theater.
If you say so, можеш свої публікувати на головній сторінці, я свої не буду :) Насправді, цю інформацію треба ховати навіть якщо серйозні люди уже все давно мають. Тому що зараз лише цей security theater дозволяє якось обмежувати масове крадівництво, і недаремно всякі організації, державні і приватні, платять грубі гроші, щоби ці крадіжки обмежити... Одним з найефективніших (з тих, що нині деплойнуті в реалі) методів обмежити один з видів цих крадіжок є відслідковування певних аспектів процесу перевірки актуальньності цеї "публічної" інформації. Якщо у шахрая буде точна, незабруднена шумом і фейками, інформація про імена, адреси і SSN конкретних людей, то цей метод перестане працювати.
> А проблема кредиток та рахунків - це проблема не сорців, це проблема доступу до середовища та інших security практик.
А дірки в доступі до середовища можна побачиги в сорсах. Хоча, цілком можливо, що група шахраїв, яка експлуатує цю дірку, вичитала його не в краденому коді, а задіяла одного з девелоперів зсередини. Не пам'ятаю, чи в одному к коментів тут, чи в якомусь з недавніх постів я описував реальний випадок ongoing fraud'а в величезній організації, на якому втрачаються мільйони (якщо не десятки мільйонів) доларів щороку, і який став можливим через то, що хтось добре розібрався в джаваскріпті на вебсайті організації. Ми не знаємо, чи ця група вичислила це методом тика, чи вкрала код, чи там є інсайдер, але крадуть саме через діру в коді. Навіть не так діру, як поганонаписаність.
no subject
Date: 2021-12-31 08:40 pm (UTC)А ось тут не погоджусь. Якось обмежувати масові крадіжки дозволяє не лише те, що ніхто не знає мого SSN - як раз навпаки, його всі, в кого є бажання та декілька десятків доларів ВЖЕ знають (привіт Experian з його "традиційними" практиками: окремими QA, code freezes і іншою фігнею з 90х).
Масові крадіжки дозволяє обмежувати цілий комплекс засобів: починаючи з 2FA, продовжуючи автоматизованим fraud detection і закінчуючи жорсткими обмеженнями на максимальну суму операції/кількість операцій (limiting the blast radius).
Ем, ми про різні речі.
Якщо, напр ти бачиш в сорцах, що там є умовний бекдор, яких слухає на порту 4444 - але цій порт не просто закритий - доступ до нього можна отримати тільки on-premises, з 2FA при логіні і перевіркою фото в айді охоронцем, то можна з високою впевненістю казати, що
(а) лівому дрібному чорту це не дасть аж нічого,
(б) серйозні люди давно вже той доступ отримали.
А якщо доступ до цього порту може отримати кожен бажаючий, то можна гарантувати, що все ВЖЕ зламане. (і зайвої шкоди вже не буде, бо вона ВЖЕ трапилася, хехе)
no subject
Date: 2021-12-31 08:53 pm (UTC)Якщо ти про той випадок, який я пам'ятаю - то там ніби то діра була в тому, що був дозволений brute force без rate limiting та exponential backoffs.
(А джаваскріпт на вебсайті красти не треба - F12 натиснув, і ти його бачиш, і навіть обфускація погано допомагає.)
no subject
Date: 2021-12-31 10:54 pm (UTC)no subject
Date: 2021-12-31 06:04 pm (UTC)До речі, імена, адреси, SSN - це вже публічна інформація. Ховати її - це security theater.
А проблема кредиток та рахунків - це проблема не сорців, це проблема доступу до середовища та інших security практик. Якщо хтось дає публічний доступ (в сенсі - можливість публічного доступу просто з потрібним паролем) до середовища, де можна отримати цю інформацію, то можна вважати, що ця інформація вже зламана, і тут доступ до сирців знову ж ситуацію суттєво не змінює.