Всем привет! После успешного дайджеста новостей за 2014 год мы решили сделать рубрику регулярной, точнее – ежемесячной. Сегодня – самые важные новости информационной безопасности за январь. Методика выбора новостей немного изменилась. Мы по-прежнему берем самые посещаемые новости с нашего сайта Threatpost и пытаемся понять, почему они удостоились такого внимания. Но в ежемесячном дайджесте новостей будет пять. Напоминаю, что на Threatpost мы собираем все новости индустрии информационной безопасности. Собственные исследования «Лаборатории» публикуются на сайте Securelist.
Краткое содержание: Дыра в glibc и почему физики не дружат с лириками, северокорейский браузер, зарядка-кейлоггер и дыры в клавиатурах, криптолокеры в целом и в частности, взлом WiFi с социальной инженерией.
5. Wifiphisher: взлом WiFi с толстым слоем социальной инженерии
Новость. Тематический тред на Stackexchange, где проблема была сформулирована еще три года назад.
В предыдущем дайджесте мы говорили о том, что интернет – сломан. Так вот, из всего того, что сломано в интернете или скорее в компьютерных сетях в целом, больше всего сломаны беспроводные сети. Мы последовательно пережили святую простоту протокола WEP, неоднократно убедились в том, что незащищенные публичные беспроводные сети – это плохо, поглядели в бездонную дыру в безопасности по имени WPS. Теперь переживаем цунами багов в прошивках роутеров – то дефолтный пароль (или подобную дыру) в прошивке обнаружат, то криво написанный NAT, то еще что-нибудь. Короче, только социальной инженерии тут и не хватало.
Не хватало – получите. Все очень просто: достаточно создать в зоне приема жертвы точку доступа с точно таким же идентификатором SSID. Когда жертва попытается к ней подключиться, мы спросим у жертвы пароль к той, настоящей точке доступа, и аккуратно его сохраним. Ну и все, у нас есть доступ и возможность провести MITM-атаку. А, нет, не все. Сначала нужно уговорить компьютер или смартфон жертвы попробовать подключиться к нашей точке. А это мы сделаем, забивая эфир de-authentication пакетами: они приводят к отключению легитимных клиентов, которые дальше могут подключиться уже к фейковой точке доступа.
Еще одно обсуждение на Stackexchange дает понять, что проблема давно известна, и она (в части deauth packets) лечится плохо или вообще никак. В чем новость тогда? А в том, что процесс кражи паролей указанным методом автоматизировали, а соответствующую утилиту Wifiphisher выложили на Гитхаб. Мораль раз: когда у вас кто-то или что-то спрашивает пароль (неважно где), два раза подумайте, прежде чем вводить. Мораль два: нельзя защититься от атак man-in-the-middle, исключив саму возможность их проведения. Не получится исключить, по крайней мере – не в этом интернете.
К слову, deauth-пакетами в свое время баловалась сеть отелей Marriott, используя их для блокирования беспроводных точек доступа, которые приносили с собой постояльцы. И получила за это приличный штраф от американского Роскомнадзора.
4. Криптолокеры. Чем скрытая угроза отличается от явной?
Новость. Еще одна новость. Подробное исследование криптолокеров как вида.
Я уже писал, что если опросить компании, с каким видом киберугроз они сталкиваются чаще всего, то на первом месте скорее всего окажется спам. Но спам – это такая штука, ущерб от которой неочевиден. Он есть, но его сложно посчитать. А если посчитать сложно, то и оценить, насколько разумны затраты на борьбу со спамом, тоже нелегко. Тем более, что технологии борьбы со спамом неплохо проработаны, распространены и доступны.
Криптолокеры – это совсем другая история. В отличие от спама оценить ущерб от них легко. Вашу компанию атакуют, шифруют важные данные, делая их недоступными, и требуют выкуп. Вы теряете деньги. Вы теряете время. Более того, единственный инцидент может и вовсе убить вашу компанию, пример есть тут. Понятно, что защищаться от криптолокеров – надо.
С точки зрения преступности криптолокеры – это живые легкие деньги. Это не ботнет, который сначала надо построить, а потом еще продать кому-то. Поэтому, увы, криптолокеры активно развиваются, множатся и распространяются.
А в чем новость, собственно? Да ничего особенного :) Основные тенденции развития криптолокеров мы описали еще летом прошлого года (и продолжаем их исследовать). Этим же занимаются почти все секьюрити-вендоры, включая, например, Microsoft и Cisco. Работы там столько, что хватит всем. Например, в вымогателях задействованы все современные технологии сокрытия нелегальной деятельности: оплата биткоинами, коммуникации через Tor и I2P, маскировка от исследователей.
Но это не главное. Наибольший интерес представляют технологии проникновения на компьютер жертвы. Февральское исследование Cisco показало, что создатели одного из вариантов Cryptowall делают ставку на эксплойт-киты. Для бизнеса это означает, что слабым звеном инфраструктуры компании является уязвимое ПО. Не то, чтобы открытие века, но тема крайне важная: то, что почти каждая новость про криптолокеры вызывает огромный интерес, лишний раз это доказывает.
3. USB-зарядка со встроенным кейлоггером.
Новость.
Еще одна история о том, как сложно контролировать беспроводные коммуникации, началась с работы трех исследователей, решивших проанализировать защищенность беспроводных клавиатур Microsoft. Где-то в маркетинговых материалах к этим клавиатурам наверняка написано, что поток информации между устройством и USB-приемником надежно зашифрован. Таки да, но насчет надежности есть вопросы.
Если коротко, то ключом к зашифрованным символам является MAC-адрес клавиатуры, который, во-первых, можно подсмотреть, во-вторых – украсть удаленно, используя особенности чипа, отвечающего за передачу данных (и использующегося в разных устройствах, в том числе, упс, медицинских). А можно и не красть: первый байт MAC-адреса у всех клавиатур одинаковый, что сильно облегчает брутфорс.
Осталось понять, как подобраться к клавиатуре достаточно близко, чтобы на регулярной основе перехватывать нажатия клавиш. И вот здесь исследователь Сами Камкар предложил оригинальный proof of concept. Берем обычную USB-зарядку для смартфонов-планшетов, вставляем в нее соответствующим образом прошитый Arduino и получаем электрического троянского коня. Который кстати работает даже если зарядка не вставлена в розетку: небольшой аккумулятор тоже поместился. Себестоимость девайса – всего $10, и как же хорошо, что это (пока) только концепт.
Microsoft исследование не прокомментировала никак, точнее сказала, что «исследует проблему». А проблема-то интересная: сомневаюсь, что ее решит перепрошивка (и что она вообще возможна). Только замена устройства. Интересно, а что если такой «неизлечимый» баг обнаружится не в клавиатуре за $40, а в автомобиле за $70,000? Впрочем, я отвлекся.
2. В северокорейском браузере нашли бэкдор
Новость.
Впечатленный историей о взломе Sony Pictures Entertainment, исследователь Роберт Хансен решил внимательно изучить особенности северокорейского интернета. Напомню, Северная Корея, предположительно (аттрибуция — это вообще большая проблема), была инициатором атаки, обидевшись на то, что про ее лидера сняли, возможно, самую тупую комедию 2014 года.
В Северной Корее используется своя собственная операционная система на базе Linux, известная под именем Пульгынбёль Саёнджа Ёндчхеге или просто «Красная звезда». В качестве браузера – форк Firefox по имени Нэнара («Моя страна»). Исследуя браузер, Хансен обнаружил, что при каждой загрузке «Нэнара» стучится на локальный IP-адрес в изолированной северокорейской сети. Более того, вся сеть целой страны организована так, как обычно строится сеть компании: внутренние адреса, почти полная изоляция от внешнего мира и связь с ним только через прокси. Вероятно, с возможностью отслеживания всего трафика, включая зашифрованный: браузер принимает единственный сертификат – государственный, наверняка тоже имеющий какое-то романтичное название.
То есть весь необходимый инструментарий для слежки за пользователями в стране с единственным провайдером уже встроен в единственную доступную ОС. И происходит это в Северной Корее. Вот это да! Breaking News!
Конечно популярность этой новости связана исключительно с атакой на Sony Pictures Entertainment и вероятной причастности к данному мегахаку Северной Кореи. Но не только. Роберт Хансен раскрыл несколько приемов, разработанных теми ребятами, которые на самом деле знают, как запрещать и ограничивать вообще всё, не только интернет. Особенно интернет. Почитайте!
1. Уязвимость в GLIBC или Почему Важно Патчить
Новость. Запись CVE. Advisory от Red Hat.
Лирическое отступление. Одним из важных событий прошлого года стала дыра в OpenSSL, ныне известная как Heartbleed. Было очень интересно наблюдать за развитием событий: как абсолютно техническую тему сначала обсуждают в технических-же сообществах и изданиях, а потом она выплескивается в совершенно нетехнические медиа. И не зря! Проблема действительно затронула всех: владельцев бизнеса, админов, разработчиков, пользователей. В общем, огромное количество людей и компаний. Возникла и необходимость как-то просто и понятно объяснить нетехнарю (например, владельцу компании или топ-менеджеру): в чем собственно беда и что теперь делать?
И вот приходите вы к этому нетехническому человеку и говорите примерно так: Heartbleed – это важно, потому что OpenSSL, в котором обнаружена дыра, используется повсеместно. Ваш сайт может быть уязвим, ваша инфраструктура может быть уязвима, даже ваша личная почта на Yahoo может быть уязвима. Что значит «уязвима»? Могут украсть ваш пароль и почту. Могут заразить ваш сайт. Могут украсть ваши конфиденциальные данные. Что делать? Все патчить, все проверять, менять пароли, усиливать защиту инфраструктуры, потому что это не первая и не последняя дыра подобных масштабов.
И вот гуманитарий проникается, понимает и в ответ говорит: а где же вы мол, технари, раньше-то были? Почему не били в набат? Не давали объявление в «Таймс» и газету «Правда»? И в большинстве случаев выясняется, что таки да, предупреждали и обсуждали, и исследовали. Но в своем, техническом стиле. Если серьезно: чтобы оценить масштаб той или иной уязвимости, нужно понимать, в чем, собственно, заключается прореха в защите, знать, какие могут быть сценарии атаки, и уметь оценить потенциальный ущерб (что могут украсть и в каких масштабах). И это такие разные задачи, что занимаются ими, как правило, разные специалисты, и даже если им всем удается объединить усилия, они обычно не находят время на объяснение сути дела для широкой аудитории.
Вот и получается, что для нетехнического человека проблемы типа Heartbleed возникают как бы из ниоткуда.
Так вот, дыра в GNU C Library сейчас находится на «технической стадии». То есть уязвимость обнаружили, выяснили, что она действительно влияет на безопасность, и даже предположили некоторые сценарии атаки. А вот как оно может повернуться в реальной жизни на реальной инфраструктуре, и какой может быть ущерб – пока непонятно. В общем неподготовленный человек описание уязвимости видит сейчас примерно так:
Я попробую объяснить, что произошло в GLIBC, максимально просто. Сразу скажу: я не программист. Моя работа как раз заключается в том, чтобы объяснять сложные вещи просто достаточно широкой аудитории. Понятно, что Хабр – не то место, где нужно разжевывать нюансы работы с GLIBC. Мне бы очень хотелось услышать ваши комментарии к тексту ниже. Как бы вы решили задачу «объяснить просто»? Что бы вы сказали по-другому? Правильно ли я все объяснил? :) У маркетологов есть такой простой инструмент: они какую-то важную мысль пишут три раза: делают совсем короткий текст, еще один подлиннее и один совсем длинный. А потом, по обстоятельствам, используют один из них. Вот и я так попробую.
Короткая версия:
Надо регулярно обновлять ПО на компьютерах и серверах, это повышает безопасность. Недавно обнаружили серьезную дыру в Linux, и ее тоже нужно залатать, если у вы Linux используете.
Немного длиннее:
Уязвимость в GLIBC затрагивает почти все системы на базе Linux, теоретически позволяет выполнять произвольный код, и поэтому достаточно опасна. Пока реальных и действительно угрожающих сценариев атаки нет, но это не значит, что они появятся в будущем. Поэтому надо регулярно обновлять ПО.
И совсем длинная версия:
GLIBC – это стандартная библиотека языка Си для всех операционных систем на базе Linux. Она содержит большое количество программ, выполняющих стандартные действия: вывести что-то на экран, выделить область памяти для приложения и так далее. То есть ее используют те, кто пишет программы под Linux: вместо того, чтобы на каждую задачу писать свой код, они «берут» необходимую программу из GNU C Library. Таким образом разработчики и серьезно экономят время, и обеспечивают стандартизированный подход к решению типовых задач.
То есть прежде всего надо понимать, что GLIBC влияет на огромное количество программ: если в коде, хранящемся в библиотеке ошибка, то она может повлиять на работоспособность программы, использующей этой код. Если в коде есть уязвимость, то и программы, его использующие, также становятся потенциально уязвимыми. Ага?
Идем далее. Данная уязвимость была обнаружена в семействе функций gethostbyname. Это такие небольшие программы из коллекции GLIBC, которые выполняют одну простую задачу: получая на входе имя сайта (www.kaspersky.com) на выходе дают его IP-адрес вида 123.123.123.123. Если вашей программе нужно провести такую операцию (а это нужно почти любой программе, работающей с сетью), вы обращаетесь к данной функции.
Проблема в том, что функция недостаточно хорошо проверяет, что ей дают на входе. Как это обычно происходит: программа получает на входе данные, хочет записать их в специально выделенную под это дело область памяти определенного размера. И вообще не проверяет, поместятся ли данные в эту самую область или нет. Что получается? Данные записываются за пределы указанной области. Почему это плохо? Ну во-первых, за пределами нужной области памяти могут располагаться другие данные этой же или другой программы, и последняя может перестать работать. В лучшем случае. В худшем данные запишутся вместо кода, который требуется выполнить. И если нам удастся скормить «дырявой» программе кусок кода и сделать так, что он запишется как надо и куда надо: мы можем запустить какую-то свою программу (точнее произвольный код) на компьютере, никого не спрашивая.
Да, мне очень нравится эта картинка :)
Так, с постановкой проблемы определились. Какие могут быть сценарии атаки? Исследователи из компании Qualys показали, как можно выполнить произвольный код, используя данную уязвимость, когда к функции gethostbyname обращается почтовая программа Exim. Таким образом, мы теоретически можем атаковать почтовый сервер компании, использующий Exim и выполнить на нем произвольный код. Сможем ли мы благодаря этому украсть почту компании или получить доступ к важным документам или еще как-нибудь нанести какой-то реальный ущерб? Теоретически можем. Но учитывая все (не упомянутые тут) тонкости и оговорки, опасность применения уязвимости для кражи данных в реальном мире мы пока оценить не в состоянии.
И в этом заключается отличие уязвимости GLIBC от Heartbleed. Там мы имели явную и четкую угрозу, здесь эта угроза теоретическая. Рассказывая об уязвимости я опустил массу важных оговорок: и сама функция gethostbyname уже устарела, и условия для создания ситуации переполнения буфера очень специфические, а уж когда мы начинаем «примерять» уязвимость к использующим эту функцию программам, все вообще становится сложно.
Но это – пока. Есть вероятность, что кто-то (и хорошо, если это будет исследователь, а не киберпреступник) найдет способ быстро и легко ломать большое количество Linux-серверов с использованием данной уязвимости. И только тогда про уязвимость напишут журнал Forbes, газета «Жизнь», и снимет сюжет «Первый канал». Все расскажут о том, что ах как же так, дыра существовала с 2000 года и никто не заметил. Но будет поздно. Поэтому вывод: Патчить Важно. И важно закрывать обнаруженные уязвимости на собственных серверах даже в случае, если прямой опасности вроде бы нет.
Автор: f15
