Google использует своего «паука» FeedFetcher для кэширования любого контента в Google Spreadsheet, вставленного через формулу =image(«link»).

Например, если в одну из клеток таблицы вставить формулу

=image("http://example.com/image.jpg")

Google отправит паука FeedFetcher скачать эту картинку и закэшировать для дальнейшего отображения в таблице.

Однако если добавлять случайный параметр к URL картинки, FeedFetcher будет скачивать её каждый раз заново. Скажем, для примера, на сайте жертвы есть PDF-файл размером в 10 МБ. Вставка подобного списка в таблицу приведет к тому, что паук Google скачает один и тот же файл 1000 раз!

=image("http://targetname/file.pdf?r=1")
=image("http://targetname/file.pdf?r=2")
=image("http://targetname/file.pdf?r=3")
=image("http://targetname/file.pdf?r=4")
...
=image("http://targetname/file.pdf?r=1000")

Все это может привести к исчерпанию лимита трафика у некоторых владельцев сайтов. Кто угодно, используя лишь браузер с одной открытой вкладкой, может запустить массированную HTTP GET FLOOD-атаку на любой веб-сервер.

Атакующему даже необязательно иметь быстрый канал. Поскольку в формуле используется ссылка на PDF-файл (т.е. не на картинку, которую можно было бы отобразить в таблице), в ответ от сервера Google атакующий получает только N/A. Это позволяет довольно просто многократно усилить атаку [Аналог DNS и NTP Amplification – прим. переводчика], что представляет серьезную угрозу.



С использованием одного ноутбука с несколькими открытыми вкладками, просто копируя-вставляя списки ссылок на файлы по 10 МБ, паук Google может скачивать этот файл со скоростью более 700 Мбит/c. В моем случае, это продолжалось в течение 30-45 минут, до тех пор, пока я не вырубил сервер. Если я все правильно подсчитал, за 45 минут ушло примерно 240GB трафика.

Публикую краткий пересказ статьи. Советую прочитать ее полный текст на языке оригинала.

Panos Ipeirotis получил недавно счет от амазона на сумму более $1170, в то время как обычно сумма в его счетах значилась около $100.

Меня зовут Роб Стакл, я консультант по безопасности из Феникса, штат Аризона, и в основном работаю пентестером. Я участвую в конференциях DefCon с 1996 года, увлекаюсь высотной фотографией, а в эти выходные была одиннадцатая годовщина нашей свадьбы. Я хочу поблагодарить мою удивительную и понимающую жену Линду, которая не ожидала, что моё участие в DefCon означает, что каждый год я буду вынужден проводить годовщину нашей свадьбы в Вегасе, о чём я очень сожалею.



Я собираюсь поговорить с вами о нескольких вещах, связанных с исследованиями, над которыми я работал несколько последних лет. Их объединяет общая тема — если вы не мониторите свой DNS трафик и не понимаете, что там происходит, когда всё в порядке, то вы наверняка не обратите внимания, когда с ним начнут происходить плохие вещи. Я «насиловал» DNS в течение нескольких лет и это всегда было одним из моих любимых векторов атаки. Вы можете потратить целое состояние на упрочнение периметра сети, но если я могу получить контроль над одним из ваших устройств, поверьте мне, ваша игра закончена.

Конференция DEFCON 21. DNS может быть опасен для вашего здоровья. Часть 1

При этом предполагалось, что границы домена организации – это foo.com и вы никогда не захотите использовать www.com. Microsoft изменила это поведение DNS, потому что, очевидно, не все организации имеют два уровня для доменных имён.



Если ваш домен верхнего уровня – Великобритания, то при соединении с конкретным доменом ad.foo.co.uk поведение DNS по умолчанию будет выглядеть так:



То есть запрос будет отсылаться за границы вашего доменного имени на www.co.uk. Поэтому был создан случайный хотфикс, исправление безопасности, сужающее организационные границы домена до 3-х, и в этом случае деволюция DNS останавливалась после второго запроса www.foo.co.uk.