ПРИНТЕРЫ СЕГОДНЯ - Xakep Online

62ВзломХАКЕР 04 /171/ 2013ПОДОБРАТЬ ПАРОЛЬРЕШЕНИЕВсякие простые и дефолтные пароли — это один из паразитов безопасности.Конечно, многие вендоры в своем ПО поменяли подход и теперь перекладываютответственность на пользователей, заставляя тех при установкезадавать пароли. Но «в среднем по больнице» ситуация плачевна, особеннодля всевозможных девайсов.Проводя пентест внутри крупных компаний, сталкиваешься с кучей различногоПО, различных устройств, подключенных к корпоративной сети.И ведь все нужно посмотреть, потыкать, поподбирать дефолтные пароли.Ведь можно и принтеры похакать, и читать чужие документы. И сетевое оборудованиеможно переконфигурить для своих нужд. Не говоря уж о том, чтоиногда можно найти девайсы, ответственные за контроль «крутилки» на проходной,со всеми приятными последствиями. В общем, девайсов очень много,а времени мало.Вот поэтому и хотелось обратить общее внимание на появившийся проектDPE (default password enumeration) — goo.gl/Fgioa от www.toolswatch.org.Здесь нет ничего очень необычного. Просто база данных дефолтных учеток.Но это как раз то, что необходимо. Дефолтные пароли привязаны к вендорам,типам девайсов и ПО, описанию, CVE, CPE. Формат хранения удобен для внедренияв стороннее ПО (всевозможные сканеры и брутфорсеры).Самое трудное здесь — поддержание проекта в дельном состоянии. Чтобыинформация была правдива, а списки пополнялись. Но есть надежда, чтоэто как раз оно. Челы даже добавились в проекты на MITRE (goo.gl/WUuk9).Сейчас же это выглядит просто: dpe_db.xml — база данных (1920 дефолтныхучеток) и парсер для нее DPEparser.py.DPEparser.py-v — поиск по вендору-t — по типу-с — по CPE-d — по описанию-u — обновление базыПолучаем список дефолтных учетокCSRF НА ЗАГРУЗКУ ФАЙЛОВРЕШЕНИЕГоды идут, технологии меняются и становятся технологичнее…И если раньше считалось, что Sameorigin policy бережет разработчика, что нельзя делатькросс-доменные запросы (XMLHTTPRequest)с помощью JavaScript. Конечно, многие разработчикиудивлялись, когда хакер «из рукава»доставал обычные CSRF-ки GET-запросом илиделал чуть более продвинутые POST-запросычерез автоматически отправляемую формочку сРис.1. Загрузка стандартными средствами формочекправильным Content-Type. Но все-таки была несокрушимаястена, так как XMLHTTPRequest иправда не разрешался на сторонние домены, апотому мы не имели возможности делать загрузкупроизвольных файлов, используя CSRF. Ведьв браузере, чтобы загрузить файл, пользовательдолжен его выбрать с помощью соответствующегодиалогового окна…Но годы прошли, и власть переменилась. Вышелстандарт HTML5, который позволяет намтеперь совершать кросс-доменные запросы.XMLHTTPRequest разрешено делать на любойхост. Это является частью стандарта CORS (CrossOrigin Resource Sharing). Вообще, она было сделанадля того, чтобы из JavaScript’а можно былополучать данные с других доменов. Но CORS созданс вниманием к безопасности. А потому дляпримера предположим, что JavaScript с хоста Апытается получить информацию с хоста Б. Производитсязапрос, используя XMLHTTPRequest,на хост Б. В запросе на хост Б добавляется новыйзаголовок — Origin (то есть имя сайта, с которогоделается запрос). В свою очередь, ответ от хостаБ может иметь заголовок «Access-Control-Allow-Origin», в котором указываются сайты (или * длявсех сайтов), которыми может быть получена информацияс хоста Б. То есть браузер пользователяпо этому заголовку может решить, разрешеноли яваскрипту с хоста А получить ответ от Б. Здесьважно отметить, что отсутствие Access-Control-Allow-Origin приводит к запрету для всех хостов.Получается, что CORS вполне секьюрнаятехнология. Но, как ты, наверное, заметил, дляреализации ее создателям пришлось нарушитьстарые запреты и разрешить кросс-доменныезапросы. Да, ответ мы не получим, но запрос послатьможем. По сравнению с обычным CSRF, использованиевозможностей JavaScript позволяет