разработка безопасного кода

Разработка безопасного кода

Андрей Сомсиков[email protected]

Не используйте лабораторные машины для тестирования на безопасность◦ Требуется разрешение от лаборанта

Последствия◦ Лишение прав доступа◦ Переустановка OS

Предупреждение

Создание безопасного ПО Написание безопасного кода Обзор решения Microsoft

План лекции

Безопасность (Security)◦ Is the condition of a system that results from the

establishment and maintenance of measures to protect the system.

◦ Security is an aspect of a product, not a feature.◦ Устойчивость к воздействиям.

Защита персональных данных (Privacy)◦ Право на неприкосновенность частной жизни.

Угроза (англ. threat) – возможная опасность. Риск (англ. risk) – количественная оценка

угрозы.

Терминология

Создание безопасного ПО

Обзор

ПО получает все большее распространение◦ Банковские и финансовые системы◦ Государственные системы ◦ Персональные системы

Рост киберпреступности◦ Повышение профессионализма хакеров◦ Появление новых бизнес моделей◦ Низкий уровень компьютерной грамотности

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

◦ Security incident handling (≈$100K-$500K)◦ Негативное и широкое освещение в прессе◦ Недовольство пользователей

Почему ПО должно быть безопасным

Жизненный цикл разработки ПО◦ Разбиение процесса на стадии◦ Нет общепринятого стандарта:

Microsoft SDL (http://msdn.microsoft.com/security) Intel SDL

Безопасность должна быть на всех стадиях:◦ Тренинги по безопасности◦ Моделирование угроз◦ Тестирование на безопастность◦ ...

Создание ПО

Проектирование Написание Тестирование Поддержка

http://msdn.microsoft.com/security

Анализируют уязвимые места дизайна или реализации ПО:◦ Исследуют взаимодействие с системой◦ Собирают и анализируют выходные данные◦ Изучают компоновку системы и потоки данных◦ Ищут применимость опубликованных атак и

уязвимостей Инструменты

◦ SoftIce, WinDBG, OllyDebug, gdb/kdb, сетевые сканеры, ...

◦ Dump памяти, depends, dumpbin (дисассемблирование), декомпиляторы, ...

◦ Fuzzers – подача случайных входных данных

Что делают хакеры?

Написание безопасного кода

Проверка входных данных◦ “All input is evil, until proven otherwise”◦ Проверяйте неправильность входных данных:

Формат, длина, тип, интервал Уменьшай площадь атаки

◦ Используй только необходимые сервисы и оганичивай время их использования Файлы, устройства, сторонние компоненты

◦ Все методы взаимодействия с ПО должны быть документированы и протестированы Отсутствие «секретного» API или скрытой

функциональности

Основные принципы (1/4)

Использовать минимально необходимые привилегии◦ Проверяй запуск приложения с

пользовательскими правами доступа: user/guest, доступ к системным папкам User Account Control (UAC) должен быть включен

Многоуровневая защита◦ Несколько уровней защиты ПО повышают

стойкость к взлому Firewall, проверка входных данных,

аутентификация и авторизация.


Неизвестность≠ Защищенность◦ Сокрытие может быть только дополнительным

уровнем защиты. Готовность к нештатным ситуациям

◦ Ошибка не должна приводить систему в небезопасное состояние.

◦ Сообщение об ошибках не должно бфть слишком детальным «Неверное имя пользователя или пароль»

◦ Журнал ошибок должен быть доступен только авторизованным пользователям


Тесты на безопасность◦ Тесты на распространенные ошибки◦ Проверки на недокументированное поведение◦ ...

Учеба на ошибках◦ Документируй и анализируй ошибки


Основные уязвимости

Переполнение буфера - происходит при записи данных в память за границу выделенной области:◦ На стеке (stack)◦ В динамической памяти (heap)

Сложно но возможно в managed коде (C#, Java)

Цели:◦ Исполнение вредоносного кода,◦ Получение доступа к информации,◦ Нарушение стабильной работы.

Переполнение буфера

Переполнение стека в действии

Buffers Other vars

EBP

EIP Args

void func(char *p, int i) { int j = 0; CFoo foo; int (*fp)(int) = &func; char b[128]; strcpy(b,p);}

Адрес возвратафункции

Обработчики исключенийУказатели на функцииВиртуальные методы

Задают порядок исполнения кода

Исполнения вредоносного кода возможно если * p будет больше буфера b 16

n-функции в C/C++ безопасны?

• Пример 2:#define MAX (50)char szDest[MAX];strncpy(szDest,pszSrc,MAX);

• Пример 1:// Code verifies pszSrc is <= 50 chars)// pszSrc is a char *#define MAX (50)char *pszDest = malloc(sizeof(pszSrc));strncpy(pszDest,pszSrc,MAX);

17

Переполнение буфера возможно даже при использованиии n-

функций

sizeof(pszSrc) 4 байта, а не 50

szDest не будет null-terminated если длина pszSrc >=

MAX

Ошибка счета на единицу в Apache* 1.3Уязвимость в модуле mod_ssl (версии до 2.8.10).... char *cp;char caCmd[1024]; char *cpArgs; ... cp = (char *)oline; for (i = 0; *cp !=' ' && *cp !='\t' && *cp != NUL && i < 1024; ) caCmd[i++] = *cp++; caCmd[i] = NUL;

cpArgs = cp; ...

Возможно выполнение произвольного кода.

^^^^^^^^

Как избежать переполнения буфера

Поиск и исправление

ошибок переаолнени

я буфераУменьшить

площадь атаки

Security Code Review – Поиск уязвимостей до

выпуска продукта

Использовать более

безопасную функциональность (strsafe, Safe

CRT, STL)

Опции сборки кода: /GS, NX,

Heap Checking, ...

Инструменты для анализа кода на безопасность

FuzzTesting - Тесты со

случайными входными данными

19

Арифметические ошибки:Проблемы. Переполнение (overflow/underflow).unsigned int a = 0xefffffff;unsigned int b = a + 2;

Потеря или приобретение знакаint c = a

Потеря старших разрядовchar d = a;

20

Арифметические ошибки приводят к переполнению буфера

Арифметическик ошибки:Пример.void Example(char * str, int size) {char buf[80];

// Check to make sure size is ‘valid’if (size < sizeof(buf)) {

// Should be safe to copy strstrcpy(buf,str);

}}

21

Арифметическик ошибки: Как избежать? Тщателно проверяйте вычисления

сдвигов в массивах, адресов памяти Используйте беззнаковые типы для:

◦ Индексов◦ Размеров буферов◦ Closely examine any calculation used to determine

an array offset or memory location Обращайте внимания на предупреждения

b ошибки компилятора а также на иструкции по отключению ошибок (#pragma)

22

Канонические представления:Проблемы. Данные представленые по разному могут

быть эквивалентны:◦ filename_secret.ext ≡ filena~1.ext◦ www.site.ru/secret ≡ www.site.ru/%73ecret

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

23

Используются для обхода проверок

Канонические представления:Пример.SecretFile.txt

SecretFile.txt.Secret~1.txtSecretFile.txt::$Data

String FileName = System.Console.ReadLine();if (FileName.ToLower().Equals(“secretfile.txt”)) {

// deny access to file}else {

// grant access to file}

24

Именем файла может быть

“Secret~1.txt” или “SecretFile.txt::

$Data”?

Канонические представления:Как избежать ошибок?• Приводите к канонической форме перед

использованием или проверкой.• Используйте возможности операционной

системы для приведения к канонической форме

• Используйте регулярные выражения для поиска запрещенных символов

25

Только правильное использование криптографии позволит защитить данные и скрыть секреты◦ Некоторые алгоритмы признаны

взламываемыми: MD4, MD5, RC4, DES, SHA1.◦ Существуют атаки на некоторые реализации

алгоритмов: RSA, AES◦ NIST – как правильно применять алгоритмы

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

Генерация случайных данных.

Криптография: Возможный ошибки.

Используйте стандартные реализации алгоритмов SSL, CryptoAPI.

Не разрабатывайте собственный алгоримы - используйте проверенные.

Используйте правильные генераторы случайных чисел.

Обновляйте ключи переодически. Используйте специальные функции для

очиски памяти SecureZeroMemory.

Криптография: Как избежать ошибок?

DOS Attck – Атака на систему призванная привести к отказу в обслуживании

Остновные векторы атаки:◦ Остановка или падение системы (проверка

входных данных, переполнение буфера, арифметическая ошибка)

◦ Перегрузка CPU◦ Нехватка памяти, ресурсов◦ Загрузка сети

Denial of Service (DOS)

Аутентификация и авторизация◦ Доступ к ресурсам должны иметь только

авторизованные пользователи. Фильтрация

◦ Проверка входных данных Ограничения

◦ Не позволять использовать максимальное количество ресурса.

Способы защиты от DOS

http://msdn.microsoft.com/ru-ru/magazine/cc163518.aspx - Безопасные привычки: 8 простых правил для разработки более безопасного кода

http://msdn.microsoft.com/ru-ru/security/default.aspx - Центр безопасности

http://www.microsoft.com/security/sdl/default.aspx - Microsoft Security Development Lifecycle

Ссылки

http://msdn.microsoft.com/ru-ru/magazine/cc163518.aspx

http://msdn.microsoft.com/ru-ru/magazine/cc163518.aspx

http://msdn.microsoft.com/ru-ru/security/default.aspx

http://msdn.microsoft.com/ru-ru/security/default.aspx

http://www.microsoft.com/security/sdl/default.aspx

http://www.microsoft.com/security/sdl/default.aspx

Software

разработка безопасного кода