Spectre & Meltdown: покрокове пояснення

Оригінал: https://twitter.com/gsuberland/status/948907452786933762

Інтро

Коли процесор доходить до умовного розгалуження у коді (наприклад, “if”), він намагається передбачити, яку гілку буде обрано в програмі, перш ніж програма сама взнає результат. І він виконує цю гілку заздалегідь — ця функція процесора називається “спекулятивне виконання”.

Ідея полягає в тому, що якщо процесор правильно “вгадає” вибір програми (що усі сучасні процесори роблять досить добре), він вже виконає наступний біт коду до того часу, коли фактично стане відома обрана гілка. Якщо процесор помилиться, виконання “відкотиться” назад і почне виконання правильної гілки.

Що робить процесори такими успішними в прогнозуванні умовного вибору програм, — це збереження даних про попередні операції розгалуження в так званому Буфері історії розгалужень (Branch History Buffer, BHB). По принципу: якщо певна програма обирала шлях A раніше, вона, ймовірно, обере шлях А знову, замість шляху Б, який вона ще не обирала.

Цікаво, що код виконується “спекулятивно”, до того, як результат умовного розгалуження буде завершено. Це умовне розгалуження може бути критично важливим для безпеки. На щастя, процесори (в основному) досить розумні, щоб “відкотити” назад будь-які побічні ефекти спекулятивного виконання.

Але існує два важливих винятки з цього “відкочування” побічних ефектів: кеш пам’яті та сама історія розгалужень (BHB). Ці дані, як правило, не відкочуються назад, оскільки спекулятивне виконання має на меті збільшення продуктивності процесора, а відкочування кеш-пам’яті та вмісту BHB, шкодить продуктивності.

Існує три способи експлуатації цієї поведінки. У документі Spectre описано перші дві експлойти з наступними результатами:

  1. Розкриття пам’яті ядра користувацькому процесу на “залізі”.
  2. Розкриття пам’яті ядра хоста віртуальної машини (гіпервізора) процесу в “ядрі” віртуальної машини.

Атака #1

Перший експлойт працює, змушуючи ядро виконати деякий ретельно підготовлений зловмисником код, який містить перевірку обмежень масиву, а потім читає цей масив, причому індекс читання контролюється зловмисником. Це звучить як зухвала ідея, але це не так завдяки JIT (Just in Time compiling).

В Linux, Extended Berkley Packet Filter (eBPF) дозволяє користувачам записувати фільтри сокетів з режиму користувача, які компілюються ядром JIT, щоб ефективно фільтрувати пакети на сокеті. Подробиці неважливі, але це означає, що зловмисник може виконати код на рівні ядра.

Експлойт передбачає написання коду eBPF, який виконує наступні кроки:

  1. Виділяє два масиви фіксованого розміру
  2. Перевіряє наданий користувачем індекс на входження в масив 1
  3. Якщо все ОК, здійснює читання масиву 1 по цьому індексу
  4. Обчислює другий індекс з одного біту отриманого результату
  5. Читайте по другому індексу з масиву 2

Насправді, є ще один крок 4.5, який здійснює граничну перевірку другого індексу по читанню, але ми не маємо наміру робити читання за рамками масиву 2, тому це не має значення.

З точки зору “реального” виконання, цей код завжди обривається на кроці 2, коли/якщо користувач передає індекс за межами масиву 1. Але якщо процесор-“провидець” припускає, що перевірка буде успішною, він спекулятивно виконає читання з-поза меж архіву на кроці 3, та продовжить виконання аж до кроку 5.

Ось що прикольно. На кроці 4 ми беремо значення, яке ми отримали читанням з-поза меж масиву (куди ми, як правило, не маємо доступу), і використовуємо один біт (b) від нього, щоб вибрати конкретну адресу пам’яті (індекс масиву) для читання. Якщо b = 0, то читаємо індекс 0x200; якщо b = 1, то читаємо індекс 0x300.

Це гарантує, що пам’ять, на яку вказує індекс 0x200 або індекс 0x300 буде закешована. Коли процесор усвідомлює, що перевірка обмежень на кроці 2 провалилася, він “відкочується” назад до цього розгалуження, щоб продовжити виконання правильної гілки. Однак дані з кроку 5 все ще знаходяться в кеші!

Потім ми можемо піти й прочитати дані в 0x200 та 0x300 та пересвідчитися, що вони кешуються, вимірюючи швидкість читання. Щойно ми взнаємо, який індекс було закешовано, ми можемо безпосередньо визначити один біт з пам’яті ядра, виходячи з вибору індексу на кроці 4.

Є деякі деталі щодо того, як необхідно підготувати кеш перед цією атакою, але всі ці речі можна проробити у циклі в процесі непривілейованого користувача, щоб здійснити повний дамп пам’яті ядра.

Атака #2

Друга атака, описана в статті Spectre, передбачає “отруєння” історії прогнозування розгалужень, щоб змусити процесор спекулятивно виконати код за адресою, визначеною зловмисником, що призведе до подальших атак на кеш, які описані вище.

Виконавши ретельно відібрану послідовність непрямих переходів (indirect jumps), зловмисник може заповнити історію прогнозування розгалужень таким чином, що він зможе вибирати, яку гілку буде спекулятивно виконано під час виконанні непрямого переходу.

Це може бути дуже круто. Якщо я знаю, що в коді ядра є фрагмент коду, який демонструє поведінку, подібну до нашого прикладу з eBPF вище, і я знаю, яка в цього коду адреса, я можу непрямо перейти до цього коду, і процесор спекулятивно виконає його.

Якщо ви маєте досвід експлуатації вразливостей такого класу, ви, ймовірно, впізнаєте в цьому дещо подібне до ROP-гаджета (Return-Oriented Programming gadget). Ми шукаємо послідовність коду в просторі ядра, що має правильну послідовність інструкцій, щоб отримати витік інформації через кеш.

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

Ви також помітите, що нам потрібно знати адресу цільового коду ядра. З KASLR (Kernel Address Space Layout Randomization) це не так просто. Цей блог Project Zero пояснює, як можна перемогти KASLR, використовуючи прогнозування розгалужень та кешування як побічний канал, тому я не буду вдаватися до опису деталей: https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html

Надзвичайно круто те, що це працює поза межами віртуальних машин. Замість традиційного непрямого переходу (наприклад, jmp eax) ми можемо використовувати команду vmcall, щоб спекулятивно виконувати код в ядрі хоста VM (гіпервізору) таким же чином, як і в ядрі нашої ​​VM.

Атака #3

Нарешті, є третій підхід. Він передбачає атаку очищення та перезавантаження (flush + reload) кешу на пам’ять ядра, подібну до першого варіанту атаки, але не вимагає виконання коду в ядрі — все це можна зробити в режимі користувача.

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

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

Отже, якщо ви можете “обігнати” переривання, ви можете спекулятивно виконати якусь іншу інструкцію, яка завантажує дані в кеш на основі значення, прочитаного з пам’яті ядра. Тепер це стає кеш-атакою, подібною до попередніх трюків.

Власне, це все.

Для повної інформації я рекомендую прочитати ці два документи, а також пости Project Zero, вказані вище.

https://spectreattack.com/spectre.pdf

https://meltdownattack.com/meltdown.pdf

Від себе: #бережіться 🙂


Originally published at blog.styran.com on January 5, 2018.

Хто є хто на ринку кібер-безпеки

Ринок кібер-безпеки, який, за деякими оцінками, наступного року перестрибне об’єм 200 млрд на рік, для більшості населення планети залишається якоюсь містичною таємницею. Коли я спілкуюся на робочі теми з людьми, які не є інсайдерами цієї індустрії, мені нерідко доводиться розвінчувати стереотипи та відверту оману. Тому я спробую підсумувати найбільш популярні міфи про кібер-безпеку як галузь у цьому невеличкому пості.

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

Більше того, кібер-безпека це настільки різнопланова та мінлива галузь, що коли у 2013 році у Національній академії США підняли питання про формалізацію професії із аналогічною назвою, причому не просто так, а на запит Департаменту внутрішньої безпеки (DHS), призначена комісія відповіла відмовою. Аргументувалося це рішення в основному тим, що область знань кібер-безпеки змінюється та розвивається настільки динамічно, що стандартизувати її у вигляді якоїсь статичної професії наразі було б контрпродуктивно.

Продовжуємо. Для багатьох є новиною той факт, що більшість компаній, які надають послуги або розробляють товари з кібер-безпеки, не є зосередженими на цій галузі. Більше того, безпека продуктів та сервісів не є їхнім головним пріоритетом. Це звучить контр-інтуїтивно, але так і є: основні гравці на цьому ринку — це не ІБ-, а ІТ-компанії, які “за інерцією” вийшли на ринок безпеки, користуючись напрацьованими бізнес-стосунками з вже існуючими клієнтами.

Далі, багато хто знає про існування різних інструментів побудови організаційної безпеки, таких як міжнародні та галузеві стандарти, та вважає, що за абревіатурами ISO27001, PCI DSS, HIPAA та GDPR стоять містичні сили, які якимось чином впливають на вимоги безпеки, що компанії застосовують до своїх систем та процесів. Насправді, це не так. Єдина сила, яка рухає організаціями в напрямку захисту їхніх систем, це бюджет. Жодні фреймворки з управління ризиками та регуляторні акти не можуть змусити організацію витратити на безпеку більше, ніж вона собі може дозволити економічно. З іншого боку, ці фреймворки можуть допомогти їй більш ефективно витратити цей бюджет, але не більше.

Наступне, існує протилежна думка, що так званий комплаянс, тобто виконання норм зазначених вище стандартів та законів, не додає безпеки. Ця позиція культивується, зокрема, багатьма спеціалістами з кібер-безпеки та потрапляє в родючий ґрунт нонконформістськи налаштованих спеціалістів з ІТ. Але це невірно. Насправді, і PCI DSS, і GDPR, і навіть КСЗІ/НДТЗІ та інші страшні слова дуже навіть додають в безпеці менеджерам, які відповідають за їх додержання. Відповідність вимогам комплаянсу може позбавити їх серйозної політичної, адміністративної, а деколи навіть кримінальної відповідальності у випадку виникнення у організації гучного зламу чи іншого інциденту кібер-безпеки. Так що, комплаянс — це навіть дуже й дуже безпека, але треба пам’ятати чия і від кого.

Отже, не все так просто та одностайно в області кібер-безпеки. Ті, хто її продає, та навіть ті, хто її споживає, не завжди в ній зацікавлені. Хто ж насправді займається кібер-безпекою, поліпшує її рівень та розвиває її як галузь?

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

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

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

Власне, індустрія кібер-безпеки, тобто бізнеси, нон-профіти та спільноти, які займаються тим, що покращують безпеку, але при цьому, на відміну від вендорів “першого ешелону”, інтеграторів та дистриб’юторів не вважають її додатковим або неосновним видом діяльності. Це компанії, які будуються навколо сервісів, продуктів, або платформ, які зосереджені на безпеці ексклюзивно, тобто пішли ва банк з цією місією.

Дослідники безпеки. Це окрема каста, яка поділяється на криптографів, дослідників вразливостей, дослідників шкідливих програм тощо. Вони можуть діяти незалежно, або входити до підрозділів великих компаній, причому як постачальників так і споживачів безпеки. Причому на мій погляд споживачі тут відіграють набагато потужніше, візьмемо для прикладу Google, Netflix, Amazon або Facebook. Ці команди чи незалежні дослідники продукують звіти, результати та ПЗ з відкритим кодом, якого ви не дочекаєтесь від інших гравців на ринку.

Власне, це все, що я хотів вам повідомити про “легітимних” гравців на цьому ринку. Тепер ви знаєте в загальних рисах які тут двіжухи та з ким мені доводиться мати справу день у день.


Originally published at blog.styran.com on December 27, 2017.

Ще трохи про хакерів

Раз вже розпочали, то продовжуємо невеличкий лікнеп щодо того, хто є хто в нашій пісочниці.

По-перше, хакери та кібер-злочинці це різні поняття. Завдяки сталому голлівудському стереотипу та неосвіченості медійників, хакерами здебільшого називають людей, які здійснюють злочини з допомогою комп’ютерів та мереж. Це неправильно. Оригінальне значення слова “хакер” в комп’ютерному сенсі — це людина, яка докладає неабияких зусиль, знань та навичок задля розв’язання складної проблеми. Коли йдеться про безпеку, то узагальнити можна так: хакери вивчають системи та намагаються використати їх у спосіб, який не передбачався творцями цих систем. Отже, хакер — це комбінація експертних знань, наполегливості, та творчого підходу.

По-друге, хакери бувають не “білі” та “чорні”. Коли людей розрізняють по кольору, це називається расизм. Натомість, хакери “носять” різнокольорові капелюхи: білі, чорні та сірі. Розібратися хто є хто у цих капелюхах дуже просто. Вайтхети зламують системи легально та з етичних міркувань. Блекхети зламують системи нелегально та з неетичних міркувань. Грейхети — це буквально сіра зона, в якій дії диктуються міркуваннями етики, але не завжди і не скрізь вміщуються в рамки закону. Чому все ж таки різнокольорові капелюхи а не хакери? Тому що, зважаючи на ситуацію, контекст та настрій, одна і та сама людина може виконувати дії, які можуть бути або легальними (вдень на роботі здійснюючи пентест з прямого документального дозволу клієнта) або не дуже (вночі вдома аналізуючи вразливості у веб-сайтах держустанов). І капелюх для цього змінити набагато легше і дешевше, ніж колір шкіри.

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

Якось так. Тепер ви тут всіх знаєте. Бережіться

Про Responsible Disclosure, Full Disclosure, та чому хакери — це добре для кібербезпеки

та чому хакери — це добре для кібербезпеки

Багато хто звернув увагу на вакханалію розкриття вразливостей у системах Українських державних установ, органів самоврядування та підприємств критичної інфраструктури. Якщо ви провели останні тижні на сонячному пляжі або у темній печері, подивіться на крайні пости Sean Brian Townsend та увійдіть у курс справи. Після цього можете повертатися до цього поста.

Отже, хлопці відриваються в форматі Full Dosclosure: знаходять у системі вразливість та повідомляють про неї публічно. Реакція на таку поведінку в суспільстві неоднозначна: власники вразливих систем, звичайно, нервуються, та реагують в міру власної обізнаності з кібербезпеки. Обізнані втирають сльози, зчіпляють зуби, беруть себе в руки, та виправляють вразливість. Необізнані волають на весь інтернет “це провокація”. Зовсім новачки ще й погрожують хакерам у відповідь, очевидно не маючи жодного уявлення про те, що у нас типу свобода слова, а “злам” — це навмисне подолання заходів безпеки, яких у їхньому випадку тупо не існувало. Спеціалісти з безпеки, принаймні ті, хто не просто так називається, а ще й розбирається в темі, майже одностайні: це краще, ніж мовчати, але… Ось тут можуть бути варіанти.

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

В 90-ті, коли інтернет з’явився в усіх цивілізованих країнах, веб перетворився з академічного інструменту в комерційний, а хакінг став масовим захопленням технічно обізнаної молоді, оця сама молодь першою зрозуміла, що інтернет до неї не готовий. Хакери знаходили вразливості пачками, дехто використовував їх для розваг (перші мережеві та веб-черв’яки не були фінансово вмотивованими), дехто перейшов на темний бік та почав тупо рубати з цього бабло. Але вендори, тобто розробники та продавці програм та систем були майже одностайні: вам не слід шукати та використовувати вразливості в наших системах, або ми вас нафіг засудимо, бо у нас є юристи та лобі в конгресі, а у вас — ні. Хакери, як відомо, не дуже полюбляють таке ставлення, тому десь у ті роки з’явився такий собі список розсилки під назвою Full Disclosure, в який зливалися всі публічні звіти про вразливості, причому робилося це здебільшого анонімно.

Десь наприкінці 90’х, початку 2000’х, найбільш просунуті вендори зрозуміли, що стратегія заперечення проблеми відсутності безпеки в їхніх продуктах — не дуже ефективна. Зокрема, вихід Windows XP показав, що вразливості безпеки являють собою екзистенціальну загрозу компанії Microsoft. Адже коли протягом днів після релізу твого флагманського продукту в ньому знаходять вразливість виконання коду на відстані, яка легко перетворюється на мережевого черв’яка, це, м’яко кажучи, не дуже добре. І десь в районі 2002–2003 років Майкрософт, точніше Білл Гейтс, прийняв рішення щось з цим робити. І не самостійно, а з залученням у процес хакерів з таких легендарних команд, як L0pht Heavy Industries, Foundstone, Sysinternals тощо. Останню, до речі, вони зрештою придбали та зробили частиною компанії. Результатом цієї співпраці програмістів, які пишуть програми, та хакерів, які ці програми зламують, було утворення першої методології Secure Development Lifecycle (SDL) та зрештою — розробка першого більш-менш захищеного продукту компанії Microsoft — SQL Server 2005.

Всі ці зрушення призвели до того, що вендори (не всі) зрештою усвідомили (Oracle так і не усвідомив), що з хакерами потрібно співпрацювати. Але правила цієї співпраці вони встановили власноруч, не порадившись з хакерами. І придумали вони таку річ, як Responsible Disclosure, що означало, що першими про вразливість мають дізнаватися вендори, а хто так не робить — той безвідповідальний. І почався багаторічний holy war між прихильниками Responsible та Full Disclosure, який не припиняється й досі, і повірте мені: ані українська Кібер-поліція, ані Херсонська обласна рада не будуть останньою інстанцією у цих дебатах. Це глобальна дискусія, яка напевно триватиме вічно, тому що в Responsible Disclosure є свої вади, такі як гальмування реакції вендора, а Full Disclosure… а FD, — це FD 🙂

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

Бережіться

How to Build Security Awareness Programs That Don’t Suck

This is the script of my talk at BruCON 0x09. You can find the video here: https://www.youtube.com/watch?v=40tUy6TNXM8; the slides are here: https://files.brucon.org/2017/006_Vlad_Styran_Security_Awareness_v3.pdf.

Introduction

Hi everyone. Thanks for coming.

Before we begin, let me ask you a question. In your professional opinion, what is the weakest link in a security system? Louder please. OK, the human. Thank you.

But it seems that not all of us agree. Is it so? Alright, let’s do it this way: all of you please raise one hand. [Raise hand]. Come on, that’s not too hard, you can do it.

First, let’s spot the cheaters. Please, lower your hand if you have a degree in applied psychology, behavioral science, or anything similar. Thanks. Now, please, lower your hand if, in your professional opinion, and to the best of your knowledge, there is a component of security system, that is weaker and riskier than a human being. In other words, that human is not the weakest link. [Lower hand]. Okay, thank you. Now, please lower your hand, if you think, that the first and the most important thing that a company should do to protect itself is to train their staff.

Okay thank you very much! I think we’re ready to start.

The through line

So, what it’s all about? Besides getting you acquainted with Ukrainian accent, (which is basically Russian accent, but please don’t tell anyone I’ve told you that), today I’m going to tell you how I stopped blaming the user and found a way to change the human from “the weakest link” to a valuable security asset, and in some cases — to the strongest component of a security system.

The beginning

Let me start with a story that begins one bright morning in the fall of 2005, when a young IT guy arrived at the office of a small software engineering company, to find a surprising email from their ISP in his inbox. The email stated that the traffic from their corporate network was temporarily filtered by the TCP port 22 per an abuse report. That’s right, this young IT guy was me, and at that moment he was quite surprised. And by “surprised” I mean scared to death.

What followed next, was my first experience of digital forensic investigation. The logs, the integrity checks, the pcaps, the timeline: all the stuff that now sounds trivial, but was a lot of fun then. The track broke off on an outdated Linux server in central Ukraine, it was running long distance calls billing & their IT guys knew how to turn it on & off.

Then, I started to analyze my compromised box: RedHat 9, AKA “Shrike”, with 2.6 kernel, remember that? Although a bit old, it was still clean of any remotely exploitable vulns, so I was intrigued. Because in my world Linux was so secure, no one could hack into it. So, I did all the appropriate analysis, learning to do that along the way, and found out that at some point the malicious worm entered the OS by successfully guessing the root password. That’s how I met John the Ripper and attempted to crack that password. What do you think it was?

password123

After all these years, I see a history behind it: the guy apparently had some experience. I bet his first root account was protected by just ‘password’, then something surprising happened, and he started using password1, and so on.

Of course, after this fantastic adventure, I could not go back to my sysadmin life. So, this is how my career in InfoSec has started.

Through the next 5 years I’ve been working at several roles, mostly exploring the industry and figuring out where I belong. Starting from system integration, through InfoSec management and audit, to pentesting and application security. Finally, I’ve realized that pentesting and consulting are the areas where I could inflict the most benefit to the largest number of people.

Early in my career I’ve embraced the concept of a human, being the so called “weakest link”. Considering the high popularity of this idea, and the level of authority from which it was articulated over and over again, it was already a sort of common wisdom. Bruce Schneier puts it as “Amateurs hack systems, professionals hack people”. Other security gurus build their essays, talks, and interviews based on the assumption that humans are incapable of dealing with online threats. Who was I to disobey? So, for rather a long time I accepted it and somehow lived with it.

But the question “Why?” stuck in my head. Why people click and run crap they get from strangers? What makes them do all these unsafe things, give out secrets, allow spying on them and so on?

Much later, I think I’ve found an answer. In my point of view, security issues arise in places where different technologies meet each other.

As an example, imagine that you are asked to take an old banking application that runs on a mainframe, and bring it on the internet. This sounds as a very surprising thing to do, but it’s been done more than a few times. In the end, most probably, you will have a bunch of mediation devices, wrappers, web-services, and finally a web-interface (if you are lucky), or an ugly Java applet (if you’re not). Because of the differences of how computing was done in the mainframe era, and the way we do it now, there will be a huge complexity overhead in between, which will create security problems.

By stretching this rule, we can explain why human-to-machine interaction is the ultimate source of security risk. Because of how people and machines work: they work very, fundamentally differently.

Machines follow strict and logical laws, while humans are mostly irrational. However, their irrationality has a system in it, and this system is a subject of a large part of psychology, called behavioral science. Using the concepts of behavioral science in cyber security is often called Social Engineering.

While practicing the Red Team’s craft, I’ve obtained a chance to use Social Engineering for conducting so called social pentests or pentests via social channels. The topic got me and I’ve started to explore it with passion. I’ve read both Kevin Mitnik’s books available at the moment, and knew everything from Chris Hadnagy’s first book before it was published: mostly because of extensive listening to his Social Engineer podcast. Chris had it right about inviting guests to the program, all of which were great professionals in the areas that are directly or vaguely connected to social engineering. This is how I kept discovering new topics to learn and new people to look up to.

After a few years, I have started to not only successfully practice social engineering, but to understand the underlying psychology principles, such as reciprocity, commitment, social proof, authority, liking, and scarcity. I’ve read a vast variety of material on human behavior, from Paul Ekman, to Dan Ariely, to Robert Cialdini. Then I dug deeper: into behavioral economics, personal and collective habits, psychology of incentives, negotiations, happiness, success. I even took some phycology courses and tried to approach neurology, which still remains a challenge to me.

Going through all this knowledge and embracing all the cool ideas of these brilliant people, was quite fun. And of course, it made me a better social engineer, as well as notably improved my “soft skills”, social experience, and overall quality of life. Living with people becomes much more interesting once you realize how they work. And it’s not necessary to disassemble them for that.

One of the best ways to learn is to teach others, so I’ve started to promote social engineering within the security community: I gave talks, wrote blogs, played tricks at my colleagues in the pubs. Of course, all this was mostly about more social engineering in pentesting; we have to test tech, processes AND humans.

And, as in all areas of knowledge, after spending some time learning and practicing, I started to see “the bigger picture”. At some point, the new question stuck in my head: “How can I protect against this stuff?”

But preaching “more social engineering in pentests!” wasn’t working. Here, let me tell you how the things are going in social engineering pentests field. Usually, social engineering is not requested by clients, the same is true for bug bounty programs. It’s usually explicitly out of scope. When I ask people, should we include the social channel into the testing, the answer normally is: why testing something that we know for sure will fail?

After some time, I got bored of trying to explain to people that pentest results are not binary, that they give companies detailed input data for improvement. Even, excuse me, PCI DSS did not fix the situation by starting to require social engineering to be included to the pentest scope. Don’t hack our people, we know you are going succeed.

So, what should I do next, I pondered. What other ways shall I try? Fortunately for me, the answer was someone else’s idea.

A friend called me and told that he was appointed the CISO of a large national enterprise, and after a couple of months at the new role it was obvious to him, that the company staff needs improvement in regard to social engineering threats. His company operated in a highly competitive environment (if you know what I mean), so the risks of human error were high. People were phished constantly, were being pretexted over the phone on a daily basis, and the kinds of attacks against the company were quite sophisticated.

Later, one of the students told me a story that pretty much summed up the state of affairs. One Friday the accountant left a couple of PDF invoices on her computer desktop to submit them first thing on Monday, and left the office. To her surprise, after the weekend there were almost the same invoices on her desktop, but with slightly different payment details.

What my friend proposed, was to develop and deliver an awareness training. (Aha, my first reaction was very similar to yours, yawn, eye roll.)

“You mean one of those remote slideshows with 5 multiple choice questions in the end”, I asked.

“No”, he said. “We want you to take all your offensive experience and prepare a one-day onsite workshop where you’ll teach our top-managers, executive assistants, heads of departments, sales, the front-desk and every other high-profile target in our organization how to detect, resist, and react to social engineering attacks.”

Taking into account that I’ve just started my own small consulting company, I had not so many options. In addition, I thought that this was a brilliant idea. In this way, I found myself in a surprising situation, where I should compile all of my previous learning and practical experience, and describe it in terms, clear to the people, who have no relation to InfoSec or IT. But in order to do it right I had first to summarize why we usually do it wrong.

Explanation of problematics: how it’s done now and why it is wrong

I finally had time to sit and analyze the state of security awareness in the industry, and why it fails, miserably and constantly. Luckily for me, I didn’t have to stop working to do it, because there was a company willing to pay for that.

I did some research, which in fact was a bunch of interviews with colleagues that share or don’t share my views on the topic. After a while, I could summarize the reasons why we are doing it wrong. So, here they are.

First, cyber-security, that is basically a human problem, is attempted to be solved by technical means. Look, the majority of issues we have to deal with, be it a security vulnerability, insecure configuration, or users clicking crap: it’s all about human behavior. Humans make mistakes. And we are trying to fix these mistakes by antiviruses and firewalls. Why? Perhaps, because most of us came to this industry from IT and other technical areas, so we just see the nails everywhere. Maybe, that approach isn’t the worst-case scenario after all. But what if we just consider other ways to deal with it, instead of…

Displacing responsibility. Strategically, what we are trying to do is moving the point of risk treatment as far away as possible from the human — the point where most risks arise. Isolating the human from the responsibility for their actions, would, of course, solve all of our problems, but unfortunately it doesn’t seem to work. Maybe we should consider moving the responsibility, or at least that part humans could deal with, back to them?

If you think about it for a while, centralization of responsibility is quite a common problem, and as you may know, there are industries that are trying hard to solve it. Automotive reforms itself to so called lean manufacturing, software engineering got carried away by agile programming, operations are devops now and so on. So maybe it’s time for us too, to consider moving the control back to, or at least closer to the human being?

The third thing that is making everything above much harder to fix, is that InfoSec industry is totally driven by business risk. We want to formulate security decisions in terms of avoiding financial loss or gaining competitive advantage. We believe that speaking business language makes our attempts to improve security more efficient. However, the main thing we are really good at, is helping business tick a few boxes in a compliance checklist.

We spend most of our efforts on convincing corporate decision makers that our products and services are better not for security of their organizations, but for their budgets. Why we do that? Because, apparently, that’s where the money is. But in my opinion, instead of focusing on business risk, we should focus on personal risks of the people we talk to.

Finally, the worst thing is, that we surprisingly don’t seem to do anything about the so called weakest link. Every time I hear someone says, “Users are dumb, there is nothing we can do about it”, I ask: “What have you tried?” Did you, personally, try to change the situation? Logically, it’s the weakest link that needs the reinforcement for the most effective improvement of overall security. But, as I said, humans are irrational.

Explanation of methods: what we should do and why it is right

After I arranged this list obstacles, I started to figure out how I could complete the task at hand: reinforce people’s ability to face the risks, without completely relying on technology, by giving them back the control and responsibility for their actions, and by making security their personal interest.

Thankfully, as much as intersections of different technologies are the source of security problems, the intersections of different areas of knowledge are the source of innovation. After all these years of learning seemingly unrelated technical and human stuff, I felt ready to test some theories.

Long story short, I came up with a list of three basic tools, that, from my experience, have the highest potential and efficiency of changing human behavior in regard of cyber threats. These tools are: fear, incentives, and habits.

Fear

We all know how fear works: we experience the threats around us, get harmed by them, and after that, we can avoid them, or prepare for them. One good thing about our brain is that we don’t have to necessarily go through dangerous experiences to learn from them. Our prefrontal lobes allow us to learn from experience of others and, which is the most fascinating, from simulated experiences: our own imagination. This dramatically lowers our death rate, because we can learn to be safe, and be safe at the same time. And learning how to deal with threats in the physical world is what human brain does the best.

Our brain is an excellent tool of continuous searching, identification, and treating the risks: by fleeing from them, or fighting them, or hiding from them, or playing dead, or making preventive strikes. This, our brain developed and excelled at during the tens of millions of years of evolution. So, the mere fact that we are still here on this planet means that we can be taught to deal with threats. It’s been proven on practice, and fear is the major tool we use for that.

We memorize things better when we’re scared, or as I call it, sufficiently stressed.

Of course, you don’t need to scare your audience to death. The main goal is to make it personal to them. Cyber threats are dangerous for them, not just their company. They will lose their reputation if a Skype worm infects half of their contact list. They will be raided by the police if their PC seeds child pornography to the internet. “I am too small to be a victim”, “I have nothing to hide”, “I have nothing to steal”: these fallacies have to be eliminated. People are hacked not because they’re important. People are hacked because they are trusted by other people and organizations.

Your goal is to make your training appropriately scary, but not a bit scarier. Fear is our psychological immune system and you need to train it by making fake injections of stress. The appropriate level of stress is easy to measure. Insufficiently stressed audience will spend their time checking Facebook and Twitter. Overstressed audience will just run away. And properly stressed audience will engage into the training, won’t leave for lunch before you answer all the questions, and after the training will ask you: how do you live with all this knowledge? I always reply: you’ll get used to it.

Which brings us to the need of repeating. Our brain is smart, it remembers bad things worse than good things. Time heals, but not in the meaning that our memories degrade, they are replaced by new impressions. So, unfortunately for your audience, they will need repeating. The frequency and the form is up to you. I prefer to phish my clients once in a while; with their permission, of course, but without them knowing the exact time when it happens.

Incentives

Incentives are another great tool you can use, and it’s much younger than fear in the evolutionary sense. It doesn’t hit the foundation of our psychology, but rather exploits the social norms, that we developed as a society. The two incentives that I find the most useful are competition and belonging.

Using competition to promote security awareness is simple. Establish a sort of internal “bug bounty” program and declare a reward. Reward the reported phishing attempts, unidentified strangers caught on premise, confidential print-out leftovers. People like to be rewarded and distinguished from the mass. This is why the materiality of rewards isn’t always critical: the hall of fame could be enough.

Using belonging is a bit more complicated. Here you’ll have to create a group of corporate awareness evangelists, if you will. First, naturally, every InfoSec person should be in this group. Second, everyone of formal authority, including the top-3 levels of management should be in there. Third, but the most important: every socially hyperactive person should be in there too. I call them social unicorns, and having them in your team is a gift or a curse, depending on your point of view. They spend immense amount of time talking around water coolers and coffee machines. They know virtually everyone in the office, which means they know their birthdays, their spouses’ names, their kids’ ages and so on. They are easy to spot, and they are gold for security awareness.

How? Imagine the situation, when such a person gets hacked. The worst thing their employer could do in this case is to fire them. Because after the hack they are the best security awareness asset in the company. [Why?] They will tell everyone about how exactly it happened, what they did wrong, how cool the security guys were to explain them their mistakes, and how they never, never will do it again.

So, establishing the security culture demands at least three initial categories of, pardon me, thought leaders: the people with expert, formal, and social influence over the rest of your staff. These ladies and gentlemen should undergo a formal security training and be officially associated with security awareness initiative company-wide. The others will follow.

Habits

In order to make the change permanent, you’ll have to use habits. Habits let us automate: do less analytics, decision making, and other higher cerebral activity, relying instead on routines that we build over time. They drive us to work, clean our houses, cook our meals, and do many other important things.

Habits are critical. For example, if we had no habits, we would have much larger brains and that would cause a lot of trouble, from higher death rates of women giving birth, up to the esthetics of our selfies. But the most dangerous thing about habits is the false belief that they can be given up. The truth is, we cannot easily get rid of them, however, we can change them.

Habits are simple loops that can be described as if-then clauses, followed by rewards. Let’s look at a few examples:

· stress eating: if feel stressed, then go eat a cookie, and get higher sugar level and better mood as a reward;

· smoking: if bored, then go smoke a cigarette outside, and be rewarded by a small talk with a fellow smoker;

· drinking: if feeling down, then go to the bar, and be rewarded by a company of a thankful listener (or at least the bartender’s polite attention).

These loops of trigger, routine, and reward represent our habits and, as such, most of our behavior. Our goal is to take bad security habits and replace them with good ones. For that, we need to identify the triggers, the routines that they cause, and the rewards the brain seeks.

Let’s hear some bad security habits, I bet you got some. I’ll start with this one. If received an email, then open it immediately, and be rewarded by zero unread items. If the email contains an attachment with an intriguing name (such as “2018 compensation review plan.xlsm”), then open it as soon as possible, and be rewarded by knowing your boss’s salaries. If asked to run a macro, then click “allow”, and be rewarded by finally getting your eyes on it. You get the idea, so could you please give me a few examples from the top of your head… Anyone?

So, you totally nailed it. Now, let’s play with habits design for a while. We already discussed the reward (bug bounty and hall of fame), so let’s assume that you already have that. Then, I hope you agree, that we should change the routine to something like panic, or freeze, or at least proceed with caution. But let’s talk triggers first.

When you train people, you give them example triggers, and they usually confirm that something similar has happened to them. Then they share the cases from their experience, and in this way, you have an ever-growing collection of trigger formulae.

Each formula contains three main components:

  1. a method of social engineering attack, such as phishing emails, impersonation, elicitation, pretexting over the phone, software exploits, baiting with USB thumb drives, and so on;
  2. an influencing principle: urgency, reciprocity, social proof, authority, liking, commitment, and so on.
  3. a security context: basically, anything of personal or business value.

Again, let’s look at some popular examples.

  • You receive an email with an urgent request to provide confidential data.
  • The pizza delivery guy is staring at you while holding a huge pile of pizza boxes at your office door.
  • An “old schoolmate” you just met in the street is asking you about the specifics of your current job.
  • You receive a call from a person that introduces themselves as the CEO’s executive assistant and asks you to confirm the receipt of their previous email and open its attachment.
  • An attractive, likable human is asking you to take part in an interview and is going to compensate that with a shiny new USB drive (in the hope you insert it into your working PC later).

These are examples of triggers that should surprise your colleagues and force them to turn off the autopilot and take manual control over the situation. For that, they, of course, should be taught the influence principles, the types of modern cyber-attacks, and the kinds of things hackers could want from them: remote access, banking accounts, contact lists, bandwidth, business, and personal secrets and so on. And then, if you taught them right, they’ll be ready to learn the universal formula, that should guide them through any potentially harmful situation:

When you identify a potential type of attack, that is accompanied by influencing principle, and the situation concerns a security context, you should pause, rewind, and start processing the situation with caution, applying the skills developed during the training.

As simple as that.

Of course, it is just the knowledge, the theory. The skill, the habit is built with practice. You will need a lot of examples and training tasks for everyone to get this right. But from my experience, this is the most fun part of the training.

Bonus

OK, it seems that we have some time left, so I can give you one more tool. There are plenty of sources of awareness material in popular culture, even if we as InfoSec professionals find them of inappropriate precision. For example, in my opinion, Mr. Robot’s Season 1 did for security awareness more, than the whole InfoSec industry so far. At least, I could show it to my parents and not be ashamed of it. The Real Hustle is good at showing con artists’ tricks. Tiger Team gives an idea of what Red Teaming exercises look like. Lie to Me is quite OK to understand emotions and universal expression, as long as you read Dr. Paul Ekman’s devastating comments to each episode. So, if you like a book, or a movie, or a series about cybers, share it, don’t hold it to yourself.

Example

In the end, let me share a perfect security awareness improvement that I witnessed only once so far. We had a client that requested the full package: the initial full-scope pentest, the training for their staff, and then the re-test to measure the change. In fact, that wasn’t the plan from the beginning, but the initial pentest was so devastating, that they decided to go all in.

As sad as the initial pentest report seamed to the client, as promising it looked to us. I won’t describe everything that happened to avoid sounding like an ad. Just two things that impressed me the most.

The first thing was their reaction to the slide, showing all of their passwords (of course, without relation to usernames). It goes like this: At first, everyone is looking for theirs in the hope it isn’t there. Then, they find it, and it’s the moment of ultimate despair. But in a few seconds, they start reading others’ passwords, and then they look at each other and start laughing altogether, hysterically, and it can’t be stopped for a few minutes.

The second thing was that when the first group took the training, we had a pause for two weeks before the second group. When we started with the second group, it was a mind-blowing experience. Almost all of them have already subscribed to my blog, my Facebook page, my company’s page, started following the news we share, watching our webinars, and so on. More than half of them were already the fans of Mr. Robot and asked questions about the validity of the techniques depicted in it.

Eight months later, when we conducted the re-test, the results were fascinating. I’d be happy to say that we failed to hack them, but that wouldn’t be technically true. Because of all employees, one actually took the bait, but she did it intentionally. That was her last day at work, she already got the check, and according to her, it was obvious that it was us. So, she decided to have some fun. And she showed me that there are aspects of human behavior, that require further research.

Closure

So, this is my story, so far. Maybe, because in its very beginning I myself got hacked, I avoided the temptation of blaming the user, and actually figured out how humans can become stronger. This is what I’m inviting you to do too. Users aren’t dumb, they just don’t now. That’s why humans are the weakest link in security — by default. And this is how you change their settings.

Don’t underestimate humans. Give them a chance, and believe me: they will surprise you.

Thank you.