Государственный университет Адамс. Как взламывать веб-сайты. Часть 1

Давайте поговорим о нашей следующей атаке. Расскажу, как серверы вас идентифицируют. Для этого между браузером и сервером используется протокол HTTP без сохранения состояния, когда общение с сервером происходит независимыми парами «запрос-ответ». Поэтому сервер вас забывает, как только установлена связь, и при следующем сеансе уже не помнит, кто вы такой.



Однако он помнит вас, пока вы пользуетесь веб-приложением, потому что когда вы кладёте в корзину вещи, которые собираетесь купить, то можете продолжить покупки и снова вернуться, чтобы просмотреть содержание своей корзины. Реализация «запоминания» происходит при помощи кукиз идентификации сеанса. Как только вы залогинились на сервере, он генерирует файл куки, который представляет собой уникальную последовательность букв и цифр, и отправляет его вашему браузеру, который сохраняет это куки локально на вашем компьютере. После этого браузер возвращает кукиз серверу с каждым вашим запросом на протяжение одного сеанса. Получая эти кукиз, сервер понимает, что за пользователь обращается к нему с данным запросом. Это самый распространенный способ идентификации пользователя, который пользуется веб-приложением.

Следующий тип атаки носит название «межсайтовый скриптинг», XSS. Идея этой атаки в том, что злоумышленник принуждает веб-сайт отображать вредоносный код, обычно в виде JavaScript, который затем исполняется в браузере пользователя. Такая атака может преследовать любую цель, но чаще всего используется для получения идентификатора сеанса жертвы. Ценность Session ID состоит в том, что его можно рассматривать в качестве пароля, так как он идентифицирует вас. Захватив идентификатор сеанса, злоумышленник может замаскироваться под вас, используя прокси-сервер для связи с целевым сервером. Целями такой атаки может быть желание выступать от вашего лица, автоматизировать какие-то действия, например, рассылку спама, от вашего имени, или внедрить вирус.

При поиске уязвимости межсайтового скриптинга XSS в веб-приложении вы ищите поле ввода, в котором можно поместить некоторую информацию, отослать её на сервер и посмотреть, какой результат отобразится в окне браузера.



Я неправильно ввожу расположение здания, указав Plachy Hall, адрес зала баскетбольной команды нашего университета. Веб-сервер получает эту информацию и соображает, что профессор компьютерных наук – это «ботан», который не может обитать в месте расположения спортивной команды, и выдаёт сообщение об ошибке: «Plachy Hall – это неправильно»!

Наиболее уязвимы в этом отношении окна поиска, куда вы можете ввести некоторые довольно неясные термины, а затем посмотреть, что получите в ответ. Чаще всего вам выдается подсказка с перечислением возможных правильных вариантов, которыми может воспользоваться злоумышленник.

Следующее, что вам нужно сделать, это проверить, сможете ли вы внедрить свой вредоносный код и затем его выполнить. Мы попробуем организовать XSS атаку при помощи JavaScript.



Код JavaScript всегда выделяется открытием и закрытием тега script, а также оператором OR. Разработчики приложений не совсем глупы, поэтому они установили механизм фильтрации, называемые «дезинфекцией». Он внедряется внутрь кода, проверяет, нет ли там опасных символов, и по возможности удаляет их. Простейший тест «дезинфекции» JavaScript выглядит так:

<script>alert(“Testing”)</script>

Но хакеры немного умнее, поэтому у них имеется сайт ha.ckers.org/xss.html. У меня нет времени, чтобы показать вам этот сайт, но там можно найти самые изощренные способы обхода элементов управления, которые разработчики приложений попытались вставить в свои программы, чтобы удалить опасные символы. Так что существуют довольно хитроумные способы, позволяющие хакеру проникнуть внутрь приложения.

Итак, давайте поговорим о том, как будет проходить XSS- атака. У нас имеется веб-сервер «Факультетских страничек», куда мы собираемся ввести вредоносный код. У нас есть Ева, которая собирается совершить взлом, но мы что-то пропустили на этом слайде – мы забыли про жертву. Что хорошего в XSS-атаке, это то, что вам не нужно никого для этого нанимать. Я имею в виду, что на этот раз не собираюсь быть жертвой, потому что у Евы есть мой пароль и она может сделать с моим аккаунтом все, что захочет. Поэтому Ева выходит из большой игры и больше не гоняется за маленькими мальчиками. Давайте выведем на сцену нашу жертву (смех в аудитории, потому что на слайде появляется фотография одного из профессоров факультета).

Теперь, когда жертва заняла своё место, давайте посмотрим, как будет развиваться атака. Предположим, что Еве удалось разместить вредоносный код JavaScript на сервере, куда собирается войти наша жертва, используя для этого свою учётную запись.

Это важно, потому что как только жертва залогинится на сервере, она получит идентификатор сеанса, который Ева постарается перехватить, это очень важная часть атаки. Итак, жертва запрашивает веб-страничку, которая содержит вредоносный код JavaScript, этот код выполнится в браузере жертвы и отправит Еве идентификатор сеанса.



Получив идентификатор сеанса, Ева может использовать свой прокси-сервер и делать всё, что захочет, маскируясь под жертву. Единственный недостающий кусочек мозаики – это сам вредоносный JavaScript, который хакер должен вставить в страницу и который должен захватить наш идентификатор сеанса жертвы и передать его злоумышленнику.

Это очень просто. У нас имеется код JavaScript, который начинается и заканчивается открытием и закрытием тега:

<script>

В первой строке кода создаётся рисунок точно так же, как в JavaScript динамически создается рисунок для любой страницы. Вы знаете, что в основе любой картинки находится файл, который содержит изображение, так что мы должны сказать браузеру, куда нужно пойти, чтобы получить эту картинку. На это указано во второй строке, где расположена ссылка на сайт хакера, однако браузер думает, что это именно то место, где находится нужное изображение. Он перейдёт на сайт Евы и попросит document.cookie, потому что считает, что это и есть нужный ему файл изображения.

Но это совсем не файл картинки, а идентификатор сеанса, который мы пытаемся захватить с помощью JavaScript. Как видите, раздобыть Session ID довольно просто. В третьей строке, которая не используется в коде для осуществления XSS-атаки, расположен сигнал тревоги, который вызывает всплывающее окно в браузере с сообщением об атаке. Это сделано специально для нашего примера, потому что реальная XSS- атака происходит совершенно незаметно для жертвы.



Итак, давайте пригласим Еву и посмотрим, как она будет совершать атаку межсайтового скриптинга.

Eve Hacker: благодарю вас, доктор Лавленд! Первое, что я должна сделать – это закрыть несколько не нужным нам вещей. Нам больше не нужен прокси-сервер Burp Suit, поэтому я его закрываю. Во-вторых, мне нужно перенастроить веб-браузер и переключить его на использование по умолчанию системных настроек прокси.

Теперь давайте перейдём на страницу входа сайта доктора Лавленд, потому что если вы помните, у меня есть ее пароль и я в любое время могу войти на сайт вместо неё. Как я уже упоминала, доктор Лавленд довольно ленива, она использует истекший SSL-сертификат, поэтому я должна подтвердить исключения безопасности, чтобы зайти на страницу входа в систему. Так как я знаю пароль, то могу редактировать ее веб-страницу. Как мы уже знаем, на странице редактирования персональной информации имеется уязвимость в строке Building Location, «Расположение здания», и именно сюда я собираюсь ввести свой вредоносный JavaScript.



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



(Ева надевает бейсболку, изображая профессора факультета Стивена Элдриджа)

Я только что вернулся с увлекательной встречи, где мы в нерабочее время обсуждали, какая машина должна пользоваться приоритетом на парковке – «Субару» или «Джип», а потом нам в голову пришла мысль, что разница может заключаться в наличии люка в крыше авто. Так что теперь мне нужно войти в систему и проверить свои контактные данные, потому что мне бы не хотелось пропустить следующую «внеклассную» встречу из-за того, что мои данные были недоступны. Итак, я авторизуюсь в своем веб-приложении под логином saldrich и своим паролем.



Итак, всё выглядит как обычно, я не вижу ничего плохого на своей страничке профессора математики, вся контактная информация в порядке.

О, боже, мои часы показывают, что до следующей встречи остается всего 2 минуты! Сейчас я собираюсь встретиться с доктором Лавленд, поэтому мне нужно зайти на её страничку и посмотреть, не смогу ли я накопать на неё какой-то компромат, чтобы упомянуть о нем при встрече. Итак, я жму на ссылку Susan Loveland, попадаю на её страницу и… доктор Элдридж, ваша страница взломана!



(профессор Элдридж снимает бейсболку, превращаясь в Еву)

Сейчас, когда у меня есть ваш Session ID, я могу использовать мой прокси-сервер и замаскироваться под вас, доктор Элдридж, делая всё, что захочу, от вашего имени. Передаю слово вам, доктор Лавленд!

Сьюзен Лавленд: благодарю вас, Ева! Я хотела упомянуть, что наше приложение «Факультетские странички» разработано на основе одного из новейших веб-фреймворков – Python Django Web Framework, имеющего отличную систему «дезинфекции» входных данных, которая удаляет из кода JavaScript опасные символы. Поэтому для того, чтобы Ева могла осуществить свою атаку, я исключила проверку значения поля Building Location на наличие таких символов.



Насколько успешными бывают атаки межсайтового скриптинга? Примерно 80-90% веб-сайтов имеют механизм контроля уязвимостей на стороне клиента. Неспособность противостоять атакам XSS является самой распространённой уязвимостью приложений Web 2.0, которые больше взаимодействуют с конечными пользователями.

Вероятно, вы слышали об одном из самых известных «червей» межсайтового скриптинга Samy, автор которого Сэми Камкар придумал в 2005 году, как обойти входную фильтрацию социальной сети MySpase. Он расположил на своей странице JavaScript, так же, как поступила с моей страницей Ева. Этот скрипт делал 2 вещи: добавлял Сэми в друзья жертве и копировал сам себя на страницу профиля жертвы. Сначала эта атака протекала очень медленно, потому что всего несколько человек зашли на страницу Сэми и добавились в друзья, но постепенно вирус распространялся всё больше и больше и заражение начало лавинообразно нарастать. Этот пример стал показательным в смысле возможностей XSS атаки, так как более чем миллион запросов в друзья за несколько часов «обрушил» сайт MySpase. Таким образом, последствия этих атак могут быть довольно серьёзными.

Последний тип атак, о котором я хочу сегодня рассказать, это атаки управления доступом, или атаки доступа. При такой атаке хакер хочет получить информацию, к которой не имеет доступа. Существует несколько уязвимостей, на которые направлен вектор атаки доступа.
Нередко разработчики приложений забывают, что они оставили файлы в корневой директории документа на веб-сервере, и если вы сможете обнаружить их существование, то получите возможность просматривать эти файлы, которые часто содержат конфиденциальную информацию.
Другой способ найти уязвимость — это очень внимательно изучите URL-адрес. Например, если вы видите адрес такого вида app.com/ViewDoc.php?docid=1280149120, то вполне сможете простым перебором цифр в конце ссылки получить документ, который не предназначен для ваших глаз.

Многие приложения рассчитаны на различные уровни пользователей и в них встроен соответствующий механизм доступа, который нередко основан за запросах с такими параметрами app.com/login/home.jsp?admin=false, поэтому вы можете попробовать войти на сайт, использовав в строке замену адреса на admin=true.

На самом деле наиболее распространенная уязвимость контроля доступа – это неправильная реализация функции авторизации. Сейчас Ева это продемонстрирует.

Eve Hacker: благодарю, доктор Лавленд. Чтобы осуществить последнюю атаку, просто нужно очень тщательно посмотреть на URL нашего веб-приложения. Сейчас я расширю окно приложения, чтобы строка с адресом на странице доктора Лавленд полностью поместилась на экране. Я должна избавиться от этого надоедливого JavaScript, который установила.

Мы видим, что адрес странички доктора Лавленд localhost/SampleSite/Faculty/index-1.html, а если мы переключимся на страничку доктора Элдриджа, то адрес станет таким localhost/SampleSite/Faculty/index-2.html.

Вам не кажется, что здесь используется одинаковый шаблон? Однако меня не интересуют эти адресные строки, потому что в них нет возможности ввода информации. Поэтому я хочу добраться до формы авторизации доктора Лавленд. Если я залогинюсь под её именем, то смогу редактировать её персональную информацию. Но давайте посмотрим на URL-адрес страницы, в конце которого имеется IndexForm-1, и вы можете догадаться, что возможно, здесь есть возможность добраться до формы данных доктора Элдриджа.



Итак, вопрос состоит в том, можем ли мы добраться до его формы без того, чтобы залогиниться от его имени. Давайте попробуем. Я меняю единицу на двойку так, что адрес принимает вид localhost/SampleSite/Faculty/indexForm-2.html, нажимаю «Ввод», и перед нами появляется страница с персональной информацией доктора Элдриджа.



Перед нами баг, который студенты доктора Лавленд забыли исправить – приложение имеет уязвимость, позволяющую проникнуть на чужую страницу без ввода логина жертвы.
Доктор Элдридж очень приятный человек, мне не хотелось бы его раздражать, я ничего против него не имею, но ради смеха всё-таки оставлю что-нибудь на его страничке. Давайте я искажу его имя и фамилию, а заодно исправлю должность с «Профессора» на «Младшего преподавателя».



Сейчас я отправлю исправленную персональную информацию на сервер, и если теперь войти на страничку Элдриджа, то на ней можно увидеть внесенные мной исправления.



Так что, доктор Лавленд, если у вас будут проблемы с доктором Элдриджем, когда он вздумает задержать вас после лекций, просто скажите, и я вообще удалю всю его информацию!
Сьюзен Лавленд: спасибо за поддержку, Ева! Я хочу поговорить об уязвимости контроля доступа буквально еще одну секунду. Для людей, которые, как и я, любят копаться в коде, объясню, что произошло во время этой атаки.



На этом слайде показан метод заполнения формы с персональной информацией. Последняя строка – это именно то, что интересовало Еву. Этот класс защищает form_index от быстрых функций @login-required и @authUser и проверяет, чтобы каждый, кто хочет изменить значения в полях формы, должен для этого залогиниться в системе. Однако разработчики забыли об этом и не добавили обязательное упоминание этих быстрых функций в контексте заполнения формы.
Показанный код проверяет, соответствует ли запрошенная форма лицу, которое авторизовалось в системе, но поскольку его не использовали правильным образом, Еве удалось обнаружить в приложении эту уязвимость.

Замечу, что 78% всех сайтов имеют уязвимость доступа. В апреле прошлого года некие хакеры обнаружили уязвимость в университетском кампусе Berkeley – это были скрытые файлы, которые разработчики оставили на сервере документов веб-сервера. Хакеры смогли просмотреть эти файлы и раздобыть номера социального страхования и конфиденциальную медицинскую информацию более чем 160 тысяч человек. Так что вы видите, насколько серьезными могут быть последствия атаки контроля доступа.

Мне бы хотелось упомянуть ещё несколько интересных фактов в контексте темы нашего сегодняшнего разговора. В последнее время резко возросло внимание государства к вопросам кибербезопасности. Так, Министерство обороны только в 2008 году зафиксировало более 360 миллионов попыток взлома. На совершенствование системы кибербезопасности в сфере информационных технологий в 2010 году планируется затратить около 75,8 миллиардов долларов, что на 7,2% больше, чем было затрачено на эти цели в 2009 году. По сообщениям журнала CNN Money Magazine, в 2009 году в США специалисты по интернет-безопасности входили в топ самых востребованных профессий. Средний годовой доход консультантов в области компьютерной безопасности составил 99,7 тысяч долларов, максимальный – 152 тысячи долларов. По прогнозам, потребность в таких специалистах с 2006 по 2016 год увеличится на 27%.

Хочу сказать, что на факультете компьютерных наук недавно появилась возможность получить степень младшего специалиста Internet Computing & Network Security, так что это отличная отправная точка для того, чтобы начать карьеру в этой области.

(надевает Черную Шляпу)

Eve Hacker: хочу на минуточку прервать вас, доктор Лавленд! Для будущих преподавателей, присутствующих в этой аудитории, замечу, что если вы освоите эту специальность и когда-нибудь окажетесь в ситуации, когда не получите обещанной прибавки к зарплате, то вы всегда сможете обратиться к мафии и выполнить для них взлом по контракту. Это станет отличной прибавкой к зарплате преподавателя компьютерных наук.

(снимает шляпу)

Сьюзен Лавленд: я хочу поблагодарить людей, которые внесли серьезный вклад в создание сегодняшней презентации, разработчиков «Факультетских страничек». Думаю, что благодаря их тяжелому труду я смогу покинуть эту аудиторию без наручников и эскорта полиции кампуса. Единственный «выживший» член этой группы – это Райан Голдсуорси, сыгравший важную роль в развитии этих страниц. Хочу поблагодарить доктора Стивена Элдриджа за его чувство юмора и представление личной странички для демонстрации атак, высказать благодарность заведующим кафедрами, которые внесли щедрый вклад в мой проект «Факультетских страничек», а также поблагодарить Службу компьютерных вычислений кампуса за то, что они защищают нас от таких людей, как Ева.

Благодарю за внимание.


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас оформив заказ или порекомендовав знакомым, 30% скидка для пользователей Хабра на уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps от $20 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps до весны бесплатно при оплате на срок от полугода, заказать можно тут.

Dell R730xd в 2 раза дешевле? Только у нас 2 х Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 ТВ от $249 в Нидерландах и США! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?