Был я в том офисе — там ещё на этажах холодильники с коробочками вкусного мороженого и газировкой, так же — все на халяву, + ещё гитар хиро, библиотека, комната релаксации с водой 8) Достаточно забавно все это сделано…
даже очень-очень-очень… сложно 8) Так что стабильного, крутого эксплойта не будет… зато паники по Интернетам… уууу….
Если прикинуть, то даже DoS эксплойт геморройный… надо послать 2^32 (например, если unsigned int в x32) UDP пакетов, что бы задосить сервак, обнулив счетчик.
Ну в Хроме есть флэш, например. Флэш тот — в ослабленной песочнице работает. Собственно ребята из Vupen продавали эксплойт который делал стабильный RCE в Гугл Хроме через багу в флэше. www.vupen.com/demos/VUPEN_Pwning_Chrome.php
Есть некий счетчик, при каждом «специальном» UDP пакете этот счетчик увеличивается. Соответственно когда таких пакетов очень много, происходит integer overflow и счетчик становится == 0. В этот момент и происходит free, а так же, происходит (пере)выделение памяти для новой структуры (так как счетчик ==0, значит надо выделить памяти… типа). Вот в этот момент и происходит где-то ошибка с текущим указателем на структуру. Вроде как указатель есть, а указывает черт знает куда (теоретически туда можно запихнуть поддельные данные с указателем на r0-шеллкод). Ходит слух, что ошибка завязана на функцию счетчика ICMP ответов (если порт закрыт, шлется ICMP сообщение об этом)- ippRateLimitICMP. В любом случае, подождем PoC… уж скоро должен быть. Хотя, ИМХО, RCE стабильный эксплойт сделать будет очень сложно 8)
Думаю, проблема решается настройкой МЭ роутера — фильтр на 22 и 80 порты на внешнем интерфейсе… (если действительно нельзя отключить службу на внешнем интерфейсе...)
А у меня другой опыт, положительный, с отечественным хостингом виртуальных серверов. В админке был перловый баг отсутствием фильтрации для open — ;ls|, причем админка то не на гостевой ОС бегала, а на основном хосте. Дали за это 5-7(стоимость месяца) баксов и спасибо сказали. Исправили ошибку то ли в тот же день, то ли на следующий.
Вывод: Компании разные бывают и реакция у всех разная.
Поставить валидную ЭЦП на левую платежку в ситуации, когда ПК клиента заражен — вопрос решенный.
Дальше только нужно, что бы операционистка не заподозрила левак и, конечно, что бы клиент не проверил счет. Если эти два фактора true, тогда дела в шляпе. Платежка уйдет в АБС, и дальше только ждать, в надежде что клиент не заметит палева.
Отсюда вывод:
Сложно не затроянить ПК и поставить ЭЦП на платежку, а обмануть клиента, что бы он эту платежку не видел хотя бы дней 5.
1) Защита КБ обходится. Факт. Причем не только клиента.
2) Второй таск: обойти фрод-мониторинг, который в большинстве случаев осуществляет девочка-операционист. Решается.
3) Человека, конечно, будут искать. И иногда находят.
А вот это, кстати, тоже ДоС. Только не на сервер а на клиента:
1) Пользователь получает малварю через что-то.
2) Малваря гадит.
3) Малваря компрометирует клиента (попытками ДоС атаки или чем-либо ещё)
4) Сервер блокирует клиента
=>
6) Клиент не может подключится к БК и узнать как там у него дела — так как заблокирован.
— Или например так, шлем клиенту 2к СМСок. Тогда СМСка об действии со счетом не достигнет цели 8) Кроме того, клиент не сможет воспользоваться, например, OTP для доступа к счету.
Мораль: ДоС бывает разным, так и цели у него бывают разные
Сколько — По классам уязвимостей.
или по CVSS2 (если кто-то мучался и считал).
Так же интересно, сколько было коллизий (когда ресерчер сообщает багу, о которой, ранее уже сообщал другой ресерчер)?
Если прикинуть, то даже DoS эксплойт геморройный… надо послать 2^32 (например, если unsigned int в x32) UDP пакетов, что бы задосить сервак, обнулив счетчик.
www.vupen.com/demos/VUPEN_Pwning_Chrome.php
Вывод: Компании разные бывают и реакция у всех разная.
Я же говорил, опыта мало 8)
Поставить валидную ЭЦП на левую платежку в ситуации, когда ПК клиента заражен — вопрос решенный.
Дальше только нужно, что бы операционистка не заподозрила левак и, конечно, что бы клиент не проверил счет. Если эти два фактора true, тогда дела в шляпе. Платежка уйдет в АБС, и дальше только ждать, в надежде что клиент не заметит палева.
Отсюда вывод:
Сложно не затроянить ПК и поставить ЭЦП на платежку, а обмануть клиента, что бы он эту платежку не видел хотя бы дней 5.
2) Второй таск: обойти фрод-мониторинг, который в большинстве случаев осуществляет девочка-операционист. Решается.
3) Человека, конечно, будут искать. И иногда находят.
ДоС немного не ДДос…
А ДДос да, конечно. один клиент не может…
1) Пользователь получает малварю через что-то.
2) Малваря гадит.
3) Малваря компрометирует клиента (попытками ДоС атаки или чем-либо ещё)
4) Сервер блокирует клиента
=>
6) Клиент не может подключится к БК и узнать как там у него дела — так как заблокирован.
— Или например так, шлем клиенту 2к СМСок. Тогда СМСка об действии со счетом не достигнет цели 8) Кроме того, клиент не сможет воспользоваться, например, OTP для доступа к счету.
Мораль: ДоС бывает разным, так и цели у него бывают разные
—
P.S. И это не секурно: дата рождения не особо «секретная» информация.
// это так, общая информация, раз уж тема такая… 8)