Какво е Account Harvesting?

Има много различни видове нарушения на данните. Някои включват огромно количество време, планиране и усилия от страна на нападателя. Това може да приеме формата на научаване как работи дадена система, преди да създадете убедително фишинг съобщение и да го изпратите на служител, който има достатъчно достъп, за да позволи на нападателя да открадне чувствителни данни. Този вид атака може да доведе до загуба на огромно количество данни. Изходният код и фирмените данни са често срещани цели. Други цели включват потребителски данни като потребителски имена, пароли, данни за плащане и PII като номера на социално осигуряване и телефонни номера.

Някои атаки обаче не са толкова сложни. Разбира се, те също нямат толкова голямо въздействие върху всички засегнати. Това обаче не означава, че те не са проблем. Един пример се нарича събиране на акаунти или изброяване на акаунти.

Изброяване на акаунти

Опитвали ли сте някога да влезете в уебсайт само за да ви каже, че паролата ви е грешна? Това е по-скоро конкретно съобщение за грешка, нали? Възможно е, ако след това умишлено направите печатна грешка във вашето потребителско име или имейл адрес, уебсайтът да ви каже, че „акаунт с този имейл не съществува“ или нещо в този смисъл. Виждате ли разликата между тези две съобщения за грешка? Уебсайтовете, които правят това, са уязвими към изброяване на акаунти или събиране на акаунти. Просто казано, чрез предоставяне на две различни съобщения за грешка за двата различни сценария е възможно да се определи дали дадено потребителско име или имейл адрес има валиден акаунт в услугата или не.

Има много различни начини за идентифициране на този вид проблем. Горният сценарий на двете различни съобщения за грешка е доста видим. Освен това е лесно да се коригира, просто предоставете общо съобщение за грешка и за двата случая. Нещо като „Въведеното от вас потребителско име или парола са неправилни“.

Други начини за събиране на акаунти включват формуляри за нулиране на парола. Възможността да възстановите акаунта си, ако забравите паролата си, е удобна. Лошо защитен уебсайт обаче може отново да предостави две различни съобщения в зависимост от това дали съществува потребителското име, за което сте се опитали да изпратите повторно задаване на парола. Представете си: „Акаунтът не съществува“ и „Нулирането на паролата е изпратено, проверете имейла си“. Отново в този сценарий е възможно да се определи дали съществува акаунт чрез сравняване на отговорите. Решението също е същото. Предоставете общ отговор, нещо като: „Изпратен е имейл за нулиране на парола“, дори ако няма имейл акаунт, до който да го изпратите.

Тънкост при събирането на акаунти

И двата метода по-горе са донякъде силни по отношение на техния отпечатък. Ако нападател се опита да извърши една от двете атаки в мащаб, това ще се появи доста лесно във всяка система за регистриране. Методът за нулиране на паролата също така изрично изпраща имейл до всеки акаунт, който действително съществува. Да бъдеш силен не е най-добрата идея, ако се опитваш да бъдеш подъл.

Някои уебсайтове позволяват директно взаимодействие с потребителя или видимост. В този случай, просто като сърфирате в уебсайта, можете да съберете екранните имена на всеки акаунт, който срещате. Екранното име често може да бъде потребителското име. В много други случаи може да даде голям намек за това какви потребителски имена да отгатнете, тъй като хората обикновено използват варианти на имената си в своите имейл адреси. Този тип събиране на акаунти взаимодейства с услугата, но по същество е неразличим от стандартната употреба и затова е много по-фин.

Чудесен начин да бъдете деликатен е изобщо да не докосвате уебсайта, който е атакуван. Ако нападател се опитва да получи достъп до корпоративен уебсайт само за служители, той може да успее да направи точно това. Вместо да проверяват самия сайт за проблеми с изброяването на потребителите, те могат да отидат другаде. Чрез претърсване на сайтове като Facebook, Twitter и особено LinkedIn може да бъде възможно да се изгради доста добър списък със служители на дадена компания. Ако след това нападателят може да определи имейл формата на компанията, като [email protected], тогава той всъщност може да събере голям брой акаунти, без изобщо да се свързва с уебсайта, който планира да атакува с тях.

Малко може да се направи срещу всяка от тези техники за събиране на сметка. Те са по-малко надеждни от първите методи, но могат да се използват за информиране на по-активни методи за изброяване на сметки.

Дяволът е в детайлите

Общото съобщение за грешка обикновено е решението за предотвратяване на активното изброяване на акаунти. Понякога обаче малките детайли издават играта. По стандарти уеб сървърите предоставят кодове за състояние, когато отговарят на заявки. 200 е кодът на състоянието за „OK“, което означава успех, а 501 е „вътрешна сървърна грешка“. Уебсайтът трябва да има общо съобщение, указващо, че е изпратено повторно задаване на парола, дори ако всъщност не е, защото не е имало акаунт с предоставеното потребителско име или имейл адрес. В някои случаи обаче сървърът все още ще изпрати кода за грешка 501, дори ако уебсайтът показва успешно съобщение. За нападател, който обръща внимание на детайлите, това е достатъчно, за да каже, че акаунтът наистина съществува или не съществува.

Когато става въпрос за потребителски имена и пароли, дори времето може да играе фактор. Уебсайтът трябва да съхранява вашата парола, но за да се избегне изтичането й в случай, че е компрометиран или има измамен вътрешен човек, стандартната практика е паролата да се хешира. Криптографският хеш е еднопосочна математическа функция, която, ако се даде един и същ вход, винаги дава същия изход, но ако дори един знак във входа се промени, целият изход се променя напълно. Чрез съхраняване на изхода от хеша, след това хеширане на паролата, която изпращате, и сравняване на съхранения хеш е възможно да се провери дали сте изпратили правилната парола, без изобщо да знаете паролата си.

Сглобяване на детайлите

Добрите алгоритми за хеширане отнемат известно време, за да завършат, обикновено по-малко от една десета от секундата. Това е достатъчно, за да затрудни грубата сила, но не толкова дълго, за да бъде тромаво, когато проверявате само една стойност. може да е изкушаващо за инженер на уебсайт да намали ъгъла и да не си прави труда да хешира паролата, ако потребителското име не съществува. Искам да кажа, че няма реален смисъл, тъй като няма с какво да се сравни. Проблемът е времето.

Уеб заявките обикновено получават отговор след няколко десетки или дори сто милисекунди. Ако процесът на хеширане на паролата отнема 100 милисекунди, за да завърши и разработчикът го пропусне... това може да бъде забележимо. В този случай заявка за удостоверяване за акаунт, който не съществува, ще получи отговор за приблизително 50 ms поради забавяне на комуникацията. Заявка за удостоверяване за валиден акаунт с невалидна парола може да отнеме приблизително 150 ms, това включва забавянето на комуникацията, както и 100 ms, докато сървърът хешира паролата. Като просто провери колко време е отнело отговорът да се върне, нападателят може да определи с доста надеждна точност дали даден акаунт съществува или не.

Подробно ориентирани възможности за изброяване като тези две могат да бъдат също толкова ефективни, колкото и по-очевидните методи за събиране на валидни потребителски акаунти.

Ефекти от събирането на сметка

На пръв поглед възможността да идентифицирате дали даден акаунт съществува или не съществува на даден сайт може да не изглежда като голям проблем. Не е като нападателят да е успял да получи достъп до акаунта или нещо подобно. Проблемите обикновено са малко по-широки по обхват. Потребителските имена обикновено са или имейл адреси, или псевдоними, или базирани на истински имена. Истинското име може лесно да бъде свързано с дадено лице. И имейл адресите, и псевдонимите също са склонни да се използват повторно от едно лице, което им позволява да бъдат обвързани с конкретно лице.

И така, представете си, ако нападател може да установи, че вашият имейл адрес има акаунт в уебсайт на бракоразводни адвокати. Какво ще кажете за уебсайт за нишови политически връзки или специфични здравословни условия. Подобно нещо всъщност може да изтече чувствителна информация за вас. Информация, която може да не искате там.

Освен това много хора все още използват повторно пароли в множество уебсайтове. Това е така, въпреки че почти всички са запознати със съветите за сигурност да използват уникални пароли за всичко. Ако вашият имейл адрес е замесен в нарушение на големи данни, възможно е хешът на вашата парола да бъде включен в това нарушение. Ако нападател успее да използва груба сила, за да отгатне паролата ви от това нарушение на данните, той може да се опита да я използва другаде. В този момент нападателят ще знае вашия имейл адрес и парола, която може да използвате. Ако могат да изброят акаунти на сайт, в който имате акаунт, може да опитат тази парола. Ако сте използвали повторно тази парола на този сайт, тогава нападателят може да влезе в акаунта ви. Ето защо се препоръчва използването на уникални пароли за всичко.

Заключение

Събирането на акаунти, наричано също изброяване на акаунти, е проблем със сигурността. Уязвимостта на изброяването на акаунти позволява на атакуващия да определи дали даден акаунт съществува или не. Като уязвимост при разкриване на информация, нейният пряк ефект не е непременно тежък. Проблемът е, че когато се комбинира с друга информация, ситуацията може да се влоши много. Това може да доведе до съществуването на чувствителни или лични данни, които могат да бъдат обвързани с конкретно лице. Може да се използва и в комбинация с пробиви на данни от трети страни, за да получите достъп до акаунти.

Също така няма законна причина даден уебсайт да изтече тази информация. Ако потребител направи грешка в своето потребителско име или парола, той трябва да провери само две неща, за да види къде е направил грешката. Рискът, причинен от уязвимостите в изброяването на акаунти, е много по-голям от изключително малката полза, която те могат да осигурят на потребител, който е направил печатна грешка в потребителското име или паролата.