Що таке збір облікового запису?

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

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

Обліковий запис

Чи намагалися ви коли-небудь увійти на веб-сайт лише для того, щоб він повідомив вам, що ваш пароль неправильний? Це скоріше конкретне повідомлення про помилку, чи не так? Цілком можливо, що якщо ви потім навмисно зробите помилку у своєму імені користувача чи адресі електронної пошти, веб-сайт повідомить вам, що «обліковий запис із цією електронною адресою не існує» або щось подібне. Бачите різницю між цими двома повідомленнями про помилку? Веб-сайти, які роблять це, вразливі до перерахування облікових записів або збирання облікових записів. Простіше кажучи, за допомогою двох різних повідомлень про помилку для двох різних сценаріїв можна визначити, чи має ім’я користувача чи адреса електронної пошти дійсний обліковий запис у службі чи ні.

Існує багато різних способів виявлення такого роду проблеми. Наведений вище сценарій двох різних повідомлень про помилку досить очевидний. Це також легко виправити, просто надайте загальне повідомлення про помилку для обох випадків. Щось на зразок «Ім’я користувача чи пароль, які ви ввели, були неправильними».

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

Тонкість в збиранні рахунків

Обидва вищезазначені способи є дещо гучними з точки зору свого сліду. Якщо зловмисник спробує здійснити будь-яку масштабну атаку, це досить легко відобразиться практично в будь-якій системі журналювання. Метод скидання пароля також явно надсилає електронний лист на будь-який обліковий запис, який насправді існує. Бути голосним – не найкраща ідея, якщо ви намагаєтеся бути підступним.

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

Чудовий спосіб проявити непомітність — взагалі ніколи не торкатися атакуваного веб-сайту. Якби зловмисник намагався отримати доступ до корпоративного веб-сайту лише для співробітників, він міг би зробити саме це. Замість того, щоб перевіряти сам сайт на наявність проблем із переліком користувачів, вони можуть піти в інше місце. Переглядаючи такі сайти, як Facebook, Twitter і особливо LinkedIn, можна створити досить непоганий список співробітників компанії. Якщо потім зловмисник зможе визначити формат електронної пошти компанії, наприклад ім’я.прізвище@comapny.com, тоді він зможе зібрати велику кількість облікових записів, навіть не підключаючись до веб-сайту, який планує атакувати.

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

Диявол криється в деталях

Загальне повідомлення про помилку, як правило, є рішенням для запобігання активному перерахуванню облікових записів. Однак іноді саме маленькі деталі видають гру. За стандартами веб-сервери надають коди статусу, відповідаючи на запити. 200 — це код стану для «ОК», що означає успіх, а 501 — це «внутрішня помилка сервера». Веб-сайт має мати загальне повідомлення про те, що було надіслано запит на скидання пароля, навіть якщо насправді це не так, оскільки не було облікового запису з наданим іменем користувача чи адресою електронної пошти. У деяких випадках сервер усе одно надсилатиме код помилки 501, навіть якщо веб-сайт відображає повідомлення про успішне завершення. Для зловмисника, який звертає увагу на деталі, цього достатньо, щоб зрозуміти, що обліковий запис дійсно існує чи не існує.

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

Складання деталей

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

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

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

Наслідки збирання облікового запису

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

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

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

Висновок

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

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