Удивление программных уязвимостей или использования?

Я понимаю, что Вы хотите, чтобы Ваши клиенты использовали питание Python, но не хотите, представляют исходный код.

Вот мои предложения:

(a) Запись критические части кода как C или библиотеки C++ и затем используют SIP или большой глоток для представления API C/C++ пространству имен Python.

(b) Использование цитон вместо Python

(c) И в (a) и в (b), должно быть возможно распределить библиотеки как лицензируемый двоичный файл с интерфейсом Python.

28
задан 8 revs, 4 users 77% 9 May 2013 в 06:51
поделиться

30 ответов

Мой любимый и самый впечатляющий из тех, что я видел до сих пор, - это класс методов криптографии, известный как Атаки по побочному каналу .

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

27
ответ дан 28 November 2019 в 02:12
поделиться
7
ответ дан 28 November 2019 в 02:12
поделиться

Второе издание Справочника Shellcoder: обнаружение и использование дыр в безопасности довольно занимательно:

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

Google Книги

0
ответ дан 28 November 2019 в 02:12
поделиться

Уязвимость Hyper-Threading :

Эта уязвимость разрешает локальную информацию раскрытие информации, включая разрешение непривилегированный пользователь для кражи RSA закрытый ключ используется на том же машина.

1
ответ дан 28 November 2019 в 02:12
поделиться

Мои фавориты - это класс довольно специфических атак, известных как Атака на строку формата ]. Они используют теги форматирования, подобные printf, для перезаписи данных в стеке. Некоторые из них используют непонятные токены, такие как% n, которые, хотя и довольно редко встречаются, могут быть введены в код, если программист будет достаточно небрежным, чтобы позволить нефильтрованным входным данным достичь строки формата.

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

Еще одна интересная атака - это ошибка off-by-one . Опять же, это нелегко использовать, но определенно выполнимо.

3
ответ дан 28 November 2019 в 02:12
поделиться

Месяц назад я был на французской конференции по ИТ-безопасности (SSTIC), где один парень объяснил, почему и как нельзя доверять текущей доверенной вычислительной архитектуре. Как ? Он показал нам "бэкдор acpi", который дал ему uid 0 (root-привилегии) ​​после того, как пару раз отключил / снова подключил электрический кабель его ноутбука. Можно читать статью и слайды (на французском, но я думаю, что поиск в Google по запросу "loic duflot + acpi" должен дать некоторые результаты на английском языке): http://actes.sstic.org/SSTIC09/ACPI_et_routine_de_traitement_de_la_SMI/

2
ответ дан 28 November 2019 в 02:12
поделиться
5
ответ дан 28 November 2019 в 02:12
поделиться

Кто не помнит Killer Poke (нетехническое объяснение): у старых Commodore 64 медленная видеопамять. Используя POKE, вы можете записать специальное значение в адрес в видеопамяти - это вызывает все виды вуду, не в последнюю очередь из-за изменения напряжения некоторых цепей, что, к счастью, приводит к тому, что экран обновляется больше.

Когда Commodore обновила свое видеооборудование, одна и та же команда poke заставляет напряжение снижаться до всех типов проблем и поджаривать оборудование. Программный эксплойт может вызвать повреждение оборудования. Замечательно.

4
ответ дан 28 November 2019 в 02:12
поделиться

Одна из наименее сложных атак, которые я когда-либо видел, была одной из самых эффективных. Один мой знакомый тестировщик работал над тестированием приложения VB6 под Win98. Приложение было создано для открытия в окне фиксированного размера. Тестировщик, проявив смекалку, создал ярлык для приложения и установил ярлык для открытия приложения в развернутом виде. Когда приложение открывалось в гораздо большем размере, чем предполагал разработчик, оно открывало элемент управления данными, который обычно не был бы виден. Щелкнув вручную элемент управления данными, тестировщик смог перейти к записи, которую он не должен был просматривать, и изменить ее ...

7
ответ дан 28 November 2019 в 02:12
поделиться

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

Это может использоваться для атак на сайты, которые добавляют токен безопасности к URL-адресу (если этот токен не слишком длинный), просто пробуя все возможные комбинации.

9
ответ дан 28 November 2019 в 02:12
поделиться

Я думаю, что относительно недавняя уязвимость Linux подходит для вашего описания использования кода, который кажется безопасным (хотя и немного неправильно структурированным).

Это был конкретный фрагмент кода в ядре Linux:

struct sock *sk = tun->sk;  // initialize sk with tun->sk
…
if (!tun)
    return POLLERR;  // if tun is NULL return error

Из-за оптимизации GCC оператор if и тело удаляются (что разумно для пользовательского кода, но не в большей степени для кода ядра). Благодаря некоторой смекалке человек смог построить из этого эксплойт.

Резюме:

http://isc.sans.org/diary.html?storyid=6820

Опубликованный эксплойт:

] http://lists.grok.org.uk/pipermail/full-disclosure/2009-July/069714.html

РЕДАКТИРОВАТЬ : Вот гораздо более подробное описание того, как этот код был использован. Это краткое прочтение, но очень хорошее объяснение механизмов, используемых для эксплойта.

http: // lwn. net / SubscriberLink / 342330 / f66e8ace8a572bcb /

19
ответ дан 28 November 2019 в 02:12
поделиться

LWN.net опубликовал сообщение об эксплойте Cheddar Bay с использованием нулевых указателей, что само по себе не опасно, но благодаря оптимизации кода gcc он может выполнять нежелательный код, даже если вы настроили SElinux.

Кроме того, использование javascript-интерфейса на веб-страницах с помощью атак mitm для создания кейлоггера (onkey (нажатие / вверх / вниз) и публикация по URL-адресу - это довольно нестандартное решение, я думаю.

0
ответ дан 28 November 2019 в 02:12
поделиться

Не совсем программное обеспечение, но я уверен, что оно где-то играет роль.

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

http://lasecwww.epfl.ch/keyboard/

1
ответ дан 28 November 2019 в 02:12
поделиться

Прочтите это, это поразит вас (это определенно взорвало мой разум!).

http://news.ycombinator.com/item?id=639976

Один хакер взломал сайт «Hacker News», использовав то, что случайное создание файлов cookie не было на самом деле случайным. Комментарий к той же теме дает прекрасное описание взлома,

Спасибо, dfranke. Все эти годы всякий раз, когда я думал об истинном хакере, это то, что я изобразил на обратной стороне мой разум - достаточно сложный материал для мне достать статистику и лайнер Книги по алгебре. Каждый второй веб-хак попытка за последнее десятилетие была XSS, плохие пароли и глупая форма вопросы подачи. Откровенно говоря, у меня было отказался от существования истинного хакеры whitehat до этого поста. Головные уборы прочь, сэр.

Некоторые похвалы хакеру:

Товарищи хакеры, обратите внимание. Вот как вы решаете проблему! Dfranke это Пандора, крыса в лабиринте, Шерлок Холмс, генерал Шерман, Уильям Рэндольф Херст и твой отец все завернутый в одну.

Как и Пандора, он такой любопытный, у него чтобы проверить это.

Как крыса в лабиринте, он продолжает идти ищет чистый путь.

Как Шерлок Холмс, он применяет логику чтобы определить следующий шаг.

Как генерал Шерман, он сохраняет маршируют, строят инструменты по пути поскольку они ему нужны.

Как Уильям Рэндольф Херст, он определяет пейзаж. ("Вы предоставляете картинки, я войну обеспечу. ") "поэтому я выбрал более активный подход: разбей его! "(весело)

И, как любой родитель, он не бросил пока его ребенок не пошел.

Спасибо, Даниэль. Я очень надеюсь, что ты нашел способ направить этот талант в ваша дневная работа.

2
ответ дан 28 November 2019 в 02:12
поделиться

По «сложному» масштабу атака Дауда на виртуальную машину ActionScript не имеет себе равных. См. эту рецензию для развлекательного резюме статьи.

2
ответ дан 28 November 2019 в 02:12
поделиться

Все время задаются вопросом, не так ли? В этот год «Не может быть реальным ... но вау!» Означало загрязнение параметров и обнюхивание вашей истории без использования JavaScript .

Я выберу последний вариант, потому что он удивительно прост (Я думаю, что у каждого будет момент, когда он поймет, что сам мог иметь эту идею ... нет, должен был иметь.), И он использует оптимизацию полосы пропускания самого браузера, которая гарантирует, что фоновое изображение загружается только тогда, когда это необходимо.

Мне это нравится.

И это нелегко смягчить, не сломав несколько вещей. На самом деле я ошибаюсь, вы можете запретить "невидимые" фреймы в браузере. Не знаю, действительно ли это кому-нибудь нужно.

2
ответ дан 28 November 2019 в 02:12
поделиться

Вот однострочная команда оболочки, которая выполняет эскалацию привилегий для OS X:

osascript -e 'tell app "ARDAgent" to do shell script "whoami"'

Это не так просто, как кажется, поскольку вам нужен отдельный вектор атаки для доступа к пользователю shell, но это действительно классная полезная нагрузка.

Я не уверен, что это больше работает, но я помню, как делал это на моем Mac в то время (с простой копией, вставкой), и он с радостью сообщил 'root'.

Вот статья в слэшдоте:

http://it.slashdot.org/article.pl?sid=08/06/18/1919224

3
ответ дан 28 November 2019 в 02:12
поделиться

Другой неожиданный и недавний эксплойт - это Clickjacking , который еще раз показывает неадекватность нашей текущей модели того, чем является и каким должен быть веб-браузер. Легко обходит большинство средств защиты от XSS, CSRF и т. Д. И позволяет вредоносному веб-сайту «украсть» контроль над вашими щелчками и направить их по ошибке в определенное место на другом веб-сайте - например, кнопку «ОК» на странице «Перевод средств» на сайт вашего банка или диалоговое окно параметров Flash, позволяющее злоумышленнику ПРОСМОТРЕТЬ ВАШУ ВЕБКАМУ БЕЗ ВАШИХ ЗНАНИЙ!
Шокирующе и блестяще ...

2
ответ дан 28 November 2019 в 02:12
поделиться

I thought the recent hack into a Twitter employee's email accounts was pretty scary.

Basically took advantage of an expired email account and the "forgotten password" recovery system of another account.

0
ответ дан 28 November 2019 в 02:12
поделиться

Подделка межсайтовых запросов .

Я считаю это одним из самых простых, но разрушительных. Пока на сцене не появился CSRF, веб-разработчики предполагали, или, скорее, доверенные браузеры, чтобы отправлять запросы, созданные пользователем, но это не так. Классический пример сбитого с толку депутата .

3
ответ дан 28 November 2019 в 02:12
поделиться

Да, да, мы все знаем о SQL Injection - и все мы знаем, как от него защититься, верно?
Ваше приложение должно выполнять проверку ввода, вызывать хранимые процедуры и т. Д. И т. Д.

Но знаете ли вы, что в определенных ситуациях Контрабанда SQL может легко все это обойти?
Самое шокирующее в этом то, что это вызвано малоизвестной, по большей части недокументированной, «особенностью» в некоторых базах данных, фреймворках, объектах db и т. Д. Короче говоря, база данных (или сантехника по пути туда) может вам помочь. благосклонность счастливого - и тихого - перевода одного незнакомого персонажа в другого! Например, символ Unicode U + CABC может стать кавычкой (U + 0027), которую вы пытались заблокировать в своем приложении, но, к сожалению, база данных решила создать и позволить злоумышленнику снова провести атаку SQLi прямо через вашу защиту.

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

8
ответ дан 28 November 2019 в 02:12
поделиться

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

Они показали, что вы можете читать содержимое обычной оперативной памяти после перезагружать. Охладив чипы до -50 ° C с помощью баллончика с распылителем воздуха (не жидким азотом или чем-то подобным), они обнаружили, что менее 1% битов перевернулось через 10 минут без питания (!)

серьезная атака на все программы шифрования дисков. Они должны хранить ключ дешифрования в ОЗУ, и если вы сможете перезагрузить компьютер, вы, вероятно, сможете получить доступ к ключу. Вы можете сказать, что не позволите людям вот так перезагружать вашу машину, но подумайте об украденных ноутбуках в режиме ожидания. Они проснутся и представят заставку с запросом пароля. В это время ключ шифрования диска находится в ОЗУ =>

6
ответ дан 28 November 2019 в 02:12
поделиться

Возможно, это не совсем то, что вы ищете, но разработчики MoinMoin Wiki ведут центральный список регулярных выражений Wiki-спама здесь: http: //master.moinmo. http://www.rfidvirus.org/

2
ответ дан 28 November 2019 в 02:12
поделиться

Лучшим из того, что я видел до сих пор, был комментарий строки mrand.c к пакетам Debian SSL, потому что purify жаловался на использование неинициализированных данных. Это была не ошибка кода сама по себе, а скорее ошибка рефакторинга, она была введена специалистом по обслуживанию, прокомментировав строку кода. Строка, которая была прокомментирована, была вызовом функции, которая должна была обеспечивать энтропию для генерации ключей, но, поскольку она использовала для этого неинициализированные данные, valgrind пожаловался.

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

Это продолжалось в течение нескольких лет, и был обнаружен только по ошибке, когда Лучано Белло создавал сотни ключей для проекта колледжа и заметил несколько ключевых коллизий.

Эти ошибки представляют собой реальную угрозу, они продолжаются годами, и как вы это проверить? ГПСЧ действительно случайный? alt text
(источник: dilbert.com )

Точная строка была:

md_rand.c

MD_Update(&m,buf,j); /* purify complains */

Вы можете прочитать все об этой удивительной ошибке здесь: текст ссылки

3
ответ дан 28 November 2019 в 02:12
поделиться

Хорошо, это не программная уязвимость или эксплойт, но даже в этом случае:

« Ван Эк Фрикинг - это процесс перехвата содержимого ЭЛТ и ЖК-дисплей, обнаружив его электромагнитное излучение ». (Из Википедии)

Просто ... вау ...

10
ответ дан 28 November 2019 в 02:12
поделиться

Несколько лет назад я взглянул на программу (на Acorn Archimedes), которая была защищена сложной системой шифрования (просто чтобы увидеть, как это было сделано, и извлечь уроки из нее). Это было сделано очень умно: сам код дешифрования использовался как часть ключа дешифрования, так что любая попытка с ним повлиять на расшифровку нарушит дешифрование и, таким образом, оставит вас с мусором в памяти.

Через 2 дня попыток понять, как это было сделано, и как можно было обойти это, посетил друг. Используя инструмент операционной системы (щелчок и перетаскивание, чтобы максимально увеличить объем памяти RMA), он ограничил доступную оперативную память для запуска процесса чуть больше, чем размер .exe. Затем он запустил его. Сразу после расшифровки он попытался выделить память, но потерпел неудачу и разбился. Затем он сохранил расшифрованную программу из памяти. Общее время взлома: и никогда не использовал взломанный код. Это действительно было просто упражнение по интеллектуальному программированию)

и никогда не использовал взломанный код. Это действительно было просто интеллектуальное упражнение по программированию)

12
ответ дан 28 November 2019 в 02:12
поделиться

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

РЕДАКТИРОВАТЬ: Только что было обсуждение, в ходе которого была поднята идея поместить SQL-инъекцию на полосу магнитной карты. Думаю, вы можете разместить его где угодно, поэтому проверяйте любой ввод, особенно от пользователей, и такие устройства хранения данных.

21
ответ дан 28 November 2019 в 02:12
поделиться

Классическим эксплойтом был взлом Кена Томпсона, чтобы дать ему root-доступ ко всем Unix-системам на Земле.

Когда Bell Labs была единственным поставщиком Unix, они распространяли исходный код, так что каждая установка могла собрать и настроить собственную ОС. Этот источник включал команду входа в систему Unix. Кен модифицировал компилятор C, чтобы определить, компилирует ли он команду входа в систему, и, если да, добавил начальную проверку пароля. Этот пароль был его собственным волшебным и предоставлял root-доступ.

Конечно, любой, кто читал исходный код компилятора C, увидел бы его и удалил. Итак, Кен снова модифицировал компилятор C, так что, если он компилирует компилятор C, он снова вставит хакерский метод входа в систему.

Теперь переходит к самой важной части; Кен скомпилировал компилятор C своим взломанным компилятором, затем удалил все следы своего взлома, удаление его из источника, резервные копии, контроль версий, все. Он существовал только в скомпилированном двоичном файле, который был частью дистрибутива Unix.

Любой, кто получил этот Unix от Bell Labs, получил взломанный логин и компилятор C. Если они посмотрели на источник, это было безопасно. Если они перестроят ОС, взломанный компилятор взломает перестроенный компилятор, который повторно вставит взлом в команду входа в систему.

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

Кен показал это в статье ACM под названием Размышления о доверии .

Если они посмотрели на источник, это было безопасно. Если они перестроят ОС, взломанный компилятор взломает перестроенный компилятор, который повторно вставит взлом в команду входа в систему.

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

Кен показал это в статье ACM под названием Размышления о доверии .

Если они посмотрели на источник, это было безопасно. Если они перестроят ОС, взломанный компилятор взломает перестроенный компилятор, который повторно вставит взлом в команду входа в систему.

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

Кен показал это в статье ACM под названием Размышления о доверии .

18
ответ дан 28 November 2019 в 02:12
поделиться

Чрезвычайно простой способ испортить ваше веб-приложение: если приложение позволяет пользователям добавлять изображения в профили, доску сообщений или сообщения в блогах, злоумышленник может настроить URL-адрес изображения, например '/ Account / LogOut '(или любой другой допустимый локальный URL-адрес, вызывающий нежелательные действия). Если ему удастся опубликовать свой профиль / сообщение / сообщение «до главной страницы» - каждый пользователь выйдет из системы сразу после входа в систему (браузер выполнит запрос в / Account / LogOut в контексте текущего пользователя, чтобы загрузить изображение), поэтому функциональность страницы будет серьезно повреждена.

4
ответ дан 28 November 2019 в 02:12
поделиться
Другие вопросы по тегам:

Похожие вопросы: