Категорія: Кібербезпека

Есе, рекомендації та думки на професійні теми: кібербезпека, аппсек та пентести.

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. Якщо ви хочете дізнатися більше про безпеку месенджерів, я рекомендую цей виступ.

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?

Як хакери отримують ваші паролі

Та як цьому запобігти

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

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

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

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

1. Підбір пароля онлайн

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

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

2. Підбір пароля оффлайн

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

Plain text password:	my5uperDup3r$ecurePWD
MD5 hash (old *NIX):	eea2f7abd226770f85fbf69f836a3caf
LM hash (old Win):	AAD3B435B51404EEAAD3B435B51404EE 
NTLM hash (new Win):	244936F66C0BFF1C222011AA6D41AC2F 
SHA1 hash:	2c3d59e5df90826f5dde14104ecaa708544da842 
SHA256 hash:	57b1c949176683545fd1f8b7e8a74ff6b08d1936da875000a0e5f5f23929d18f

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

3. Повторне використання пароля

Не секрет, що багато користувачів використовують один пароль в декількох системах. На жаль, це поширена практика, дехто навіть скрізь використовує всього один пароль та гордо називає його “улюбленим”. Погана новина в тому, що витоки баз даних паролів відбуваються щодня, після чого ці бази або стають доступними публічно, або продаються на чорному ринку. Тому знайшовши пароль користувача з логіном [email protected] у викраденій базі аккаунтів ВКонтакте, хакер перевірить, чи підходить він в Однокласниках, Facebook та на VPN-сервері його компанії-роботодавця.

Дізнатися про те, як часто та в яких масштабах трапляються витоки баз даних паролів, можна на вебсайті https://haveibeenpwned.com. Там же можна перевірити, які з ваших паролів в інтернеті вже було скомпрометовано та підписатися на повідомлення про майбутні злами.

4. Викрадення або підглядання пароля

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

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

5. Відновлення пароля через email або SMS

Більшість гідних поваги інтернет-сервісів дозволяють користувачам відновити втрачений чи забутий пароль за допомогою email або номера телефону, який використовувався під час реєстрації. (Менш підковані використовують для цього відповіді на “секретні питання”, які зазвичай не є такими вже й секретними). Отже, отримавши доступ до номера телефону або, що значно легше, до електронної пошти користувача, хакер може скористатися легітимною процедурою відновлення пароля.

6. Перехоплення пароля мережею

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

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