1. Які загрози таїть швидке виведення нових продуктів на ринок, безглузді помилився розробників, здатні...
2. ненавмисний шкоду
3. Buffer overflow
4. Небезпечні зв'язки
5. Готовність до стандартів, праці і оборони
6. Слабка ланка
7. Чому засилля connected (без потреби) пристроїв - це проблема?
8. висновки

Які загрози таїть швидке виведення нових продуктів на ринок, безглузді помилився розробників, здатні підставити під удар будь-яку систему, і чому насправді виробники постачають чайники Wi-Fi-модулем.

Кодіть, забувши про небезпеку

Зараз одна з великих проблем в тому, що у більшості розробників немає адекватної підготовки в області інформаційної безпеки. Йдеться про відсутність не якихось глибоких і професійних, а базових знань. Програмісти отримують завдання створити нову цікаву штуку і роблять її. При цьому вони запросто можуть не побачити в результатах роботи можливі напрямки атаки - вони просто не в змозі зрозуміти, як їх дії самі по собі створюють загрози.

Причина лежить в області загальної професійної культури. Один з ключових принципів безпеки полягає в тому, що захист не можна прибити на готовий продукт, зробивши його секьюрним. Наприклад, не можна усвідомлено робити систему кривої і дірявої, просто тому що ця система внутрішня і доступна буде тільки в інтранеті, де ніяких погроз не очікується. Практика показує, що, по-перше, можуть знайтися і внутрішні атакерів, а по-друге, з дуже великою ймовірністю, рано чи пізно до цієї системи буде потрібно доступ ззовні. Її виставлять у публічний інтернет, і все пропало.

ненавмисний шкоду

Айзек Азімов сформулював три закони робототехніки, перший з яких говорить: «Робот не може заподіяти шкоду людині або своєю бездіяльністю допустити, щоб людині було завдано шкоди». Але сам же в романі «Оголене сонце» писав і про недосконалість цих законів: вони не захищають від ненавмисного шкоди - якщо один робот приготує отрута і поставить його в певне місце, а інший просто віднесе стакан з напоєм господареві, не знаючи про вміст, удвох вони цілком можуть скоїти вбивство. Навіть незважаючи на те, що кожен з них окремо має фундаментальний заборону на це.

Класичний приклад такого дуету в IT - винос недостатньо захищеного сервісу в публічний інтернет. Розробник, який цей сервіс написав, усвідомлював, що той, можливо, захищений досить примітивно, але він також знав, що це внутрішній сервіс, він знаходиться у відносно безпечною мережі, недоступний «зовні». Проблема в тому, що своє знання про можливі проблеми з безпекою він нікому не передав, а в через якийсь час нове завдання отримав вже інша людина. Наприклад, компанія, в якій сервіс зробили, почала аутсорсити частина роботи, і доступ до системи потрібен працівникам ззовні. І ось уже сервер промацують сотні скриптів, які шукають уразливості, робиться brute-force підбір паролів, які для маленького внутрішнього сервісу, швидше за все, прості, напевно й тестові акаунти залишилися, та й SSH-сервер без сек'юріті-патчів за два роки.

Хто тут самий винуватий? Здоровий глузд підказує, що той, хто виставив сервіс в інтернет - він не забезпечив його належний захист. Але ж він міг і не знати, що там є аккаунт «admin» з паролем «test» або що за певним URL розробник залишив сторінку діагностики, яка взагалі не захищена паролем. Якби перший розробник не економив на безпеки і робив систему «як для ворогів» - може бути, багатьох проблем можна було б уникнути. Саме тому турбота про безпеку повинна починатися з першого дня - це те, що називається «security in depth».

Про такі речі замислюється мало, зазвичай програмісти в своїх діях просто не бачать «security implications». Чи не тому, що вони дурні або ліниві, просто їм ніколи не доводилося мати з цим справу. Ось аналогія - джуніор написав якийсь фрагмент програми, два дня його вилизував і тестував, він упевнений, що тепер в ньому все ідеально. При цьому синьйору досить одного погляду, щоб побачити баг в цьому коді. Йому не потрібно щось тестувати і перевіряти - він просто відразу може сказати: «Ось тут при таких-то умовах воно зламається». Можна сказати, що «нейронна мережа» досвідченого розробника набагато краще натренована в цій предметній області і якісь патерни він просто «бачить». Миттєво, не замислюючись. При цьому той же самий досвідчений розробник сам може в упор не помітити величезну діру в безпеці, яку він тільки що створив. Його «нейронна мережа» відмінно натренована, але вона натренована на інші речі, він просто «не бачить» проблему. Якщо її показати, він все зрозуміє, часто з півслова, але сам він вразливість прогавив.

Існує окрема дисципліна Threat modeling, яка дозволяє прогнозувати загрози і напрямки можливої ​​атаки, а також визначати цінність даних, які ви при цьому ризикуєте втратити. Її можна викладати не тільки стосовно IT, але програмісти точно повинні отримувати концептуальне уявлення про неї в базовому комплекті знань. Також абсолютно необхідно, щоб розробники знали типові дірки. Вони повинні бути в курсі, якими бувають помилки і як потім за рахунок них інші люди зламують системи.

Buffer overflow

Я припускаю, більшість розробників знають, що таке buffer overflow і чому, коли пишеш на мові C, не можна використовувати функції стандартної бібліотеки, які форматують рядок, не обмежуючи її довжину. Просто тому що в сервісі з відкритою реєстрацією який-небудь користувач спробує створити собі ім'я такої довжини, яка переповнить буфер і змусить процесор виконувати вже не ваші, а його команди. Це тема, здавалося б, заїжджена. Про цю проблему відомо десятки років, але на GitHub і зараз можна знайти який-небудь свіжий opensource-проект, в якому першою ж рядком буде форматування тексту в якого не встановлено довжині буфер, де в якості параметрів використовується інформація «out of control of the application , т. е. отримана від користувача.

Мені здається, індустрія вже втратила надію, що розробники колись навчаться захищатися від buffer overflow. Тому основний рух було в сторону того, щоб зробити його неможливим - апаратний захист від виконання стека або зовсім відсутність прямого доступу до пам'яті в високорівневих мовах. Але хоч мову C неухильно втрачає популярність, він поки сильний і як і раніше майже безальтернативний для вбудованих пристроїв і IoT, оскільки на слабенький процесор нічого більше не заштовхаєш.

У Java таке слабке місце, як buffer overflow, відсутній як клас. Але яким би не був мову, не складає труднощів накодо на ньому якусь класичну діру. Скажімо, на кшталт сервера, що повертає файл з upload-каталогу по його імені, де виявиться, що в імені можна передати ../../ .. і вийти за межі upload-каталогу. Подібні проблеми відомі багато років, і в 2018 році не повинно бути жодної програми, яка дозволяє цим скористатися. Але вони продовжують з'являтися.

Саме тому мені здається важливо навчати розробників безпеки. І найголовніше, напевно, це як раз розповідати їм про "небезпеки" »- як зазвичай зламуються системи. Тільки з цим набором знань вони починають бачити проблеми в своєму коді.

Небезпечні зв'язки

Інтернет речей - термін дуже загальний, його можна застосувати до будь-якої колекції пристроїв, які Коннект один з одним. У всякому разі, про це часто говорять саме так, хоча на практиці все розумні датчики і прилади, які ти купуєш і встановлюєш у себе вдома, зв'язуються зовсім не між собою, а з хмарної інфраструктурою. Саме туди вони відправляють звіти про свій стан, саме звідти отримують команди. Якщо у тебе вдома є пристрої різних виробників, швидше за все, інформація з твого будинку відправляється в хмару кожного з них. Тобто розумний будинок розсилає велику кількість інформації, наприклад, за чотирма адресами. А ти навіть не замислюєшся, що і кому він репорт (відмінну статтю про це можна прочитати на Gizmodo ).

Ніхто не хвилюється, тому що цими даними люди не дорожать. Кому є діло до рівня вологості в спальні, наявності накипу у вашій кавоварці, улюбленої вами температурі води або часу включення лампочок у вітальні? Але останнє, як мінімум, повідомляє зацікавленій особі, коли ви буваєте вдома. Якщо темно стає о шостій годині вечора, а світло включається в сім, можна з великою часткою ймовірності розраховувати, що до семи ви не з'явитеся. Нещодавно був прекрасний скандал з вібраторами, якими чомусь можна було управляти через iOS-додаток. Виявилося, про всі режимах використання вони повідомляли виробнику (зрозуміло, для поліпшення якості сервісу). Ось вже, здається, інформація з дуже низькою цінністю, але користувачам таке спостереження за їх звичками категорично не сподобалося.

Аналіз інформації з різних пристроїв може дати досить повну картину вашого життя. І, звичайно, не думаю, що всім пристроям потрібен вихід в інтернет. Наприклад, я зовсім не хочу, щоб моя газова колонка раптово включилася, отримавши команду з хмари.

Готовність до стандартів, праці і оборони

Здорово, якщо розумна лампочка, яку ти купив, відразу інтегрується з розумним будинком. Але з великою ймовірністю вона реалізує якийсь запатентований виробником власний «стандарт» і працює тільки зі своїм додатком. Теоретично тобі б могло знадобитися десять додатків, щоб регулювати лампочки від різних виробників. Apple, Google, Amazon намагаються ввести стандартний API для управління будинком, при використанні якого тобі взагалі не важливо, як саме реалізовано конкретний пристрій. Яке-небудь додаток від Amazon може керувати будь-яким з них, зрозуміти його тип і успішно виконувати функції інтерфейсу між користувачем і хмарою.

У IoT особливо яскраво проявляється прагнення якомога швидше вивести на ринок новітнє геніальне пристрій. Тому питання стандартів виявляється вторинний - якщо додаток може управляти пристроєм, виробник вже щасливий. Пізніше на нього починають збоку прикручувати, наприклад, інтеграцію з Amazon Alexa, щоб їм можна було управляти голосом. Але це вже приклад after thought (думки навздогін).

Імплементувати стандарти з самого початку було б простіше, але чи завжди виробники в цьому зацікавлені? Можливо, деякі вендори якраз і хочуть, щоб їх пристрої відправляли інформацію саме в їх же власне хмара, звідки вони зможуть її отримати і проаналізувати. Наприклад, якщо компанія поставляє термостати, дуже цікаво зібрати статистику, коли користувачі їх включають і вимикають, яку температуру вважають оптимальною. Це дозволить оцінити картину по окремих регіонах і виділити основні типи користувачів, яких напевно виявиться небагато. Звичний для кожного з них режим можна пропонувати разом з термостатом у вигляді preset зі зрозумілими назвами: «офісний співробітник», «фрілансер» і т. Д. В результаті клієнти зможуть заощадити час, а можливо, і гроші (якщо preset йде з особливим тарифним планом на електрику), просто упізнавши себе в одному з типів.

Слабка ланка

Виробники побутової техніки тепер намагаються вивести в інтернет будь-який новий прилад. Я з великим подивом дізнався, що мікросхема ESP32 (є ще і більш ранні варіанти, в тому числі ESP8266) коштує менше долара. Вона позиціонується як «system on chip with integrated Wi-Fi» - в принципі, це маленький процесор з вбудованою пам'яттю і Wi-Fi-модулем. Коштує копійки, та й розміром теж з монету. Яка спокуса для виробника мікрохвильовій печі увіткнути в неї таку штуку! А скільки можливостей для праски!

Ніяку певну мету вони можуть при цьому і не переслідувати, скоріше, промацувати грунт. Тут можна згадати історію з Apple watch - я практично впевнений, що на момент випуску першого пристрою ніхто не знав, яка з його можливостей вистрілить. Apple бив з дробовика в усіх напрямках відразу: і тобі ідентифікація, і contactless payments, і фичи для спорту - і то, і це, все, що приходить в голову. До третього Apple watch у них напевно зібралася якась статистика використання пристрою і розуміння його користувачів. Тому презентація третьої моделі вже виглядає набагато більше як презентація спортивного аксесуара, ніж чогось іншого. Думаю, виробники побутової техніки роблять те ж саме, намагаючись подивитися на реакцію користувачів.

Навіщо пральній машині вихід в інтернет? Я бачу тільки один резон: вона зможе сама себе діагностувати і повідомити в сервісну службу про те, що скоро зламається. Це, можливо, корисно. Але виробник розповість про мільйон інших безсумнівно необхідних речей, які можна робити з connected пральки - звичайно ж, її можна дистанційно запустити з телефону (здрастуй, ще один додаток).

Чому засилля connected (без потреби) пристроїв - це проблема?

Кавоварка теж може сходити в інтернет, щоб дізнатися свіжі ціни на каву або курси валют. І хоча вона не може розповісти про тебе дуже багато чого, крім, мабуть, режиму власника, з нею може виникнути інша проблема: «Ланцюг настільки міцна, наскільки міцним виявиться її найслабша ланка». Я маю на увазі, якщо ваша кавоварка буде зламана, під ударом опиняться ще 25 ваших unhackable пристроїв. Той, хто зуміє зламати будь-яку побутову техніку, підключену до вашої мережі, за великим рахунком увійде до вас додому і зможе там розгулятися. Таке вже було , Правда, не з кавоваркою, а з чайником. Його виробник використовував чіп з вбудованим Wi-Fi, який підтримував TELNET з дефолтних паролем. А зайшовши в чайник, через пару команд можна було отримати Wi-Fi-ключ. У загальному і цілому, чим більше різних пристроїв в будинку, тим більше того, що називається attack surface - потенційних місць для атаки.

Наприклад, у якогось пристрою може бути механізм, що має на увазі автоматичний трансфер даних конфігурації. Якщо одне з них вийде з ладу і буде замінено новим, перше просто передасть дані про локальний оточенні: ключі, паролі, а нове не потрібно буде болісно конфігурувати. Але, якщо в цей механізм є дірки, що проходить під вікном людина зможе змусити пристрій передати ці дані і йому. Проблема в тому, що користувач, як правило, поняття не має, на що здатне його пристрій. У нього може бути всього одна кнопка, воно може не вміти нічого розумного, і common sense підказує нам, що і загрози воно представляти не повинно. А уявіть, що воно приймає команди по Bluetooth, і в нього забули відключити режим діагностики ... А чи завжди ви готові довіряти результатам security testing виробників побутової техніки? Та й чи була вона?

висновки

Навряд чи розумні холодильники будуть служити нас найближчим часом (за кавоварку не ручуся). Але от позбутися всіх паролів можна по милості самого примітивного датчика, встановленого у вашій квартирі. Паралельно з проблемою security, існує пов'язана, але не тотожна їй, проблема privacy. Розумні будинки спостерігають за своїми власниками, в кінці кінців збір інформації - одна з основних функцій пристроїв, з яких ці системи складаються. Якщо дані в результаті виявляються не в тих руках, спостереження автоматично перетворюється в шпигунство.

Звичайно, користувач сам вирішує, чи потрібні йому чайник і зубна щітка з виходом в інтернет. Але в першу чергу, замислюватися про потенційні загрози слід тим, хто створює програми. Постійна оцінка можливих загроз на рівні вашого власного шматка робота - не параноя, а важлива частина професійної культури. У всякому разі, я сподіваюся, що вона такою стане.