Эта статья написана под впечатлением от статьи "OSSIM — разворачиваем комплексную open source систему управления безопасностью". Я не буду повторяться и описывать сам процесс установки системы. Я хочу только внести некоторые уточнения и пояснения связанные с практическим опытом применения OSSIM.

Когда я делаю ошибку в коде, то обычно это приводит к появлению сообщения “segmentation fault”, зачастую сокращённого до “segfault”. И тут же мои коллеги и руководство приходят ко мне: «Ха! У нас тут для тебя есть segfault для исправления!» — «Ну да, виноват», — обычно отвечаю я. Но многие ли из вас знают, что на самом деле означает ошибка “segmentation fault”?

Чтобы ответить на этот вопрос, нам нужно вернуться в далёкие 1960-е. Я хочу объяснить, как работает компьютер, а точнее — как в современных компьютерах осуществляется доступ к памяти. Это поможет понять, откуда же берётся это странное сообщение об ошибке.

Вся представленная ниже информация — основы компьютерной архитектуры. И без нужды я не буду сильно углубляться в эту область. Также я буду применять всем известную терминологию, так что мой пост будет понятен всем, кто не совсем на «вы» с вычислительной техникой. Если же вы захотите изучить вопрос работы с памятью подробнее, то можете обратиться к многочисленной доступной литературе. А заодно не забудьте покопаться в исходном коде ядра какой-нибудь ОС, например, Linux. Я не буду излагать здесь историю вычислительной техники, некоторые вещи не будут освещаться, а некоторые сильно упрощены.

Мы используем систему оценок CVSS с момента возникновения нашей базы уязвимостей и первого нашего продукта — XSpider (надеюсь, кто-то его еще помнит). Для нас очень важно поддерживать базу знаний, которую мы используем в своих продуктах и услугах, в актуальном состоянии. Поскольку рекомендации по работе с CVSS-метриками не покрывают все возможные варианты уязвимостей, иногда приходится задаваться вопросом: «Как лучше проставить метрики, чтобы итоговая оценка отражала реальную опасность уязвимости?».

Мы постоянно следим за развитием стандарта, поэтому давно ждали окончательной версии CVSSv3. Открывая спецификацию, я прежде всего хотел ответить на вопросы: «Что стало лучше?», «Что именно изменилось?», «Сможем ли мы использовать новый стандарт в наших продуктах?» и — поскольку к ведению базы часто подключаются молодые специалисты — «Как быстро можно овладеть методикой оценки?», «Насколько четкими являются критерии?».

В ходе изучения стандарта родилась эта статья, надеюсь, она поможет вам в освоении новой методики оценки уязвимостей.

WordPress — это удобная блог-платформа для публикации статей и управления ими, на которой базируется огромное число различных сайтов. Из-за своей распространенности эта CMS уже давно является лакомым куском для злоумышленников. К сожалению, базовые настройки не обеспечивают достаточного уровня защиты, оставляя многие дефолтные дырки незакрытыми. В этой статье мы пройдем типичным путем «типового» взлома сайта на Wordpress, а также покажем как устранить выявленные уязвимости.

Речь пойдет о файлах primary.key, masks.key и header.key, которые лежат в директории ххххх.000 на флешке. Данные файлы входят в состав криптоконтейнера закрытого ключа электронной подписи криптопровайдера КриптоПро, формат которого нигде не опубликован. Целью данной статьи является чтение контейнера и преобразование закрытого ключа в формат, который может быть прочитан в библиотеке OpenSSL. Долгое время было распространено ошибочное суждение, что достаточно сделать нечто вида (primary_key XOR masks_key) и мы получим закрытый ключ в чистом (raw) виде, однако забегая вперед, можно утверждать, что в КриптоПро было применено более сложное преобразование, в худшем случае состоящее из более чем 2000 (двух тысяч) операций хеширования.

Стоит упомянуть о существовании утилиты P12FromGostCSP которая позволяет конвертировать ключ в формат P12, доступный для работы с OpenSSL, но утилита имеет следующие существенные недостатки:

• Читает контейнер не напрямую, а через криптопровайдер, поэтому там, где кроме OpenSSL ничего нет, не работает.
• Если в свойствах ключа не отмечено, что ключ «экспортируемый», то конвертировать его невозможно.
• В демо версии не формирует файл с ключом, эта возможность присутствует только в платной версии.

Файл primary.key

Содержит 32 байта ключа в формате Asn1. Это только половина ключа, полный ключ получается при делении этого числа по модулю Q на маску. Поле, хранящее модуль Q в библиотеке OpenSSL имеет название order. Маска лежит в файле masks.key:

Всем доброго времени суток.

Желающие сразу перейти к технической части — прошу под кат. Для более терпеливых — небольшая предыстория с предпосылками.

Началось все с того, что И сказал бог: «да будет свет.»… ммм, нет, пожалуй, эту часть мы пропустим.

Началось все с того, что решил я: «Пора менять освещение в моей рабочей мансарде». Оно, в общем-то, было не плохим, да вот беда, изначально — с момента постройки, у меня тут стояло 3 обычные люминисцентные лампы T8, с дешевыми китай-ноунейм электронными «балластами». С точки зрения именно освещенности — решение было отличное, и трогать бы его и не стал. Но…
Китайские балласты стали дохнуть один за другим (из 7 штук в доме уже сдохло 4). Чинить это УГ — даже не стоит и пытаться, тем более — что в местах нагрева уже высохла начала крошиться сама пластмасса корпусов. В общем — в мусор.

Пришлось думать над заменой.

Главная особенность помещения мансарды — это её геометрия. Очень длинная (6,5м) при том — шибко узкая (трапеция, 4м снизу и 2 сверху) и низкая (около 2м). Очевидно — точечные источники света (читай — обычные лампы и прочие люстры) тут не годятся совершенно.

Ставить снова люминисцентки — не шибко хотелось, ибо у них помимо всего прочего есть существенный потенциальный недостаток — пары ртути при разбитии. А учитывая наличие в доме двух малолетних детей — риск поколотить лампы есть и он существенно выше ноля (хотя пока везло — не били ни разу)

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

Как-то прошла мимо новость о появлении нового микроконтроллера К1921ВК01Т ОАО «НИИЭТ». Чем он примечателен? Своей периферией, предназначенной для управления электродвигателями (motorcontrol). Это не просто пара-тройка ШИМ каналов. Это девять навороченных двухканальных модулей ШИМ (PWM), из них три модуля (HRPWM) с режимом «высокого» разрешения. Это шесть отдельных 32х разрядных модулей захвата CAP. Двадцать четыре(!) канала 12ти разрядных АЦП с гибким менеджером их запуска, встроенным усреднителем и цифровыми компараторами. Два квадратурных декодера (QEP), куча интерфейсов связи, внутренняя пользовательская память, часы – и всё это на ядре ARM Cortex-M4F с мегабайтом флеш-памяти «на борту» и производительностью 100 MIPS! Интересно?

Всем привет! Я Максим Андреев, программист бэкенда Облака Mail.Ru. В свободное время я люблю искать баги. В сегодняшнем посте я хочу рассказать об одной довольно интересной уязвимости, которую я нашёл и зарепортил в bug bounty нескольких крупных компаний, за что получил солидное вознаграждение. Уязвимость заключается в следующем: если сформировать специальный видеофайл и загрузить его на сервер, то:

• можно получить на нём SSRF;
• можно получить local file read;
• если пользователь скачает этот файл, то автоматически будет подвержен уязвимостям, даже если его не откроет: можно будет получить доступ к данным на компьютере пользователя и узнать его имя.

Здравствуйте, меня зовут Александр Зеленин и я веб-разработчик. Я расскажу, как сделать так, чтобы ваш сайт открывался быстро. Очень быстро.

Этот обзор посвящен типовым ошибкам развертывания разнообразных СУБД, от самых известных и используемых на тысячах серверов, до специализированных и относительно редко встречающихся. Задачи создать всеобъемлющий курс по всем возможным векторам и уязвимостям не было, поэтому получились небольшие видео-ролики, раскрывающие основные нюансы сетевых атак на СУБД.

Так же, стоит сразу предупредить, что веб-приложения и веб-уязвимости намеренно были оставлены за бортом и не были рассмотрены.

В настоящее время практически все разработанные и разрабатываемые приложения стремятся стать как можно более доступными для пользователя в сети интернет. В сети размещаются различные приложения для более продуктивной работы и отдыха, такие как Google Docs, калькуляторы, электронные почты, облачные хранилища, карты, погода, новости и т.д… В общем все, что нужно для повседневной жизни. Наши смартфоны практически бесполезны без доступа к интернету, так как почти все мобильные приложения подключаются к облаку, сохраняя там наши фотографии, логины и пароли. Даже большинство домашних устройств постоянно подключено к сети.



Прикладной уровень является самой надежной защитой. Уязвимости, с которыми мы тут встретимся, зачастую полагаются на сложные сценарии ввода данных пользователем, что делает их трудноопределимыми с помощью систем обнаружения вторжений. Этот уровень — самый доступный извне. Для нормального функционирования приложения должен быть доступ через порт 80 (HTTP) или порт 443 (HTTPS).

Сегодня я бы хотел поговорить о векторах атак на СУБД Oracle на разных стадиях: как прощупать слабые места базы снаружи, проникнуть и закрепиться внутри плюс как все это дело автоматизировать с помощью специализированного софта. Архитектура и возможности базы данных весьма интересны, занимательных моментов немало, а значит, немало и способов все испортить. Однако не забывай: ломать — не строить, поэтому вся дальнейшая информация предоставлена исключительно с целью выявить недочеты в защищенности тестируемых систем и повысить безопасность.

Доброго времени суток!
Некоторым программистам иногда приходит в голову мысль «а не изучить ли мне ассемблер?». Ведь на нем пишут самые (с некоторыми оговорками) маленькие и быстрые программы, да и охота ощутить вкус низкоуровневого программирования берет свое. Ну и для общего развития не повредит.
Мысль эта не обошла стороной и меня. Вдохновившись историей одного байта, я ринулся в бой…

… но оказалось, что найти материал по интересующей теме не так просто, как хотелось бы. Посему решено было создать на хабре пополняющийся пост-индекс статей/книг/мануалов/etc. об этом, несомненно, великом языке.
Под катом находится, собственно, список с краткими комментариями, разбитый по категориям.

UPD
В список начали добавляться ресурсы по программингу микроконтроллеров.

Имеется в виду выполнение записи по аппаратно защищённому от записи адресу памяти в архитектуре x86. И то, как это делается в операционной системе Linux. И, естественно, в режиме ядра Linux, потому как в пользовательском пространстве, такие трюки запрещены. Бывает, знаете ли, непреодолимое желание записать в защищённую область … когда садишься писать вирус или троян…

Описание проблемы

… а если серьёзно, то проблема записи в защищённые от записи страницы оперативной памяти возникает время от времени при программировании модулей ядра под Linux. Например, при модификации селекторной таблицы системных вызовов sys_call_table для модификации, встраивания, имплементации, подмены, перехвата системного вызова — в разных публикациях это действие называют по разному. Но не только для этих целей… В очень кратком изложении ситуация выглядит так:

• В архитектуре x86 существует защитный механизм, который при попытке записи в защищённые от записи страницы памяти приводит к возбуждению исключения.
• Права доступа к странице (разрешение или запрет записи) описываются битом _PAGE_BIT_RW (1-й) в соответствующей этой странице структуре типа pte_t. Сброс этого бита запрещает запись в страницу.
• Со стороны процессора контролем защитой записи управляет бит X86_CR0_WP (16-й) системного управляющего регистра CR0 — при установленном этом бите попытка записи в защищённую от записи страницу возбуждает исключение этого процессора.

Проект был написан скорее в учебных целях (научиться сетевому программированию в Python), чем в практических. Такую же роль несёт и статься, ведь сейчас вряд ли кто-то будет скачивать сайты, чтобы прочитать пару статеек (за исключением некоторых случаев, когда подобное реально может пригодится).

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

Есть несколько способов решения данной проблемы, но я решил выбрать немного необычный для нашего времени способ. Я решил скачивать сайты. Конечно, данных способ не подходит для крупных сайтов, вроде Хабра, тут разумнее использовать парсер, но можно скачать и отдельный хаб, список пользователей, или только свои публикации с помощью HTTrack Website Copier, применив фильтры. Например, чтобы скачать хаб Python с Хабра нужно применить фильтр "+habrahabr.ru/hub/python/*".

Этот способ можно использовать ещё в нескольких целях. Например, чтобы скачать сайт, или его часть, перед тем, как вы окажитесь без интернет-соединения, например, в самолёте. Или для того, чтобы скачать заблокированные на территории РФ сайты, если скачивать их через Tor, что будет очень медленно, или через компьютер в другой стране, где данных сайт не запрещён, а потом передать его на компьютер, находящийся в РФ, что будет гораздо быстрее для многостраничных сайтов. Таким образом мы может скачать, например, xHamster Wikipedia через сервер в Германии или Нидерландах и получить сайт в сжатом виде по SFTP, FTP, HTTP или другому, удобному для вас, протоколу. Если, конечно, места хватит, для такого большого сайта :)

Ну что, начнём!?

Введение

Apache и Nginx — 2 самых широко распространенных веб-сервера с открытым исходным кодом в мире. Вместе они обслуживают более 50% трафика во всем интернете. Оба решения способны работать с разнообразными рабочими нагрузками и взаимодействовать с другими приложениями для реализации полного веб-стека.

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

Пару недель назад нам удалось вытащить на CodeFreeze с докладом Артема Гавриченкова aka ximaera, CTO в Qrator Labs — компании, которая является одним из мировых лидеров по вопросам борьбы с DDoS-атаками.



Собственно, я позвал Артема сделать нам обзорную лекцию о том, что такое DDoS-атаки, какие они бывают и как с ними бороться.

Если конкретнее:

• История термина. Чем отличаются DoS- и DDoS-атаки?
• DDoS-атаки с точки зрения специалистов по информационной безопасности, оценка рисков;
• Виды атак и их классификация;
• Противодействие для каждого вида атак;
• DDoS-атаки в Интернете будущего: как IPv6, IoT и рост числа участников Сети повлияет на её, Сети, безопасность?

Когда речь идёт о программном обеспечении, термин «взлом» зачастую ассоциируют с пиратством и нарушением авторских прав. Данная статья не об этом; напротив, я решительно не одобряю любые действия, которые прямо или косвенно могут навредить другим разработчикам. Тем не менее, эта статья всё же является практическим руководством по взлому. Используя инструменты и методы о которых далее пойдёт речь, вы сможете проверить защиту собственной Unity игры и узнаете, как обезопасить её от взлома и кражи ресурсов.

У многих людей, как-либо связанных с безопасностью, периодически возникает желание заняться pentest'ом, то есть тестом на проникновение. И чаще всего начинают все с pentest'а веб-приложений. Порог вхождения довольно мал (простейшая sqli определяется добавлением кавычки в параметр и эксплуатируется не особо сложнее), но при этом встречаются и довольно сложные задания, которые заставляют потратить пару-тройку дней на ковыряние.
Но возникает вопрос — где применять теоретические знания, без страха внезапного появления маски-шоу? Под катом проведу небольшой обзор полигонов для экспериментов по pentest'у.

Не очень хорошо помню, как я оказался в дебаггере DOSBox, и почему я ковырялся в 16-битном ассемблере, восстанавливая функцию распаковки ресурсных файлов MM3.CC – но это было здорово. Игра у меня появилась на какой-то из последних распродаж humble bundle, а потом в сети я наткнулся на страницу Джеффа Людвига, где описывались проблемы с модификацией игры, связанные с компрессией в MM3.CC. В частности, там было написано следующее:

Оказалось, что этот алгоритм довольно сложно взломать, и пока ещё никто не научился распаковывать эти данные.

Вызов был принят. В его статье расписано, как он пытался бороться с алгоритмом. Я же распишу, как это делал я сам, и в конце дам ссылку на утилиту с открытым кодом, которая умеет не только распаковывать, но и запаковывать файл MM3.CC file.

DOS Packer

Посмотрев на MM3.EXE, я обнаружил, что это сжатый исполняемый файл DOS, с неким несжатым оверлеем, в начале которого стоит FBOV. Я ничего не знал про ДОСовские компрессоры, но я подсмотрел у Джеффа Людвига, что он использует вещь под названием “Universal Program Cracker” v1.11. Я нашёл версию 1.10 (выпущенную 25 июня 1997 года) и распаковал ехе. И мне удалось даже правильно обработать данные оверлея. И всё равно мне хотелось узнать название паковщика. Мне подсказали, что нужно использовать программу Detect It Easy, и действительно – она выдала:

EXECUTRIX-COMPRESSOR(-)[by Knowledge Dynamics Corp]
Borland TLINK(2.0)[-]

Для любителей истории могу рекомендовать старые ветки обсуждений, касающихся этого софта – от 1991 и 1995 годов:

https://groups.google.com/forum/#!topic/comp.os.msdos.programmer/QsjHLY6Kb4s
https://groups.google.com/forum/#!topic/comp.compression/IAj2-VHbtl4