Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 89
Забавно =)
> если кому-то интересно, то могу выложить
Интересно, выкладывай =)
> если кому-то интересно, то могу выложить
Интересно, выкладывай =)
Автор, проплюсовал Вас, где только мог.
Ушел экспериментировать.
Ушел экспериментировать.
У буржуев довольно давно существует такое направление как «memory forensics». Про линух не знаю точно, а вот для венды есть много полезных утилит для работы с полными дампами.
Сидя как-то раз в барчике со своим другом проводили подобные эксперименты. Чтобы сильно сократить количество строк можете пройтись так:
strings /proc/kcore | grep -A 50 -B 50 {username} | sort -u | uniq -u > /tmp/kdump.uniq
Странно но пароль всегда находился в пределах +-50 строк от имени пользователя
strings /proc/kcore | grep -A 50 -B 50 {username} | sort -u | uniq -u > /tmp/kdump.uniq
Странно но пароль всегда находился в пределах +-50 строк от имени пользователя
Попробовал. Пароля не нашел. Три машины с убунтой и дебианом.
sort -u | uniq -u > /tmp/kdump.uniqЗачем после sort посылать поток ещё и на uniq, если sort с ключиком -u уже делает и сортировку, и убирает дубликаты (делает строки уникальными). Бесполезно дублируете один и тот же функционал в одной командной конструкции.
ух, жёстко! В закладки добавил, жаль плюсануть нечем!
*убежал пробовать на своих железках…
*убежал пробовать на своих железках…
А если кроме длинны пароля еще исключать из словаря строки, заведомо не являющиеся паролями — то вообще сказка будет.
Например с 10 машин снять дамп и полностью повторяющиеся данные не брать в словарь больше никогда.
Есть конечно шанс потери пароля, но он пренебрежительно мал.
Например с 10 машин снять дамп и полностью повторяющиеся данные не брать в словарь больше никогда.
Есть конечно шанс потери пароля, но он пренебрежительно мал.
Что бы читать память надо быть уже рутом.
А в каких участках памяти лежали пароли и зачем не смотрели?
А в каких участках памяти лежали пароли и зачем не смотрели?
Да, но если рута взяли каким-нить эксплойтом, хацкер может получить пароли таким способом особо не тратя сил/ресурсов на брут и не создавая левых акков и т.д
Еще одна причина, как можно чаще менять пароли на серверах, даже параноидальные.
Еще одна причина, как можно чаще менять пароли на серверах, даже параноидальные.
а я как дурак думал что имея рута, можно тупо поменять пароль нужному логину и делать что надо не перебирая пароли
Если удаеться проникнуть в удаленную систему и получить рута, надо быть действительно дураком чтобы сразу же поменять пароли.
Оригинальный хеш пароля можно сохранить, заменить своим, сделать «дело», вернуть оригинальный хеш обратно.
Кроме того, существуют специальный скрипты. Легитимный пользователь пытается залогиниться, вход первый раз обламывается из-за другого хеша, но введенные данные сохраняются, хешируются и сравниваются с хешем неизвестного, после чего измененный хакером хеш затирается настоящим, и при второй попытке оригинальный пароль принимается. Способ универсальный на все 100%, работает даже на AIX и OpenVMS. Есть варианты попроще, с локальным проксированием FTP или SSH.
Кроме того, существуют специальный скрипты. Легитимный пользователь пытается залогиниться, вход первый раз обламывается из-за другого хеша, но введенные данные сохраняются, хешируются и сравниваются с хешем неизвестного, после чего измененный хакером хеш затирается настоящим, и при второй попытке оригинальный пароль принимается. Способ универсальный на все 100%, работает даже на AIX и OpenVMS. Есть варианты попроще, с локальным проксированием FTP или SSH.
эээ, бекдор с правами рута? зачем менять пароли, а переход из рута под пользователя su username пароля не требует
А почему не добавить ssh ключик, например? Кто из нас проверяет каждый день, сколько ключиков стоит на собственном аккаунте?
AIDE проверяет каждый день. Да хоть каждый час :-)
www.cs.tut.fi/~rammer/aide.html
и от лишних SSH ключиков защищает, и от затрояненых ssh и от прочих изменений на машине везде кроме /var/log/, /tmp и /var/www (как настроите).
www.cs.tut.fi/~rammer/aide.html
и от лишних SSH ключиков защищает, и от затрояненых ssh и от прочих изменений на машине везде кроме /var/log/, /tmp и /var/www (как настроите).
дамп памяти можно попытаться чем-нибудь другим вызвать, без привелегий рута
[root@c5-04-s12 ~]# cat /proc/kcore
cat: /proc/kcore: Operation not permitted
[root@c5-04-s12 ~]# uname -a
Linux c5-04-s12 2.6.23.14-107.fc8 #1 SMP Mon Jan 14 21:37:30 EST 2008 i686 i686 i386 GNU/Linux
[root@c5-04-s12 ~]
cat: /proc/kcore: Operation not permitted
[root@c5-04-s12 ~]# uname -a
Linux c5-04-s12 2.6.23.14-107.fc8 #1 SMP Mon Jan 14 21:37:30 EST 2008 i686 i686 i386 GNU/Linux
[root@c5-04-s12 ~]
Спасибо, хорошая статья.
А с какой целью применяется sort -u | uniq -u?
А с какой целью применяется sort -u | uniq -u?
То есть получается в памяти не хеш пароля хранится, а plain-text?
Мне одному показалось что «Шварц» на фотке немного косит :)
Было бы интересно, если бы вы добавили еще и способы защиты от этого. По поводу swap на шифрованном разделе диска уже писали, а как можно защитить физическую память от такого доступа? Есть ли возможность запретить доступ к dev/mem или proc/kcore под юзером и оставить его только для root?
Вы сами подумайте, что Вы пишете?.. Есть какая-нибудь программа типа «login» — она как-то должна принять пароль у пользователя. Так или иначе, пароль от пользователя приходит в самом что ни на есть чистом виде — в виде букв-цифр-значков с клавиатуры. Так или иначе хоть какие-то миллисекунды, но он будет храниться в памяти, и, ввиду специфики архитектуры современных компьютеров, еще наверняка и закэшируется на 2-3 уровнях. Если есть возможность эту память читать — разумеется, всё это можно вытащить…
Вообще по-хорошему после использования эта область памяти должна затираться. Чтобы только в течение каких-то миллисекунд и можно было снять инфо.
Вы сами ответили на свой вопрос. Как хранится информация в БД любого современного движка? Хэш с солью. .htpasswd ведь не plain text хранит. Тем более «миллисекунды в памяти»- а не проще тогда кейлоггер поставить, чем читать дамп памяти в 2-4 Гб? Про чтение памяти- я и спросил, можно ли запретить юзеру чтение дампа памяти или нет. Читайте внимательнее.
Он и так доступен только руту:
$ ll /proc/kcore
-r-------- 1 root root 4831842304 Мар 18 13:44 /proc/kcore
А если вы рут, то вы можете делать все, что угодно не только память читать. Так что никаких новых дыр это не несет.
$ ll /proc/kcore
-r-------- 1 root root 4831842304 Мар 18 13:44 /proc/kcore
А если вы рут, то вы можете делать все, что угодно не только память читать. Так что никаких новых дыр это не несет.
Вообще, /proc/kcore, /dev/mem и т.п. — это в первую очередь инструменты отладки. В production-системах их обычно отключают, во всяких hardened дистрибутивах и патчах (GRSecurity, OWL, Hardened *) — они отключены и запрещены по умолчанию, для затруднения доступа к паролям отдельных пользователей даже при какой-то компрометации root'а.
chmod?
Есть ли возможность запретить доступ к dev/mem или proc/kcore под юзером и оставить его только для root?
Так он и так запрещён под юзером, на это как бы намекает тот факт, что все команды в статье выполняются от имени рута (#).
А вот что будет для обычного пользователя:
$ less /proc/kcore
/proc/kcore: Permission denied
А для доп.защиты можно SELinux поставить…
Глянул на генту-сервере:
$ ls -l /dev/mem
crw-r----- 1 root kmem 1, 1 Фев 18 12:20 /dev/mem
$ ls -l /dev/kmem
crw-r----- 1 root kmem 1, 2 Фев 18 12:20 /dev/kmem
$ ls -l /proc/kcore
-r-------- 1 root root 140737486262272 Мар 18 13:53 /proc/kcore
Т.е. доступ только руту и участникам группы kmem, в число коих обычные юзеры не входят. На ноуте с Ubuntu аналогичные права. Обычные установки, без selinux и наворотов с безопасностью. А у рута куча других способов узнать пароли своих юзеров.
Или я что-то не так понял или паника преждевременна.
$ ls -l /dev/mem
crw-r----- 1 root kmem 1, 1 Фев 18 12:20 /dev/mem
$ ls -l /dev/kmem
crw-r----- 1 root kmem 1, 2 Фев 18 12:20 /dev/kmem
$ ls -l /proc/kcore
-r-------- 1 root root 140737486262272 Мар 18 13:53 /proc/kcore
Т.е. доступ только руту и участникам группы kmem, в число коих обычные юзеры не входят. На ноуте с Ubuntu аналогичные права. Обычные установки, без selinux и наворотов с безопасностью. А у рута куча других способов узнать пароли своих юзеров.
Или я что-то не так понял или паника преждевременна.
А у рута куча других способов узнать пароли своих юзеров.
Ну, если пароль хеширован и пользователь никогда не входил в систему, то будь вы хоть трижды рутом, а пароль этот достать сможете только брутом.
В данном случае тоже, если юзер не входил, то неоткуда скопировать пароль.
А если ты рут, то проще подменить бинарники, отвечающие за авторизацию, чем копаться в памяти :)
При первом же логине все будет у вас.
А если ты рут, то проще подменить бинарники, отвечающие за авторизацию, чем копаться в памяти :)
При первом же логине все будет у вас.
А зачем руту пароль пользователя, который никогда не входил в систему? Да и вообще зачем руту искать пароль пользователя, когда он спокойно может его сменить… :-)
Ну конечно может, если ядро соответствующим образом не пропатчить :) Но речь-то шла о том как узнать пароль, а не сменить.
потому что этот же юзер johndoe так же имеет акк на соседнем сервере, с тем же паролем, куда мы (хакер-рут) не имеем пока доступа. Но расшифровав пароль, мы зайдем на тот сервер как белые люди, по ssh, и имея локальный доступ уже будет проще получить рута и там.
>-r-------- 1 root root 140737486262272 Мар 18 13:53 /proc/kcore
Это нормальный размер в 140TB памяти? О_о
Это нормальный размер в 140TB памяти? О_о
Проверить, содержится ли пароль в памяти можно было и проще:
strings /proc/kcore | grep «текущий реальный пароль»
А еще полезно восстанавливать утраченный текст, к примеру, из полей упавшего браузера.
strings /proc/kcore | grep «текущий реальный пароль»
А еще полезно восстанавливать утраченный текст, к примеру, из полей упавшего браузера.
Доволен, и то как работают с памятью nix системы мне очень даже нравится, а смысла так таскать пароли не вижу. Да, /etc/shadow не судьба глянуть?
глянул у себя, размер файла kcore 1018 мегабайт, хотя на ноуте стоит 2 гига памяти, 2 планки по гигу, система 32 бита, генту, должно же быть 2 гигабайта длинна файла?
в Убунту шифрование идет по средством sha512
>Мануалы говорят, что полная длина этого файла — это размер физической памяти (RAM) плюс 4KB, но повертев этот файл на разных системах я пришел к выводу, что размер файла равен размеру RAM + SWAP.
А где ещё почти 2 гектара?! o_O
$ sudo ls -lh /proc/kcore
-r-------- 1 root root 1016M Мар 18 16:25 /proc/kcore
$ free -m
total used free shared buffers cached
Mem: 2024 1975 49 0 29 1286
-/+ buffers/cache: 658 1366
Swap: 972 32 940А где ещё почти 2 гектара?! o_O
Вот две интересные ссылочки для заинтересованых
www.mcgrewsecurity.com/tools/msramdmp/
citp.princeton.edu/memory/
www.mcgrewsecurity.com/tools/msramdmp/
citp.princeton.edu/memory/
Актуально только если локальные хеши есть, с сетевой аунтификации типа Kerberos не прокатит. Но все равно полезно было узнать, спасибо.
Любопытно. Какое ПО у Вас хранит в RAM пароли? Особенно не на desktop.
Автор статьи, судя по # в промте, сидит под рутом.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
А вы довольны памятью своей Linux системы?