Общее. 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  от Артема Агеева и отчет Александра Панасенко