Secure coding guidelines for University students (http://www.wl.unn.ru/).

1. Андрей Сомсиков
andrey.somsikov@gmail.com

2.  Не используйте лабораторные машины для
тестирования на безопасность
◦ Требуется разрешение от лаборанта
 Последствия
◦ Лишение прав доступа
◦ Переустановка OS

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

4.  Безопасность (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) – количественная оценка
угрозы.

5. Обзор

6.  ПО получает все большее распространение
◦ Банковские и финансовые системы
◦ Государственные системы
◦ Персональные системы
 Рост киберпреступности
◦ Повышение профессионализма хакеров
◦ Появление новых бизнес моделей
◦ Низкий уровень компьютерной грамотности
пользователей
 Проблемы безопасности обходятся дорого
◦ Security incident handling (≈$100K-$500K)
◦ Негативное и широкое освещение в прессе
◦ Недовольство пользователей

7.  Жизненный цикл разработки ПО
◦ Разбиение процесса на стадии
◦ Нет общепринятого стандарта:
 Microsoft SDL (http://msdn.microsoft.com/security)
 Intel SDL
 Безопасность должна быть на всех стадиях:
◦ Тренинги по безопасности
◦ Моделирование угроз
◦ Тестирование на безопастность
◦ ...
Проектирование Написание Тестирование Поддержка

8.  Анализируют уязвимые места дизайна или
реализации ПО:
◦ Исследуют взаимодействие с системой
◦ Собирают и анализируют выходные данные
◦ Изучают компоновку системы и потоки данных
◦ Ищут применимость опубликованных атак и
уязвимостей
 Инструменты
◦ SoftIce, WinDBG, OllyDebug, gdb/kdb, сетевые
сканеры, ...
◦ Dump памяти, depends, dumpbin
(дисассемблирование), декомпиляторы, ...
◦ Fuzzers – подача случайных входных данных

10.  Проверка входных данных
◦ “All input is evil, until proven otherwise”
◦ Проверяйте неправильность входных данных:
 Формат, длина, тип, интервал
 Уменьшай площадь атаки
◦ Используй только необходимые сервисы и
оганичивай время их использования
 Файлы, устройства, сторонние компоненты
◦ Все методы взаимодействия с ПО должны быть
документированы и протестированы
 Отсутствие «секретного» API или скрытой
функциональности

11.  Использовать минимально необходимые
привилегии
◦ Проверяй запуск приложения с
пользовательскими правами доступа:
 user/guest, доступ к системным папкам
 User Account Control (UAC) должен быть включен
 Многоуровневая защита
◦ Несколько уровней защиты ПО повышают
стойкость к взлому
 Firewall, проверка входных данных, аутентификация
и авторизация.

12.  Неизвестность≠ Защищенность
◦ Сокрытие может быть только дополнительным
уровнем защиты.
 Готовность к нештатным ситуациям
◦ Ошибка не должна приводить систему в
небезопасное состояние.
◦ Сообщение об ошибках не должно бфть слишком
детальным
 «Неверное имя пользователя или пароль»
◦ Журнал ошибок должен быть доступен только
авторизованным пользователям

13.  Тесты на безопасность
◦ Тесты на распространенные ошибки
◦ Проверки на недокументированное поведение
◦ ...
 Учеба на ошибках
◦ Документируй и анализируй ошибки

15.  Переполнение буфера - происходит при
записи данных в память за границу
выделенной области:
◦ На стеке (stack)
◦ В динамической памяти (heap)
 Сложно но возможно в managed коде (C#,
Java)
 Цели:
◦ Исполнение вредоносного кода,
◦ Получение доступа к информации,
◦ Нарушение стабильной работы.

16. 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

17. • Пример 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

18. Уязвимость в модуле 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;
...
Возможно выполнение произвольного кода.
^^^^^^^^

19. Поиск и
исправление
ошибок
переаолнения
буфера
Уменьшить
площадь атаки
Security Code
Review – Поиск
уязвимостей до
выпуска продукта
Использовать
более безопасную
функциональность
(strsafe, Safe CRT,
STL)
Опции сборки
кода: /GS, NX,
Heap Checking, ...
Инструменты для
анализа кода на
безопасность
FuzzTesting -
Тесты со
случайными
входными
данными
19

20.  Переполнение (overflow/underflow).
unsigned int a = 0xefffffff;
unsigned int b = a + 2;
 Потеря или приобретение знака
int c = a
 Потеря старших разрядов
char d = a;
20
Арифметические ошибки приводят к
переполнению буфера

21. 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 str
strcpy(buf,str);
}
}
21

22.  Тщателно проверяйте вычисления сдвигов в
массивах, адресов памяти
 Используйте беззнаковые типы для:
◦ Индексов
◦ Размеров буферов
◦ Closely examine any calculation used to determine
an array offset or memory location
 Обращайте внимания на предупреждения b
ошибки компилятора а также на иструкции
по отключению ошибок (#pragma)
22

23.  Данные представленые по разному могут
быть эквивалентны:
◦ filename_secret.ext ≡ filena~1.ext
◦ www.site.ru/secret ≡ www.site.ru/%73ecret
 Проблемы с использованием канонических
представлений: проверки безопасности
ориентированы на одно представление
данных, хотя фактически может быть
использовано другое
23
Используются для обхода проверок

24. SecretFile.txt
SecretFile.txt.
Secret~1.txt
SecretFile.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. • Приводите к канонической форме перед
использованием или проверкой.
• Используйте возможности операционной
системы для приведения к канонической
форме
• Используйте регулярные выражения для
поиска запрещенных символов
25

26.  Только правильное использование
криптографии позволит защитить данные и
скрыть секреты
◦ Некоторые алгоритмы признаны взламываемыми:
MD4, MD5, RC4, DES, SHA1.
◦ Существуют атаки на некоторые реализации
алгоритмов: RSA, AES
◦ NIST – как правильно применять алгоритмы
 Проблемы хранения, использования и
уничтожения секретных данных в памяти.
 Генерация случайных данных.

27.  Используйте стандартные реализации
алгоритмов SSL, CryptoAPI.
 Не разрабатывайте собственный алгоримы
- используйте проверенные.
 Используйте правильные генераторы
случайных чисел.
 Обновляйте ключи переодически.
 Используйте специальные функции для
очиски памяти SecureZeroMemory.

28.  DOS Attck – Атака на систему призванная
привести к отказу в обслуживании
 Остновные векторы атаки:
◦ Остановка или падение системы (проверка
входных данных, переполнение буфера,
арифметическая ошибка)
◦ Перегрузка CPU
◦ Нехватка памяти, ресурсов
◦ Загрузка сети

29.  Аутентификация и авторизация
◦ Доступ к ресурсам должны иметь только
авторизованные пользователи.
 Фильтрация
◦ Проверка входных данных
 Ограничения
◦ Не позволять использовать максимальное
количество ресурса.

30.  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/defa
ult.aspx - Microsoft Security Development
Lifecycle