вторник, 26 ноября 2013 г.

СОИБ. Анализ. Мобильная опасность

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

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

В этот статье предположим, что произошел несанкционированный доступ к вашему устройству и ещё раз пройдемся по наиболее опасным рискам.

Несанкционированный доступ произошел по одному из трех сценариев (их вероятность достаточно большая, чтобы сказать что с каждым мобильным устройством произойдет как минимум 1 из этих сценариев):
·        Устройство потеряно/украдено
·        Пользователь самостоятельно установил вредоносное ПО (по ошибке или в результате обмана)
·        Вредоносное ПО установлено в результате эксплуатации уязвимости в системном или прикладном ПО

Начнем с персональных рисков:
P1. Вы лишитесь  денег на личном счету у оператора связи.  Для начала это будут прямые переводы между номерами (но, как правило, есть суточные лимиты, например 3000 руб.). POC =

Далее  могут совершаться звонки на платные телефоны или загрузка платного контента со своих же ресурсов, оплата каких либо услуг  или даже перевод на другой банковский счет (POC = https://oplata.megafon.ru/order/1767781) пока ваш счет не опустеет.

Р2. Если вы пользуетесь “Интернет банком” со своего мобильного устройства, то ваш возможный ущерб равен сумме на вашем счету. Простенького кейлогера достаточно чтобы перехватить логин и пароль (POC = http://www.android-keylogger.net/).  Большинство интернет банков если использует усиленную аутентификацию платежей, то по SMS-сообщению, которое придет на то же мобильное устройство/ или OTP приложение на том же мобильном устройстве.
Если вы пользуетесь “Мобильным банком, с управлением через SMS), то не потребуется даже кейлогера. Для перевода на другой счет в том же сбербанке достаточно будет отправить SMSPOC =

А можно по SMS перевести и на карту любого банка. POC  =


P3. Вы можете потерять даже больше средств, чем у вас есть на данный момент.
Для этого придумана услуга автоплатеж. Если вы уже подключили себе эту услугу у мобильного оператора или пользовались интернет банком, то злоумышленник так-же воспользуется этой услугой и подключит свои 10 номеров с правилом перечислить 10000 руб. если баланс телефона опустится ниже 10000 руб. Как только вы разблокируете свой счет/карту после инцидента и получите очередную зряплату с вашего счета продолжат уходить деньги.
POC =



А ещё мобильные операторы придумали личные кабинеты  и различные сервисы (POC = https://oplata.megafon.ru/) которые будут захвачены в момент несанкционированного доступа к телефону. Если вы ещё пользовались этими сервисами, то первый пароль придет по SMS. Если вы уже пользовались сервисом, то новый пароль так-же будет сброшен по SMSPOC =


Если после инцидента, вы забудете перехватить какой-то из сервисов, то злоумышленник продолжит снимать деньги и наносить ущерб. Кроме вывода денег личный кабинет дает ещё следующие интересные возможности:
·        переадресация входящих вызовов

·        отправка SMS от имени пользователя


И конечно злоумышленник отключит все уведомления пользователя, отключит проверку защитного кода. Не забудьте всё это включить. POC =

Р4. Если вы вводили реквизиты банковской карты со своего мобильного устройства, то вашими средствами будут пользоваться и после инцидента. Пока вы не уничтожите или перевыпустите банковскую карту.
Даже если банковскую карту вы уничтожили сразу после инцидента, деньги могут продолжать убывать. Например, при бронировании гостиницы онлайн указывает номер банковской карты, а деньги  списываются не сразу, а после оказания услуг. Таким образом, счет пользователя может уйти в глубокий минус.

P5. Вы потеряете данные и доступ ко всем популярным персональным приложениям, которыми пользовались с мобильного устройства - Электронная почта, соцсети, службы мгновенных сообщений, облачные хранилища файлов, фотографий, электронные деньги и кошельки, аукционы, службы бронирования, службы доставки, онлайн игры и т.п. Потеряете даже доступ к госуслугам. POC =

А всё почему? Потому, что все сервисы позволяют сменить пароль, используя электронную почту или sms на телефон. В редких случаях нужна  почта и SMS одновременно. Но на вашем мобильном устройстве как раз установлен автоматический вход в вашу почту и на него же приходят SMS.

Самые хитрые злоумышленники потом продадут вам доступ к вашим персональным приложениям. POC = http://www.cnews.ru/top/2013/11/20/ostanovleny_hakery_vymogavshie_dengi_za_razblokirovku_vkontakte_i_odnoklassnikov_550482

P6. Вы потеряете данные и доступ ко всем данным, хранящимся локально на мобильном устройстве. А это контакты, история смс, фото, видео, записки, календарь, локальные документы.
Причем самые хитрые злоумышленники зашифруют все ваши данные и потом будут продавать доступ к ним.

P6. Если вредоносное ПО будет скрытным, то какое-то время вы будете отдавать персональные данные злоумышленнику:   а именно -  информацию о местонахождении (небольшой автоматический анализ выявит ваш адрес работы, дома и других часто посещаемых мест), любой вводимый текст, содержание звонков, запись с звука микрофона, фото и видео с мобильного устройства в любой момент.

Это все персональные риски, которые мне удалось осознать. Возможно, я что-то упустил? Тогда поправьте. Про корпоративные риски в следующей статье.

Так-же мне интересует, какие риски лично для вас будут неприемлемыми и остановят Вас от использования какого-то сервиса?   Электрошоковый удар? Потеря авто/недвижимости? Условный срок  за участие в DDoS атаке?

PS: Интересно будет послушать на Антифрод Раша 2013 как предлагается уменьшать эти риски.
PPS: Proof-of-concept


воскресенье, 17 ноября 2013 г.

Общее. Inbar Raz, Roman Korkikian и Adrian Furtuna после ZN (UPDATE)

В продолжение предыдущей заметки после ZN, задал несколько вопросов ещё трем  экспертам приезжавшим издалека на ZeroNights:  Inbar Raz, Roman Korkikian и Adrian Furtuna.

Roman Korkikian из Kudelski Security (Швейцария), проводил workshop "анализ по времени"

·        Ты только что вернулся с конференции ZeroNights. Какие впечатления? Что понравилось, а что нет? 
Если говорить на чистоту, то в России есть всего три конференции по ИБ, которые я посещаю/хотел бы посетить: ZeroNights, PHD и РусКрипто. И если последние две все чаще становятся маркетинговыми площадками, то первая все еще чисто техническая. В плане организации претензий нет. Даже залы, расположенные рядом с друг другом, не раздражали, когда звук с нескольких докладов перекрывался. Это технический момент и они бывают на разных конференциях.
Организаторам я бы посоветовал публиковать материалы на русском и английском языках, чтобы на них можно было ссылаться (своего рода proceedings), это удобно и практикуется многими площадками. 

·        Ты проводил workshop по криптоанализу DES и AES. Можешь ли сказать что эти криптоалгоритмы небезопасны?
Когда упоминается слово криптоанализ, то люди сразу представляют сложные математические выкладки по оценке стойкости, непонятные Rainbow и Differential cryptanalysis и вообще самые скучные уголки криптографии. К сожалению, атаковать криптографические алгоритмы можно и другими способами, что я и пытался рассказать в своей работе. Нужно рассматривать не просто сам алгоритм, а его реализацию. В конечном счете любой алгоритм должен где-то выполняться. Среду выполнения я обычно именую "железом" - это может быть специальная аппаратная реализация алгоритма или код, который выполняется на процессоре/смарт карте/микроконтроллере. Очевидно, что в железе криптографический алгоритм это всего лишь набор сигналов, которые можно измерить: изменение температуры, излучение фотонов, изменение напряжения, электромагнитное излучение и время. Ну, если представить совсем просто, то когда происходит перезапись в регистре памяти с 0 на 1, то напряжение устройства падает; или если алгоритм выполняется только тогда, когда один из битов равен 1, то тут может быть различное время выполнения для разных исходных текстов. Используя эти "физические" данные можно вычислить секретный ключ алгоритма. Такие атаки называются Side Channel Attacks (в русском нет устоявшегося термина, можно встретить и атаки по второстепенным каналам и атаки по побочным каналам). Очень часто интуиция говорит, что такие "физические" изменения настолько малы, что их невозможно заметить или рассчитать. К сожалению, интуиция врет. Такие атаки успешно проводятся различными компаниями: Cryptography Research, Riscure и другими. Вся их суть в том, что собирается очень много данных по результатам шифрования (в моем воркшопе это было 50 000 000 для AES и DES) и уже затем они определенным образом обрабатываются. Т.е. уязвимость не в самом алгоритме, а в его реализации.
И если, наконец, отвечать на твой вопрос, то алгоритмы DES и AES НЕ являются НЕБЕЗОПАСНЫМИ, а вот их конкретные реализации могут быть уязвимы. Чтобы понять все источники уязвимостей нужно потратить много времени и сил, но как я обычно говорю, если у вас на руках есть устройство, которое выполняет алгоритм с заданным ключом, то этот ключ можно всегда вытащить (цену вопроса мы не рассматриваем).

·        Какие криптоалгоритмы советуешь использовать? 
Я не советую использовать RSA и DES, а вот все остальные алгоритмы, которые работают с ключом более 80 бит - вполне.

·        Ходят легенды, что спецслужбы разных стран при реализации криптоалгоритмов заставляют использовать "неслучайные" датчики случайных чисел. Как это может сказаться на безопасности криптоалгоритмов?
Это может сказаться очень плохо. Очень часто защита криптографических алгоритмов строится вокруг датчиков случайных чисел. Типичный пример это masking, когда вначале к исходному тексту добавляется случайный вектор, а затем происходит выполнение алгоритма и параллельно с ним перерасчет этого вектора, чтобы в конце получился реальный шифротекст, как будто ничего не добавлялось в начале. Masking основывается на случайных числах и такая защита есть в очень многих устройствах. Если знать маску (случайный вектор), то можно спокойно применять Side Channel Attacks без каких бы то ухищрений (существуют специальные атаки на masking но они довольно сложны). 
Я хотел бы заметить, что очень часто "спецслужбам" не нужно встраивать "неслучайные" генераторы случайных чисел, ибо работу этих генераторов можно слегка изменить из вне. Например, разместить около генератора источник сильного электромагнитного напряжения, или облучать генератор лазером. В этом случае, числа будут уже не такими случайными, как кажется. Вообще это тема отдельной статьи. С датчиками есть еще другая проблема, что им зачастую нужно зерно (seed), значение которое подается на генератор (на С это зерно задается командой srand(seed)). Если будете создавать случайные числа с одним и тем же зерном, то получите одни и те же "случайные" числа.
Окончательно отвечая на твой вопрос: любые неслучайные генераторы чисел катастрофически вредны для криптографии, но спецслужбам нет необходимости заставлять использовать "неслучайные" генераторы, если они могут влиять на работу устройства (хотя конечно неслучайные датчики значительно упростят работу криптоаналитика).

·        В досье ZN написано что ты занимаешься анализом уязвимостей смарт-карт. Безопасны ли смарт-карты в целом, а если нет, то какую альтернативу посоветуешь?
Все зависит от системы, реализации и среды. Нельзя говорить что в целом смарт-карты уязвимы или безопасны. Я бы не использовал смарт карты (мы говорим именно о смарт картах) там, где нужна безопасность (связь специального назначения, системы доступа и т.д.). Вместо них я бы использовал специальные аппаратные реализации алгоритмов и 32х битные процессоры. Во всех остальные приложениях (метро, гражданская связь и т.д.) замены смарт картам по критериям удобство-стоимость-защищенность, сейчас нет.

Adrian Furtuna, консультант по безопасности из румынском отделении KPMG, читал доклад "Практическая эксплуатация уязвимостей округления в приложениях для интернет-банкинга"

·        You just got back from a conference ZeroNights. What are your impressions? What you liked and what is not?
I came back to Romania with a very good impression about the ZeroNights 2013 conference. The organizers did an awesome job and the quality of the talks was impressive. I was amazed to see that so many young people are interested in low level aspects of computer security, mainly reverse engineering and finding operating system bugs. Another nice thing was the real-time translation from Russian to English which permitted non-Russian attendees to understand the Russian talks pretty well. The only drawback that I saw was the artificial split of the conference room in two parts, which allowed the speakers from one room to be heard in the other room.


·        Did you make a report about the Practical Exploitation of rounding vulnerabilities in banking applications. Do you have any information, the percentage of banks are now vulnerable. Can you give some examples?
I found the rounding vulnerability in at least five different banks that I tested in Romania as part of KPMG’s penetration testing engagements. However, these were not local banks but branches of international banks. The names are not important (they already fixed the problems anyway) but the situation might be present at other banks also. This is specific to the internet banking application itself, not to the country, nor to the global bank. Anybody having an internet banking account can check if his bank is vulnerable to this attack by trying a foreign exchange transaction with a very small (sub-unitary) amount. If the transaction is accepted and the final amount is rounded to the upper value, then the bank might be vulnerable. See my conference slides for more details.

·        What advice would you give to banks to counter such threats?
There are a few measures that the banks should implement in order to be protected against this type of attack. One measure would be to deny sub-unitary amount transactions in order to make the attack non-profitable. Another measure is to limit the maximum number of transactions that are permitted for a regular user in a day. Furthermore, the bank should state in the contract that automating transactions is illegal and they should monitor for suspicious transactions with very small amounts.


·        What do you think how often it is necessary to carry out pentest? For example banks. Is it possible to survive without Pentest?
I believe that security testing must be done at every major change in an application/system or at least once a year for stable systems. This is because new vulnerabilities and attack vectors are discovered every day and a system considered secure today might be vulnerable tomorrow without actually making any change in it. The risk is even higher for financial institutions which are constantly targeted by attackers and these companies should be more aware of the need for penetration testing services. Regarding survival, you can take a look at Adobe which was recently breached and 38 million user details/credentials were leaked. It survives but its reputation is pretty damaged.

Users wanting to do simple security tests for their own external facing infrastructure or applications can use a set of free online tools on website that I am running. For more advanced testing, companies should call for specialized people and not rely only on automated tools.


Inbar Raz, Malware & Security Research Manager в Израильском отделении Check Point, проводил FastTrack Физическая(не)безопасность: не ТОЛЬКО „кибер” 

·        Q: you just got back from a conference ZeroNights. What are your impressions? What you liked and what is not?
A: I was impressed with the professional level of the talks, from the number of participants and from their relatively young age.
    I was also happy to see a large number of women, as sadly there are not many women in our profession.
    As a foreigner, I felt uncomfortable with the number of talks that were given in Russian. I think that the security experts community should encourage people to improve their English skills, because that is later used as a facilitator for cooperation with colleagues all over the world. 

·        Q: you made a fasttrack about the Physical (In)security. Why and when did you interested in physical security of computer systems?
A: It is my impression that this field receives very little attention from researchers. As a result, fewer disclosures ae published and the industry does not improve itself (this is really the whole purpose of disclosing vulnerabilities). Also, for me it’s very easy because I need nothing more than my eyes to detect an opportunity for a research, so it means I see problems all the time… 

·        Q: except for the cases shown in the fasttrack, what other interesting cases of physical insecurity, you met?
A: Pretty much anywhere you look you will find problems, from small offices to corporates, from open/public spaces to secure zones, from private businesses to national infrastructure. The purpose of my talk is raise the awareness to the problem. 

·        Q: what are the main steps do you recommend to protect computer systems in public places?
A: Obviously, the best thing would be to hire a skilled security research to find problems and point them out. But other than that, these are my recommendations:
-          Do not trust the public. You must assume people will always try to hack you.
-          Never use default settings. Get a security expert to go over all settings (security related or not) with you.
-          Prevent physical access to all elements of your network. From end-point to servers, including the network cables.



PS: также рекомендую почитать отчет про ZN  от Артема Агеева и отчет Александра Панасенко





вторник, 12 ноября 2013 г.

Общее. ESET после ZN (UPDATE)


На недавно прошедшую конференцию ZeroNights приезжала куча иностранных экспертов. Мне удалось выловить и взять интервью у руководителя группы Security Intelligence лаборатории и блогера ESET Роберта Липовски, который также приезжал на ZN из Словакии.

·        Ты только что был на конференции ZeroNights. Понравилось?
Роберт: Да, мне понравилось. Очень высокий уровень докладов. Специалисты ESET, 2 из Словакии и 2 из России, cделали четыре выступления  - 2 доклада, FastTrack и Workshop. Я в этот раз не выступал с докладом.
(UPDATE) “Hard to compare to other recent conferences – for example, I attended Virus Bulletin in Berlin in October, and it had some very interesting talks, but both of these conferences were aimed at different audiences. Zeronights was a lot more technical. Lots of low-level stuff was presented here on subjects such as the Windows kernel, virtualization, sandboxing, etc. You don’t see such in-depth presentations in many conferences. And I especially liked the workshops – Aleks Matrosov and Eugene Rodionov, for example, had a workshop on analyzing object-oriented code. All-in-all, it was a great conference for a reverse engineer. But mostly for Russian speakers, even though the interpreters were doing a fine job”


·        Чем ты занимаешься в ESET?
Исследую наиболее интересные экземпляры вредоносных программ (malware).
Для антивирусной лаборатории – главное это своевременно обнаруживать вирусы. Но если обнаруживаем что-то интересное, то делаем детальный анализ и потом публикуем информацию в блогах или рассказываем на конференциях.

·        Из последних наиболее интересных вирусов что вы анализировали?
Самыми сложными были образцы, которые исследовали в нашем российском офисе – TDL, Zeroaccess, Filecoder.
Из моего личного опыта – недавно мы рассматривали банковский троян Hesperbot, который похож по назначению на известные Zeus и SpyEye, но технически по-другому реализован.

·        На сколько распространены банковские трояны и наносят ли они реальный ущерб?
Троян Hesperbot был нацелен на банки, в ограниченном количестве стран (в Чешской республике и нескольких других европейских стран). Обычно цель трояна определяется его конфигурационными файлами. И одно и то же вирусное ядро с разными конфигурациями может быть направлено против разных банков.
Мы взаимодействовали с многими банками чтобы оценить нанесенный ущерб, но я не могу назвать вам этих цифр. По моему мнению, ущерб от банковских троянов очень велик. Если вас интересуют цифры - вы можете почитать отчет Group-ib.

·        Актуальны ли сейчас трояны для мобильных устройств
Сейчас мы ведем активную статистику по Android, так как для этой платформы уже много прецедентов и достаточно данных для анализа (ниже общая статистика за последние 24 месяца).  Мобильные банковские трояны пока очень небольшая группа на фоне других мобильных троянов. Но такие трояны наиболее опасные, так как позволяют перехватить аутентификацию пользователя по всем каналам (http, sms, voice, mobile otp) например, Hesperbot. В то время как обычные банковские трояны не могут справиться с двухфакторной аутентификацией.



·        Какие новые технологии анализа, уникальные для ESET вы недавно внедрили
Несколько новых функций.
Одна из новых фишек – Exploit Blocker, который помогает защититься от самых опасных направлений атак – заражение через эксплуатацию уязвимостей. Эксплуатация уязвимостей опасна тем, что выполняется без участия пользователей и может поражать устройства даже у опытных и осторожных пользователей.
В отличие от Microsoft Emet, который нацелен на защиту от определенных типов уязвимостей, наша технология обнаруживает результат эксплуатации любого типа. Когда от имени браузера или pdf-ридера запускается какой-то подозрительный процесс, Exploit Blocker отслеживает это.  Таким образом мы отслеживаем эксплоиты нулевого дня.  Например, так обнаруживаем эксплоит, который победил на последнем Pwnie Awards на BlackHat 2013 и умеет выходить из песочницы (sandbox) Adobe Reader.

Другая фишка - Advanced Memory Scanner.  Она призвана бороться с технологиями вирусописателей по скрытию своего схода путем полиморфизма сервисных сайтов, когда для каждого заражения генерируется новый уникальный экземпляр кода, за счет переупаковки исходной вредоносной программы в новую оболочку. Кроме того, современные вирусы умеют обнаруживать и распознавать песочницы  и эмуляторы в которых их запускают и не распаковывают вредоносный код. Но в какой-то момент им всё-таки приходится  распаковать его, чтобы провести атаку, и в этот момент Advanced Memory Scanner, обнаруживает их. 

·        DSEC, организаторы ZeroNights уже год назад предвещали появление первых вирусов для приложений SAP, но большинство антивирусных компаний их проигнорировали.
Почему эта тема не интересна? Какие-то технические сложности или нет реальной опасности?
Я не слышал про данную тему. В целом - сложно предсказать заранее от чего надо защищаться и какой новый путь атаки выберут злоумышленники. Но они обычно выбирают в качестве целей те системы, на которых можно заработать деньги и в качестве объекта атаки – наименее защищенное звено, т.е. пользователей. Поэтому наши средства защиты контролируют защищенность рабочего места пользователя и в большинстве случаев этого достаточно.




пятница, 8 ноября 2013 г.

СОИБ. Обзор результатов анализа защищенности

В одной из предыдущих статей я говорил о популярности сканеров защищенности и о типовых ролях, используемых при эксплуатации сканеров защищенности. В этот раз хочу поговорить о пользе от сканеров защищенности, точнее, от комплексных систем (кроме поиска уязвимостей умеют выполнять ещё и анализ соответствия хотя бы каким-то требованиям) анализа защищенности общего назначения (не ограниченных каким-то одним сервисом - web, db, sap и т.п.).

Каждый производитель имеет собственную табличку по детальному сравнению функциональных возможностей своих продуктов с аналогами. Как правило, сравнения эти делаются для внутреннего использования и публикации не подлежат. Не хочется повторяться и делать свое сравнение функций с нуля только для блога. Тем более что вокруг выбора функций и каждой оценки можно вести бесконечные споры. Но какой-то обзор систем нужен?!  Давайте посмотрим на отчеты систем анализа защищенности – ведь они и являются основным результатом работы этих систем. В рамках данной статьи будут рассматриваться только отчеты по конкретному узлу. Сводные, дифференциальные, динамические и т.п. пока оставляю за бортом.

В данной статье будут рассматриваться следующие системы:
·        MaxPatrol производства Positive Technologies 


·        OUTSCAN и HIAB производства Outpost24



·        QualysGuard производства Qualys




В дальнейшем планирую дополнить отчетами SecurityCenter производства Tenable Network Security.

Для начала посмотрим на сводную информацию, которую дают сканеры об узле


Далее можем изучить перечень уязвимых сервисов и уязвимостей в них. MaxPatrol группирует уязвимости по сервисам – и это удобно. Outpost24 и Qualys дают списком



Далее посмотрим что нам говорят сканеры в случае отсутствия обновлений безопасности.  Все считают показатель CVSS. Но Qualys в этот раз не смог. По рекомендациям вроде всё корректно. Идем на сайт производителя и загружаем обновления.

Посмотрим что нам дают сканеры при обнаружении некорректных настроек например в SSL. У MaxPatrol как то не хватает информации, в чем конкретно проблема и как исправить чтобы было хорошо? У остальных чуть больше информации



Теперь посмотрим ,что нам показывают при обнаружении XSS. MP – всё понятно написано. O24 – приводит четкие примеры - доказательства, так что тоже понятно где исправлять.


Далее SQL injection. Тут MP остался в одиночестве и выдает подробное и понятное описание уязвимости.




На сегодня это всё. Надеюсь вам будет полезна эта информация  и вы тоже полюбите сканеры защищенности. Всем спасибо за внимание.