Общее. Roman Korkikian и Adrian Furtuna после ZN

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

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

Это может сказаться очень плохо. Очень часто защита криптографических алгоритмов строится вокруг датчиков случайных чисел. Типичный пример это masking, когда вначале к исходному тексту добавляется случайный вектор, а затем происходит выполнение алгоритма и параллельно с ним перерасчет этого вектора, чтобы в конце получился реальный шифротекст, как будто ничего не добавлялось в начале. Masking основывается на случайных числах и такая защита есть в очень многих устройствах. Если знать маску (случайный вектор), то можно спокойно применять Side Channel Attacks без каких бы то ухищрений (существуют специальные атаки на masking но они довольно сложны). 

Я хотел бы заметить, что очень часто "спецслужбам" не нужно встраивать "неслучайные" генераторы случайных чисел, ибо работу этих генераторов можно слегка изменить из вне. Например, разместить около генератора источник сильного электромагнитного напряжения, или облучать генератор лазером. В этом случае, числа будут уже не такими случайными, как кажется. Вообще это тема отдельной статьи. С датчиками есть еще другая проблема, что им зачастую нужно зерно (seed), значение которое подается на генератор (на С это зерно задается командой srand(seed)). Если будете создавать случайные числа с одним и тем же зерном, то получите одни и те же "случайные" числа.

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.

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