Хакер #305. Многошаговые SQL-инъекции
Большинство экспертов по безопасности призывают клиентов SecurID от RSA не
паниковать на счет взлома,
обнаруженного недавно. Но это не значит, что они не должны рассматривать худший
вариант: SANS Internet Storm Center предоставил список вещей на которые следует
обратить внимание в логах – вдруг плохие парни все-таки заполучили ключи от
королевства, украли ключ токена и затем смогли добыть логины и PIN-коды для
полного взлома твоей двухфакторной системы аутентификации.
Руководитель SANS ISC Даниэль Веземанн обстоятельно разъяснил, какие
особенные записи могут появиться в контрольном журнале RSA ACE сервера для
SecurID, если есть проблема. Но даже если злоумышленник захватил ключи от
SecurID токенов организации, ему придется выяснить ID пользователя и PIN-код для
входа в систему, заметил Веземанн, так что это может произойти лишь в худшем
случае. Его публикация последовала вслед за сообщением оператора ISC Роба
ВанденБринка, который вчера объяснил на сайте ISC SANS насколько плохо все может
быть.
"Короче говоря, неважно насколько серьезна была брешь в безопасности RSA, во
власти системных администраторов применить действительно эффективные меры для
снижения риска", – написал ВанденБринк.
Вот некоторые записи, которые, будем, надеяться ты не обнаружишь в логах ACE
сервера. Но если все-таки обнаружишь, берегись:
AUTH_FAILED_BAD_PIN_GOOD_TOKENCODE
Эта запись в журнале, возможно не должна вызывать особых беспокойств до тех
пор, пока не столкнешься с более чем двумя или больше на пользователя. Эта
ошибка возникает когда пользователь делает ошибку при вводе PIN-кода или,
например, пытается угадать его. "Обычно данная ситуация является достаточно
распространенной, просто потому что авторизованные пользователи иногда забывают
PIN-код или делают ошибки при его вводе. Если таких записей на один
идентификатор пользователя появится много, есть шанс, что после энной неудачной
попытки он закроется и никакого вреда нанесено не будет ", - заметил Веземанн.
AUTH_PRINCIPAL_RESOLUTION / AUTH_ALIASES_NOT_FOUND
Время от времени пользователь делает ошибку при вводе пользовательского ID.
Но если таких записей в контрольном журнале появляется несколько, возможно,
происходит что-то подозрительное: "Но если их много, и особенно если формат
имени пользователя совсем отличается от пользовательского ID, возможно кто-то
пытается угадать ваших пользователей при помощи телефонной книги или LinkedIn
аккаунтов", - сказал Веземанн.
NEW_STATIC_PCODE_AUTH_SUCCESS
Эта запись может появиться когда пользователь входит в систему при помощи
постоянного пароля, поскольку потерял свой токен или ему дали статический.
Однако это случается редко: "Существуют законные чрезвычайные ситуации для
такого рода входа в систему, но это, конечно же опасно, иметь такую опцию – если
кто-то может уболтать справочную службу, то он сможет зайти без токена ", -
сказал Веземанн.
