Автор: Vlad Styran

Instant Messengers and URLs

What happens when you send a link?

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 XML file
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:

54.89.92.4 — — [21/Nov/2016:16:02:31 +0000] “GET /avakl.js HTTP/1.1” 404 152 “-” “Slackbot-LinkExpanding 1.0 (+https://api.slack.com/robots)"

Where 54.89.92.4 of course is a Slack instance in Amazon AWS:

$ whois 54.89.92.4 | grep Organization
Organization: Amazon Technologies Inc. (AT-88-Z)

Let’s take a look how other messengers deal with the links.

Skype sends 6 requests from 2 hosts, both belonging to Microsoft directly. A rich company can afford that.

23.101.61.176 — — [21/Nov/2016:15:38:44 +0000] “GET /avakl.svg HTTP/1.1” 200 328 “-” “Mozilla/5.0 (Windows NT 6.1; WOW64) SkypeUriPreview Preview/0.5”
23.101.61.176 — — [21/Nov/2016:15:38:44 +0000] “GET /avakl.svg HTTP/1.1” 200 328 “-” “Mozilla/5.0 (Windows NT 6.1; WOW64) SkypeUriPreview Preview/0.5”
23.101.61.176 — — [21/Nov/2016:15:38:44 +0000] “GET /avakl.svg HTTP/1.1” 200 328 “-” “Mozilla/5.0 (Windows NT 6.1; WOW64) SkypeUriPreview Preview/0.5”
23.101.61.176 — — [21/Nov/2016:15:38:44 +0000] “GET /avakl.svg HTTP/1.1” 200 328 “-” “Mozilla/5.0 (Windows NT 6.1; WOW64) SkypeUriPreview Preview/0.5”
104.45.18.178 — — [21/Nov/2016:15:38:44 +0000] “GET /avakl.svg HTTP/1.1” 200 328 “-” “Mozilla/5.0 (Windows NT 6.1; WOW64) SkypeUriPreview Preview/0.5”
104.45.18.178 — — [21/Nov/2016:15:38:44 +0000] “GET /avakl.svg HTTP/1.1” 200 328 “-” “Mozilla/5.0 (Windows NT 6.1; WOW64) SkypeUriPreview Preview/0.5”

Telegram fetches the image once, form it’s directly owned network.

149.154.167.163 — — [21/Nov/2016:15:35:18 +0000] “GET /avakl.svg HTTP/1.1” 200 328 “-” “TelegramBot (like TwitterBot)”
$ whois 149.154.167.163 | grep -E ‘^descr|^person|^address’
descr: Telegram Messenger Network
person: Nikolai Durov
address: P.O. Box 146, Road Town, Tortola, British Virgin Islands
descr: Telegram Messenger Amsterdam Network

The URL sent via Facebook Messenger on mobile results in four requests from different addresses.

31.13.102.98 — — [21/Nov/2016:19:44:51 +0000] “GET /avakl.svg HTTP/1.1” 206 328 “-” “facebookexternalhit/1.1 (+https://www.facebook.com/externalhit_uatext.php)"
173.252.120.119 — — [21/Nov/2016:19:44:52 +0000] “GET /avakl.svg HTTP/1.1” 200 328 “-” “facebookexternalhit/1.1 (+https://www.facebook.com/externalhit_uatext.php)"
173.252.123.130 — — [21/Nov/2016:19:44:53 +0000] “GET /avakl.svg HTTP/1.1” 200 328 “-” “facebookexternalhit/1.1 (+https://www.facebook.com/externalhit_uatext.php)"
173.252.123.129 — — [21/Nov/2016:19:45:12 +0000] “GET /avakl.svg HTTP/1.1” 200 328 “-” “facebookexternalhit/1.1 (+https://www.facebook.com/externalhit_uatext.php)"

Facebook kindly explains its behavior by provided URL.

However, when the link is sent via Facebook web-site, look what happens:

31.13.113.194 — — [21/Nov/2016:15:11:58 +0000] “GET /avakl.svg HTTP/1.1” 206 328 “-” “facebookexternalhit/1.1”
66.220.145.243 — — [21/Nov/2016:15:12:01 +0000] “GET /avakl.svg HTTP/1.1” 200 328 “https://l.facebook.com/lsr.php?u=https%3A%2F%2F*******%2Favakl.svg&ext=1479741420&hash=AcnhtJ5F7tKqGD-kIHGSbCF0-TflNMaiR9WNCxHznoOqJw" “Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0”
66.220.145.243 — — [21/Nov/2016:15:12:01 +0000] “GET /kl.js HTTP/1.1” 200 283 “https://*******/avakl.svg" “Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0”
66.220.145.243 — — [21/Nov/2016:15:12:01 +0000] “GET /favicon.ico HTTP/1.1” 404 152 “https://*******/avakl.svg" “Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0”
66.220.145.243 — — [21/Nov/2016:15:12:03 +0000] “GET /keylogger? HTTP/1.1” 404 152 “https://*******/avakl.svg" “Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0”
66.220.145.243 — — [21/Nov/2016:15:12:04 +0000] “GET /keylogger? HTTP/1.1” 404 152 “https://*******/avakl.svg" “Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0”
66.220.145.243 — — [21/Nov/2016:15:12:05 +0000] “GET /keylogger? HTTP/1.1” 404 152 “https://*******/avakl.svg" “Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0”
66.220.145.243 — — [21/Nov/2016:15:12:06 +0000] “GET /keylogger? HTTP/1.1” 404 152 “https://*******/avakl.svg" “Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0”
66.220.145.243 — — [21/Nov/2016:15:12:07 +0000] “GET /keylogger? HTTP/1.1” 404 152 “https://*******/avakl.svg" “Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0”
66.220.145.243 — — [21/Nov/2016:15:12:08 +0000] “GET /keylogger? HTTP/1.1” 404 152 “https://*******/avakl.svg" “Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0”

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.

How to enable Slack notifications in XSS Hunter

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:

XSS Hunter report in Slack

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!

Stay safe.

Безпечні месенджери

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

Які мобільні месенджери безпечні, а які ні?

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

tl;dr

Як і на всі інші питання у Всесвіті, на це можна відповісти або одним реченням, або в декількох томах. Отже, коротка відповідь:

Безпечні –

Не дуже безпечні –

Небезпечні –

Дуже небезпечні –

  • Skype
  • SnapChat
  • WeChat
  • Yahoo! Messenger
  • BlackBerry Messenger

Тепер докладніше.

Навіщо нам безпека миттєвих повідомлень?

Спершу даймо відповідь на питання, навіщо нам безпека у програмах для обміну повідомленнями, якщо є така чудова мобільна послуга, як SMS.

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

По-друге, SMS — це дорого. Місцями непристойно дорого. Спілкування за допомогою месенджерів через мобільний інтернет або WiFi набагато дешевше. При цьому воно не додає суттєвих ризиків якщо ви подбали про безпеку під час вибору інструменту спілкування.

Які вимоги до безпеки миттєвих повідомлень?

Щоб правильно вибрати програму для листування миттєвими повідомленнями, вам потрібно дати собі відповідь на три прості питання:

  1. Чи слідкують за мною міжнародні шпигуни та/або правоохоронні органи?
  2. Чи хочу я зберігати історію листування?
  3. Які месенджери наразі популярні серед моїх друзів та знайомих або в моєму регіоні?

Отже, давайте по черзі.

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) шифрування, в якому зберігається (або ні) анонімність учасників та історія повідомлень. У разі гострої потреби в захисті, ви можете звернути увагу на те, чи проводилось для месенджера формальне дослідження безпеки з позитивним висновком.

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

Instant messengers comparison

Звертаю вашу увагу на “культурні особливості” деяких популярних месенджерів. Як бачите, в залежності від того, який режим спілкування ви обрали, Telegram та Messenger можуть реєструвати ваші повідомлення на сервері, або ні. Також, у WhatsApp за замовчуванням не увімкнені повідомлення про зміни даних співрозмовників: якщо ваш контакт перевстановить додаток або іншим чином змінить ключі шифрування, WhatsApp про це промовчить. Я раджу увімкнути такі застереження в пункті меню Settings -> Account -> Security.

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

Особисто я використовую Viber та Messenger для спілкування з друзями та близькими, та Signal — для листування з клієнтами та колегами.

Залишайтеся в безпеці.

Оновлено 2017–01–12

  1. Через знайдені в них вразливості реалізації та бізнес-логіки, Viber та Telegtam “понижено” в рейтингу.
  2. Виправлена історична несправедливість: WhatsApp, як продукт, що використовує Signal API, відправлений в першу категорію.
  3. Додано Google Allo, який використовує Signal API в Incognito Mode.
  4. Додано деякі пояснення щодо (не)безпеки окремих месенджерів.
  5. Якщо ви хочете дізнатися більше про безпеку месенджерів, я рекомендую цей виступ.

Про бігунів

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

Отже, висновок перший: бігунам по цимбалах.

Конкретизую. Нерідко мені поступають коменти, деколи жартівливі, деколи так, інколи прямо у ФБ, а часом у реалі, що тіпа ми вимахуємось. Що усі ці фотки зі спортзалів та після пробіжки — це джакузі (“чистої води надуватєльство” як Pavel Riazanov казав). Що ніби ото є прояви нарцисизму та дефіциту уваги. І що навіть якісь дослідження на цю тему є, які цю гіпотезу науково підтверджують.

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

Ось вам яскравий приклад. В кожному “ареалі” бігунів є певний набір яскравих персонажів. Наприклад, “дід” — це такий дядько за 50, сухий і жилястий, який бігає майже щодня, причому коли немає снігу то босяка, клав на мороз або ожеледь і взагалі рембо. Або спортсмен/ка — фігачить інтервали, вічно з якимись батончиками та гелями, міряє пульси й зазвичай в якійсь командній формі. Або, що частіше, це худєюща/щий, про цих докладніше.

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

Але це про думки взагалі, тепер про фоточки. Фоточки, вони не для того, щоб “дивись як я можу”. Вони для того, щоб “дивись як можна”. Тобто, якщо зміг один, то зможе й інший. Люди на протезах долають марафони, вони що, теж вимахуються коли фотки роблять? Ні, вони показують мені, що моя міжхребцева грижа то в порівнянні просто нежить, а легкий біль в гомілці пройде після другого кілометру, тому нема чого її мацати, бери кроси й мерщій в парк. А потім зафігач селфача і покажи другові, що сніг на даху його тачки то не причина сидіти вдома. А по дорозі посміхнися трьом худєющім і дай краба дєду, бо дєд, курва, і в 60 буде марафони за 4- бігати, а ти хоч подивишся.

Коротше, я сподіваюся що я зрозуміло викладаю. Але якщо раптом хтось подумає, що я виправдовуюся, то нагадую: бігуну по цимбалах.

Сніг скінчився. Піти побігати чи що…

On the usefulness of Penetration Testing methodologies

Let’s imagine for a moment how the “bad guys” are planning their attacks. In the dark basement with cyber-punk posters covering the graffiti on the walls, with a bunch of half-assembled computers lying here and there, malicious hackers gather around the poorly lit table to decide what version of a Black Hat Attack Methodology to use in the upcoming criminal operation. Sounds absurd, right? Of course, because the attackers are not methodical.

As Penetration Testers, we see our main goal in testing our clients’ defenses functionally to assess their ability to withstand a real-world attack. Do we have to rely on external knowledge for that? Obviously, yes, it is impossible to know everything about every attack vector in 2016. Do we have to stick to a predefined set of instructions, a so-called methodology? That depends.

If you are not a pentester, and yet you have to act as one, methodologies are inevitable. To conduct a pentest yourself or reproduce the results in the report from an external consultancy, you have to get your head around a methodology of some sort. In fact, this happens all the time: the perception in the market is such that anyone, be it an accounting firm or an IT audit practice, can do Penetration Tests: look at the plenty of methodologies out there!

But if you do pentesting for a living, do you really need Methodologies? I am a big fan of seeing a pentest as rather a mission than a project. Of course, a mission has to have a plan, but it rarely can be scripted in detail. It’s essential to have a recurring chain of acquiring, analyzing, and applying data and share it within the team. It’s perfect to have both specialization and knowledge sharing between the team members. But to write down “what we do,” “what we do when we’re in,” “how we exfiltrate” in a static document? No, thanks.

To succeed at something, we have to have good mental models and actual practical how-tos at our disposal. The models let us build insight into how the attack would go and what we would have to do along the way. The how-tos and examples let us prepare for the actual operations: collect the data, apply or build the tools, make moves and get the proof of a risk to the client’s business out there. The methodologies try to bridge the gap between the two for those who need it. Do you?