Re: lug-bg: Софтуер за следене на файлове

[Hristo Erinin <erinin@xxxxxxxxx>]

Здравей,


On Tue, 15 Mar 2005 17:41:26 +0200
Dean Stoeff wrote:

> > Целта е тази база да е
> > ПОДПИСАНА, а не криптирана. 
> 
> И това е супер, разбира се, че може и да бъде само подписана, макар че
> ако и е криптирано още по трудно ще бъде "атакуващия" да разбере с
> какво си има работа за да прави каквито и да е промени по системата.

Глупости, това, че е криптирана не ти дава никаква допълнителна
сигурност. Нали трябва да имаш програма, с която да генерираш сумите,
която да живее на сървъра. Я си представи, че някой атакува сървъра ти и
успява да го пробие. Той получава достъп до твоята
(предполагам, че ти ще я пишеш, иначе от какъв зор ти е да криеш
съдържанието на файла със сумите и алгоритъма, който използваш?)
екстра-хипер-супер-мега-хитра програма. Какво остава секретно тогава?
Едно голямо нищо + изгубеното процесорно време в безмислени операции +
увеличената сложност на програмата заради допълнителните безмислени
функции.

KISS.

> > Защо разследването не може да се извърши върху "жива" система (т.е.
> > защо ни е да е рестартираме и от диск да зареждаме rescue версия от
> > CD-ROM или USB)?
> >
> Идеята /поне според мен/ е точно да се измисли алгоритъм който да бъде
> достатъчно сигурен /не 100%, а ДОСТАТЪЧНО сигурен/ да се прави на
> живо, какво значи достатъчно е въпрос на нивото на параноя.
> А ако искаме да ставаме найстина много ПАРАНОЙЧНИ, неща от сорта на:

Изглежда, въпреки всички опити да се обясни причината, поради която
се налага използване на гарантирано чиста система при операция по
проверка на файловете, ти имаш собствени идеи. Според мен, това може да
се дължи на някое от тези три неща:

1)или не си си направил труда да прочетеш това, което са написали хората
преди теб (форма на неуважение и губене на време на останалите)
2) или поради натурална глупост не можеш да разбереш обясненията
3) или имаш прекрасна идея, която ние не разбираме

Все се надявам да е третото, в който случай ще те помоля да спреш да
пишеш по тази тема за известно време (2-3 седмици) през което време, да
доизмислиш гениалната си идея и ако тя наистина е гениална, да я
споделиш с нас. Моля недей да споделяш някакви сурови и необмислени
глупости, защото тук има хора, които нямат опит в тази материя. Има
огромна опасност, четейки твоите словоизлияния, да решат, че това което
обясняваш е правилно и да вземат да послушат съветите ти. 

Деца, не правете това в къщи.

> 
> "РЕСТАРТИРАНЕ, И ЗАРЕЖДАНЕ ОТ ГАРАНТИРАНО ЧИСТ НОСИТЕЛ..." , както 
> навремето казваше проф. Веселин Бончев, също не са много сигурни.
> Точно поради тая му реплика бяха измислени алгоритми как да се
> преодолее това. Малко примерче макар, че нещото не прави точно това но

До тук човек би останал с впечатлението, че много отблизо и внимателно
си следил развитието на изкуството на писане на вируси още от
зараждането му, както и че отлично познаваш Веселин Бончев. Даже очаквам
да цитираш Vengador...

> прави достаъчно, че ако се използва неговия подход лесно може да се
> окаже , че "гарантирано чистото зареждане" не е толкова гарантирано -
> имам предвид вируси от типа на Чернобил. Нима повечето машини набедени
> за рутери и сървъри , са найстина защитени така щото нищо да не може
> да пише при необходимост в БВИС /BIOS/. С такава модификация също ще
> се окажеш в  ситуацията която сам  си описал по долу.

Както ти каза преди малко, всичко е въпрос на параноя. Проблемът при
твоя метод е, че всяко script kiddie, което може да инсталира kernel
rootkit може да заобиколи твоите проверки. Такива rootkit-ове има
достатъчно и са широко достъпни. 
А rootkit в BIOS-а досега не съм чувал някой да е създавал. А
създаването на такъв който да върши някаква работа (например да
зарежда/модифицира stageN loader) въобще не е тривиална задача (да не
говорим, че този loader освен да зарежда оригиналното ядро, трябва да го
променя и то така, че атакуващият да може да скрие атаката си). 
Е, моите поздравления, ако се сблъскаш с такъв кракер, защото сигурно
работиш в някоя фирма/организация, която може да си позволи да ти плаща 
сума с шест нули на година, за да я пазиш от атакуващи, на които им се
плаща горе-долу същата сума за да те атакуват. 
В такъв случай един съвет (за хонорара ще се уговорим в лична поща) -
най-добре използвай друг компютър, за който си сигурен в коректността на
BIOS-а. А, този съвет е приложим и в случаите, когато не работиш за
гореописаната фирма/организация.

> 
> > Причините са много. Ако са засегнати системни библиотеки е на
> > практика невъзможно да се установи модифицирането им.
> >
> > Ето ви примерче. Носите си на дискета инструмента md5sum и/или
> > sha1sum и на лист хешовете на всички библиотеки. И рзчитате като
> > изпълните тези инструменти от дискетата те да дадат верен резултат.
> > Всичко би било прекрасно, но тези инструменти не четат директно
> > информацията от файловата система. Потока се подава от библиотеките
> > н а glibc. Няма проблеми те да се модифицират така, че при поискване
> > за прочит на някоя библиотека, да бъде подавана немодифицираната й
> > версия (скрита някъде по файловата система), а при изпълнение да се
> > изпълнява модифицираната. Така чрез sha1sum или md5sum вие ще
> > получите информация, че библиотеката е немодифицирана, но това няма
> > да е така.
> >
> >
> Като цяло мога да кажа че идеята е добра, и ако все пак имаш :
> 
> 1. алгоритъм "достатъчно сигурен" , на който да се довериш за да си 
> направиш проверката

Ще чакам след 2-3 седмици да го опишеш.

> 2. Наистина чист источник не само на ключовете но и на съответните 
> пакети /да речем CDROM/

Само сумите и ключовете ще ти бъдат достатъчни. Проблемът с
възстановяване на системата е съвсем отделен и обикновено се решава чак
след като е направен forensic анализ.

> 3. алгоритъм които доверявайки се на 1) "разпознае" опит за 
> неоторизирана подмяна на каквото и да е /койда е от пакетите или части
> от тях/ да го възтановява от 2)

Поне докато не докажеш т.1 всичко това си остава въздух под налягане
(или snake oil).

> 
> мисля, че общо взето е това! Чакам коментари по идеята - но моля те 
> савсем сериозни. Смятам, че може да се заформи интересна дискусия.

В дух на разбирателство и позитивизъм, за последен път ще се
опитам да ти обясня с думи прости, защо е необходимо системата с която
ще извършваш проверка на автентичността на файловете да е гарантирано
чиста. 
Масово разпространените операционни системи в последните 10-15
години са изградени йерархично, а именно userspace програмите най-често
използват библиотеки за да изпълняват задачите си. В общия случай тези
библиотеки се зареждат динамично при стартиране на програмата (за
програми свързани статично с библиотеките ще говоря след малко).
Библиотеките от своя страна ползват API предоставено от ядрото на
операционната система- т.нар. системни извиквания (systemcall). 
Когато даден кракер влезе в някоя система той има няколко варианта да се
укрие и да си подсигури привилегирован достъп. 
Може би най-простият за изпълнение и за откриване е инсталирането на
програма (най-често shell) с вдигнат set-user-id бит и собственик root.
При стартирането на този shell той получава правата на собственика си -
root. 
Друг начин (по-напредничав) е подмяната на редица програми с
модифицирани такива, които извършват действия полезни за кракера -
например ps, lsof, netstat, find, ifconfig и каквито други се сетиш.
Тези програмки са модифицирани по такъв начин, че или осигуряват достъп
до машината, или се грижат кракера да остане незабелязан. В общия случай
тези rootkit-ове се намират чрез просто сравняване на големината на
инсталираните файлове или чрез използване на инструменти от сорта на
AIDE и Tripwire. 
Следващото "ниво" е когато атакуващият подменя примерно libc
библиотеката. Тъй като повечето програми използват готови функции от нея
не е проблем тези функции да се модифицират при определени условия да
извършват някакво действие. Например при извикване на setuid(2)
или seteuid(2) и наличие на определена променлива в обвивката
(environment variable) тези функции, вместо да изоставят допълнителните
привилегии (придобити например чрез suid бит), стартират shell, които
върви с uid=0. Друг пример за полезно вмешателство би било
модифицирането на *read(2), readdir(3) и още няколко други функции. Ако
я няма магическата променлива и някой се опитва да отвори
примерно libc.so.2 тези функции ще му връщат данни от скрито копие на
оригиналната библиотека. Hint: md5sum? rpm? PGP? Clear enough? Този
метод за скриване на нещата остава скрит докато се използват версии на
програмите свързани динамично с подменените библиотеки. В момента в
който се използват чисти програми свързани статично с чисти библиотеки и
грозната действителност лъсва на яве. 
Методът позволяващ най-голяма степен на скритост е модификация на самото
ядро - независимо чрез модули или директна поправка в /dev/kmem. Този
метод по начина си на действие е подобен на lib backdoor, а именно -
чрез модификация на кода на ядрото се променят действията на определени
"интересни" системни извиквания. И тъй като системните извиквания са
единственият начин програма от userspace да направи нещо то всички
програми подлежат на модификация, която остава прозрачна за
администратора. С други думи, ако можеш да модифицираш ядрото, можеш да
постигнеш всичко описано до тук, със значително по-малък шанс да бъдеш
открит. Единственото ограничение е фантазията на атакуващия.

Google ключови думи: adore-ng phrack lkm rootkit code injection lrk suid

Стига толкова, надявам се най-накрая да са ти се изяснили нещата.
По просто не мога да ти го обясня. Може нещо да съм пропуснал, но съм
спокоен - в списъка има достатъчно хора (hi ISECA), които знаят как
стоят нещата, ще се намесят. ;-)


-- 
Best Regards,
Hristo Erinin
============================================================================
A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers).
http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora
To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
============================================================================