Інцидент неминучий. Є лише дві речі, на які ви можете вплинути. Це те, наскільки легко вас буде зламати, та чи будете ви та ваші колеги знати, що робити коли це станеться.
Сьогодні чогось згадалося, як я кілька років тому майже одночасно спілкувався з двома джентльменами на тему неминучості настання інциденту, тобто факту компрометації інформаційних систем. Контексти були різні: в одному випадку ми обговорювали принципи побудови систем та процесів виявлення та реагування на інциденти (Security Operations Center, SOC), в іншому – доцільність проведення тесту на проникнення по соціальному каналу. Але реакція була майже однакова та досить типова: як це інцидент настане? що значить неминуче? та у нас тут і моніторинг, і реагування, і гайки скрізь закручені.
Пройшов час, і обидва ці джентльмени, точніше інфраструктури, безпеку яких вони забезпечували, стали цілями досить типових атак з використанням все тієї ж соціальної інженерії. Інциденти були досить потужні, але залишмо хоч трохи інтриги. Скажу лише, що це вочевидь вплинуло напрямок їхньої подальшої кар’єри.
До чого це я? Ні, я не про те, що коли ваші аргументи не діють, варто трохи почекати. Хоча інколи це непогана стратегія. Я просто хочу вам повторити те, що казав їм.
Вас зламають. Якщо у вас є що красти та якщо немає. Якщо у вас є Політика безпеки та якщо немає. Якщо у вас є сертифікат PCI DSS або ISO27000 та якщо є обидва. Якщо у вас три антивіруси або нуль. Якщо ви не проводите кібернавчання для персоналу та якщо ви їх проводите. Якщо ви робите пентести в повному обсязі та якщо ви навіть не скануєте периметр nmap-ом зі скриптами. Вас зламають: хтось, колись, з відомих або невідомих вам причин це зробить, тому що це можна зробити. Я знаю як — і повірте, це не вища математика (її я теж знаю). А ще, звичайно ж, я на власній шкурі знаю як це, коли вас зламують.
Тому кажу вам безплатно те, що їм сказав за гроші: інцидент неминучий. Є лише дві речі, на які ви можете вплинути. Це те, наскільки легко вас буде зламати, та чи будете ви та ваші колеги знати, що робити коли це станеться.
Нещодавно в інтернеті знову набули популярності історії про шкідливі програми, які поширюються у SVG файлах, відправлених у Facebook. Ви можете дізнатися більше про цей вектор атаки та методи зловмисників в цьому пості, але мою увагу привернуло інше.
Як ви, напевно, знаєте, SVG це векторний графічний формат, який, по суті, є файлом XML, що містить інструкції з малювання різних зображень та, що декому може здатися дивним, може містити програмний код JavaScript. Ось приклад SVG, відкривши який в більшості сучасних браузерів, ви побачите синє коло та запустите зовнішній сценарій, на який вказує відредаговане посилання:
На щастя, це спрацює лише тоді, коли в адресному рядку браузера явно вказати URL SVG-файлу, або ж якщо файл буде відкрито з диска; <IMG SRC = більш не працює з очевидних причин.
Отже, коли тема поширення шкідливих програм у SVG піднялася знову, цього разу в контексті недостатньої фільтрації вмісту в Facebook Messenger, я подумав про наслідки для приватності, які несе цей (не дуже ефективний) захід безпеки. Я гадав, що було б гарною ідеєю використати JavaScript-код в зображенні SVG, щоб перевірити, як сучасні месенджери обробляють цей формат файлів.
Після низки повідомлень, відправлених моїй дружині та колегам, я сподіваюся, що мені не заборонять використовувати месенджери, які я використав під час тестування. І, звичайно ж, у мене є чим з вами поділитися.
Гарна новина полягає в тому, що Signal, Viber, WhatsApp, та Facebook Messenger і Telegram у своїх «секретних» режимах, не брешуть, стверджуючи, що шифрують повідомлення з кінця в кінець. Хоча, в разі WhatsApp і Telegram, вставлені в повідомлення URL викликали деяку активність з боку клієнта, крім цього ніхто більше не “з’явився” в журналах вебсервера.
Погана новина в тому, що на цьому хороші новини закінчуються.
Розпочнемо з очевидного: Slack здійснює активний перегляд вмісту за посиланням для того, щоб показати його в графічному інтерфейсі. Це круто, ми всі знаємо що так і потрібно, в цьому пості я просто використаю це як приклад того, як ця діяльність виглядає. Отже, коли ви відправляєте посилання, вебсервер, що його містить, реєструє в журналі ось такий запит:
Пояснюю. Спершу якийсь хост Facebook підтягує SVG-файл, а після цього відбувається низка запитів, які генеруються “вбудованим” у SVG скриптом, а це наочно демонструє, що сценарій насправді виконуються в якомусь “браузері”. Цілком можливо, що це і є елемент фільтрації вмісту, тому що це відбувається не кожного разу та виглядає як начебто поведінка “живого” користувача. Все одно, це якось дивно 🙂
Як не дивно, Google Hangouts не показав жодних ознак інтересу до мого посилання.
Це залишає багато запитань відкритими, проте, очевидно одне: політики конфіденційності нам не брешуть і ми насправді не є власниками даних, які ми пересилаємо за допомогою месенджерів, якщо наше спілкування не зашифроване з кінця в кінець.
Під час цих тестів я використовував дивовижний JavaScript-кейлоггер by John Leitch.
Various stories about malware spreading over SVG files sent on Facebook were circulating over the interwebs lately. You can read more about this vector and the methods used by malicious hackers in this post, but what caught my interest was not the attack itself.
As you probably know, SVG is a vector image format that is, in fact, an XML file containing various drawing instructions and, surprisingly to some, capable of containing and running JavaScript code. For example, when opening in most modern browsers, this SVG will show you a blue circle and run an external script loaded from the redacted host.
SVG file containing external JavaScript code.
This will work only when the browser is explicitly pointed to the SVG file URL or if the file is open from the disk; <img src= does not work anymore for obvious reasons.
So, when this SVG topic has popped up again, this time in the context of poor content filtering in Facebook Messenger, I instinctively thought about privacy implications introduced by this (apparently inefficient) security measure. I thought it could be a good idea to use JavaScript code delivered in SVG to check how modern instant messengers process this file format.
After a series of messages sent to my wife and colleagues, I feel a subtle hope that I will not be banned from using the messengers I’ve tested. And, of course, I have some results to share.
The good news is that Signal, Viber, WhatsApp, and both Facebook Messenger and Telegram in their “secret” modes, all five claiming end-to-end encrypted communications, were not caught cheating. Although in WhatsApp and Telegram, pasted URLs resulted in some activity originating from the client, no one else appeared in the web-server logs.
Bad news is that that’s pretty much all good news.
Starting from expected obvious: Slack does an active preview of the linked content to show it in the GUI. That’s cool; we all know that, so I use it as an example of how this kind of activity looks like for this post. So, when you send a link, the web-server serving it registers this request in the log:
As you can see, first, some Facebook-owned host fetches the SVG, and after that, there is a series of requests to “embedded” script URL, which demonstrates that the script is actually run at some “browser.”
Strangely enough, Google Hangouts haven’t shown any sign of interest in my links.
This leaves a lot of questions open. However, one thing is obvious: privacy policies are correct, and we don’t really own the stuff we send over Instant Messengers unless our comms are encrypted end-to-end.
During these tests I used awesome JavaScript keylogger by John Leitch.
I have enabled Slack notifications in my standalone XSS Hunter installation that I’ve finally debugged out of complete uselessness earlier today.
Thanks to @igorblum, who has, besides pushing me to try out XSS Hunter in the first place, pointed my attention to the lack of timeliness of notifications in XSS Hunter’s default notifications delivery method: emails sent via MailGun. In addition to abovementioned delays, MailGun has established the procedure of “Business Verification” of all accounts and domains you register. Which is, in fact quite convenient, but requires service desk manual interaction anyway.
Igor’s initial idea was to push notifications to the Telegram channel, which is quite cool. However, after reading his instructions on accomplishing this task, I felt that it’s a little bit too much for me for the rest of the day. So I made a quick and dirty hack: I created a bot in my ‘personal’ Slack team and made it push notifications to #general channel.
Now, every time an XSS is fired in XSS Hunter, I get something like this:
You can do it to using this short cheat sheet I’ve published on GitHub.
Update: I have added the option of sending direct messages instead of posting to a channel. This gives you cleaner channels and a nice bot logo in messages. Enjoy!
Якби у мене був Топ-10 питань, які задають мені свідомі громадяни, які не байдужі до власної інформаційної безпеки, то на першому місці безперечно було б
Які мобільні месенджери безпечні, а які ні?
Я спробую висловити свою професійну думку щодо цього та поширити її серед якомога ширшої аудиторії, в чому розраховую на допомогу читачів.
tl;dr
Як і на всі інші питання у Всесвіті, на це можна відповісти або одним реченням, або в декількох томах. Отже, коротка відповідь:
Messenger by Facebook використовує End-to-End шифрування, але не за замовчуванням, немає інформації щодо незалежного ревю
Дуже небезпечні –
Skype
SnapChat
WeChat
Yahoo! Messenger
BlackBerry Messenger
Тепер докладніше.
Навіщо нам безпека миттєвих повідомлень?
Спершу даймо відповідь на питання, навіщо нам безпека у програмах для обміну повідомленнями, якщо є така чудова мобільна послуга, як SMS.
По-перше, SMS — небезпечні. У своїй фундаментальній незахищеності від загроз прослуховування та втручання в спілкування абонентів, мобільні мережі перевершили навіть Інтернет. Перехоплення та підробка SMS вже давно не є задачею, яка під силу лише міжнародним шпигунам, а вартість необхідного для її здійснення обладнання весь час зменшується.
По-друге, SMS — це дорого. Місцями непристойно дорого. Спілкування за допомогою месенджерів через мобільний інтернет або WiFi набагато дешевше. При цьому воно не додає суттєвих ризиків якщо ви подбали про безпеку під час вибору інструменту спілкування.
Які вимоги до безпеки миттєвих повідомлень?
Щоб правильно вибрати програму для листування миттєвими повідомленнями, вам потрібно дати собі відповідь на три прості питання:
Чи слідкують за мною міжнародні шпигуни та/або правоохоронні органи?
Чи хочу я зберігати історію листування?
Які месенджери наразі популярні серед моїх друзів та знайомих або в моєму регіоні?
Отже, давайте по черзі.
1. Модель загроз
Як завжди перед вибором інструменту захисту варто поміркувати, що саме та від кого ми захищаємо.
Загалом є три основні категорії нападників у кіберпростір: опортуністи, яким більше нема чим зайнятися, кіберзлочинці, які крадуть в нас гроші або майно, та національні розвідувальні агенції, які таким чином нишпорять одне за одним, борються з тероризмом, та роблять ще багато того, про що нам краще не знати. Правильно обравши рівень нападника ви зможете більш вдумливо підійти до вибору програми-месенджера.
Також, подумайте про цінність даних, які передаються, та приватність учасників листування. В нашому житті багато різних людей та рівень секретності наших стосунків з ними також різний. Конфіденційність ділового листування можна порівняти з приватністю особистих повідомлень. Дані, які передаються, адресати, які їх отримують, та навіть самі факти здійснення обміну повідомленнями нерідко є предметом цікавості людей, які можуть використати їх не на вашу користь.
2. “2 peer or not 2 peer…”
Миттєві повідомлення в різних месенджерах наразі передаються двома принципово різними способами: напряму відправником адресату (peer-to-peer), або через сервер. Причому модель ця дуже образна: насправді месенджер може фізично передавати повідомлення через сервер, але при цьому вміст повідомлення буде зашифрований з кінця в кінець (end-to-end). Тобто сервер (та його оператор) не матиме змоги отримати до нього доступ, а отже цей процес буде майже так само безпечний, як і при справжньому peer-to-peer спілкуванні. “Майже”, тому що факти обміну повідомленнями все одно будуть реєструватися на сервері, а це за певних умов може бути загрозою приватності.
Як бачите, тут виникає один з класичних конфліктів між безпекою та зручністю програмного забезпечення. З одного боку, ми не хотіли б, щоб Google, Facebook та решта майкрософтів мали доступ до нашого листування. Бо хто зна, що собі думають їхні адміни, і взагалі, з ким вони потім цими даними діляться. Але з іншого боку, ми хотіли б зберегти історію листування та мати змогу відновити її на новому пристрої або після перевстановлення операційної системи або додатку месенджера.
Звичайно, під час обміну повідомленнями з увімкненим end-to-end шифруванням збереження історії можливе лише на пристроях учасників листування. Про це треба пам’ятати як перед вибором засобу листування, так і перед переїздом на нову платформу або пристрій. Багато месенджерів зберігають історію в резервних копіях, які вони створюють самостійно, або за допомогою стандартних засобів ОС.
3. В безпеці та не на самоті
Популярність месенджерів штука дивна та залежить від багатьох факторів, серед яких важливу роль відіграють вік користувачів та їхній ареал. Якщо у Південній Америці абсолютно усі користуються WhatsApp, то в Східній Європі найбільш поширені Viber та Telegram, причому Messenger не далеко відстав. Отже, обираючи засіб спілкування, поцікавтеся, які у цього вибору об’єктивні перспективи, щоб уникнути ролі одинака в пустелі.
Підсумуємо. З врахуванням цінності листування, приватності його учасників, та релевантних загроз, ви можете використати (або ні) повне (end-to-end) шифрування, в якому зберігається (або ні) анонімність учасників та історія повідомлень. У разі гострої потреби в захисті, ви можете звернути увагу на те, чи проводилось для месенджера формальне дослідження безпеки з позитивним висновком.
Нижче я навожу таблицю з відомими мені характеристиками популярних месенджерів. Сподіваюся, ці результати стануть вам в пригоді під час прийняття рішення про початок або продовження використання того чи іншого засобу спілкування.
Звертаю вашу увагу на “культурні особливості” деяких популярних месенджерів. Як бачите, в залежності від того, який режим спілкування ви обрали, Telegram та Messenger можуть реєструвати ваші повідомлення на сервері, або ні. Також, у WhatsApp за замовчуванням не увімкнені повідомлення про зміни даних співрозмовників: якщо ваш контакт перевстановить додаток або іншим чином змінить ключі шифрування, WhatsApp про це промовчить. Я раджу увімкнути такі застереження в пункті меню Settings -> Account -> Security.
Цілком нормально використовувати декілька різних месенджерів для різних цілей: для спілкування по роботі, з друзями та в сім’ї. А підтримка балансу між безпекою та зручністю — вашою та ваших співрозмовників — завжди є гарною ідеєю.
Особисто я використовую Viber та Messenger для спілкування з друзями та близькими, та Signal — для листування з клієнтами та колегами.
Залишайтеся в безпеці.
Оновлено 2017–01–12
Через знайдені в них вразливості реалізації та бізнес-логіки, Viber та Telegtam “понижено” в рейтингу.
Виправлена історична несправедливість: WhatsApp, як продукт, що використовує Signal API, відправлений в першу категорію.
Додано Google Allo, який використовує Signal API в Incognito Mode.
Додано деякі пояснення щодо (не)безпеки окремих месенджерів.
Якщо ви хочете дізнатися більше про безпеку месенджерів, я рекомендую цей виступ.
