Обхід блокування по IP на сайтах

22:44 31.08.2011

В статті Обхід капч та блокування на сайтах я розповідав про один з методів обходу капч та блокування. А зараз я розповім вам про обхід блокування по IP. Це друга стаття з серії статей про методи обходу блокування на сайтах.

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

При наявності на сайті блокування по IP (на годину, чи 24 годину, чи навіть постійно блокування), зокрема в формах аутентифікації, що спрацьовує після декількох невдалих спроб логіна, є можливість обійти дане блокування. Що стане в нагоді при Brute Force атаках.

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

Для проведення Brute Force атаки з обходом блокування потрібно зробити наступні кроки:

1. Створити робочий акаунт на цільовому сайті.

2. Виявити межу блокування - після скількох невдалих спроб логіна відбувається блокування (наприклад, 15).

3. Використати метод обходу для проведення Brute Force атаки з метою підбору паролів.

Суть методу зводиться до наступного. За звичай при блокуванні по IP рахується кількість невдалих спроб, яка обнуляється при вдалій спробі логіна. Тому потрібно періодично, до того як спрацює блокування, посилати запити з коректним логіном і паролем (до власного акаунту), щоб обнулити цей рахівник. Наприклад, при блокуванні після 15 спроб, варто посилати завідомо коректні аутентифікаційні дані після кожної 5 спроби.

І таким чином блокування по IP обходиться і можна нескінченно брутфорсити з одного IP. Тому розробникам захисних механізмів потрібно коректно їх реалізовувати.


5 відповідей на “Обхід блокування по IP на сайтах”

  1. Viktor каже:

    Просто і геніально!

  2. MustLive каже:

    Так, як і багато інших методів обходу захисних систем, таких як капчі та блокування, ;-) . Як і метод обходу описаний у вищезгаданій статті.

    Що цікаво, попередній метод (з яким я неодноразово стикався на протязі 2009-2011) і цей метод я застосував під час аудиту в липні на одному українському е-комерс сайті (мого клієнта). При тому, що цей сайт перед цим пройшов PCI DSS аудит у закордонних “спеціалістів” і таких проблем вони не виявили. Так що такі прості методи не по зубам стандарту PCI DSS і аудиторам, що працюють по ньому.

  3. guest каже:

    В требованиях стандарта PCI DSS нет требований по проверке описанных вами способов обхода блокировок. как и нет требований использовать вообще такие методы защиты от злоумышленников.

  4. MustLive каже:

    guest, хоть я и не знаком детально с PCI DSS, но мне хорошо известно, что в данном стандарте есть требование по проверке Brute Force уязвимостей. Причём не только выявлению таких уязвимостей, но и по проведению атак с их использованием (для выявления слабых паролей). О чём писал автор статьи Аудит по стандарту PCI DSS, о которой я писал в 2009 году.

    И соответственно аудиторы, тестировавшие сайт моего клиента, как и любые PCI DSS аудиторы, должны были удостовериться, что защитные механизмы от BF надёжны, а не просто увидеть их и сказать, что всё надёжно и данных уязвимостей на сайте нет. Потому что заявить об отсутствии дыр на сайте, где они есть и за выявление которых людям платили деньги (и немалые - PCI DSS аудит всё таки) - это профанация.

    Стандарт не должен описывать все методы обхода, он лишь должен сказать, чтобы эффективно проверяли (не поверхностно). Как наличие дыр, так и надёжность систем защиты - в том числе и капч и блокировок, о чём я писал в своих статьях. А учитывая, что в прошлом году у моего клиента на сайте была BF (которую я выявил), а в этом году, после PCI DSS аудиторов, были добавлены два уровня защиты (оба дырявых, которые я легко обошёл), то я предполагаю, что именно они посоветовали данные защитные механизмы.

  5. MustLive каже:

    You can read this article on English in The Web Security Mailing List: Bypassing of security mechanisms.

Leave a Reply

You must be logged in to post a comment.