Comments 89
Забавно =)
> если кому-то интересно, то могу выложить
Интересно, выкладывай =)
> если кому-то интересно, то могу выложить
Интересно, выкладывай =)
+2
Автор, проплюсовал Вас, где только мог.
Ушел экспериментировать.
Ушел экспериментировать.
+4
У буржуев довольно давно существует такое направление как «memory forensics». Про линух не знаю точно, а вот для венды есть много полезных утилит для работы с полными дампами.
0
Сидя как-то раз в барчике со своим другом проводили подобные эксперименты. Чтобы сильно сократить количество строк можете пройтись так:
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 строк от имени пользователя
+9
А насколько сложные пароли были?
0
Попробовал. Пароля не нашел. Три машины с убунтой и дебианом.
+1
sort -u | uniq -u > /tmp/kdump.uniqЗачем после sort посылать поток ещё и на uniq, если sort с ключиком -u уже делает и сортировку, и убирает дубликаты (делает строки уникальными). Бесполезно дублируете один и тот же функционал в одной командной конструкции.
0
ух, жёстко! В закладки добавил, жаль плюсануть нечем!
*убежал пробовать на своих железках…
*убежал пробовать на своих железках…
-4
А если кроме длинны пароля еще исключать из словаря строки, заведомо не являющиеся паролями — то вообще сказка будет.
Например с 10 машин снять дамп и полностью повторяющиеся данные не брать в словарь больше никогда.
Есть конечно шанс потери пароля, но он пренебрежительно мал.
Например с 10 машин снять дамп и полностью повторяющиеся данные не брать в словарь больше никогда.
Есть конечно шанс потери пароля, но он пренебрежительно мал.
0
Что бы читать память надо быть уже рутом.
А в каких участках памяти лежали пароли и зачем не смотрели?
А в каких участках памяти лежали пароли и зачем не смотрели?
+33
Да, но если рута взяли каким-нить эксплойтом, хацкер может получить пароли таким способом особо не тратя сил/ресурсов на брут и не создавая левых акков и т.д
Еще одна причина, как можно чаще менять пароли на серверах, даже параноидальные.
Еще одна причина, как можно чаще менять пароли на серверах, даже параноидальные.
+5
а я как дурак думал что имея рута, можно тупо поменять пароль нужному логину и делать что надо не перебирая пароли
+9
Если удаеться проникнуть в удаленную систему и получить рута, надо быть действительно дураком чтобы сразу же поменять пароли.
+10
Оригинальный хеш пароля можно сохранить, заменить своим, сделать «дело», вернуть оригинальный хеш обратно.
Кроме того, существуют специальный скрипты. Легитимный пользователь пытается залогиниться, вход первый раз обламывается из-за другого хеша, но введенные данные сохраняются, хешируются и сравниваются с хешем неизвестного, после чего измененный хакером хеш затирается настоящим, и при второй попытке оригинальный пароль принимается. Способ универсальный на все 100%, работает даже на AIX и OpenVMS. Есть варианты попроще, с локальным проксированием FTP или SSH.
Кроме того, существуют специальный скрипты. Легитимный пользователь пытается залогиниться, вход первый раз обламывается из-за другого хеша, но введенные данные сохраняются, хешируются и сравниваются с хешем неизвестного, после чего измененный хакером хеш затирается настоящим, и при второй попытке оригинальный пароль принимается. Способ универсальный на все 100%, работает даже на AIX и OpenVMS. Есть варианты попроще, с локальным проксированием FTP или SSH.
+3
эээ, бекдор с правами рута? зачем менять пароли, а переход из рута под пользователя su username пароля не требует
0
А почему не добавить ssh ключик, например? Кто из нас проверяет каждый день, сколько ключиков стоит на собственном аккаунте?
+1
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 (как настроите).
0
дамп памяти можно попытаться чем-нибудь другим вызвать, без привелегий рута
0
[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 ~]
+6
Спасибо, хорошая статья.
А с какой целью применяется sort -u | uniq -u?
А с какой целью применяется sort -u | uniq -u?
0
UFO just landed and posted this here
под спецсимволами автор определяет команды процессора, которые НЕВОЗМОЖНО набрать с клавиатуры или распечатать в понятном человеку виде.
И вы их не используете, поверьте мне.
И вы их не используете, поверьте мне.
+9
пароль на граб + пароль на биос + защита от сброса кмос.
0
То есть получается в памяти не хеш пароля хранится, а plain-text?
0
Мне одному показалось что «Шварц» на фотке немного косит :)
+1
Было бы интересно, если бы вы добавили еще и способы защиты от этого. По поводу swap на шифрованном разделе диска уже писали, а как можно защитить физическую память от такого доступа? Есть ли возможность запретить доступ к dev/mem или proc/kcore под юзером и оставить его только для root?
0
Вы сами подумайте, что Вы пишете?.. Есть какая-нибудь программа типа «login» — она как-то должна принять пароль у пользователя. Так или иначе, пароль от пользователя приходит в самом что ни на есть чистом виде — в виде букв-цифр-значков с клавиатуры. Так или иначе хоть какие-то миллисекунды, но он будет храниться в памяти, и, ввиду специфики архитектуры современных компьютеров, еще наверняка и закэшируется на 2-3 уровнях. Если есть возможность эту память читать — разумеется, всё это можно вытащить…
0
Вообще по-хорошему после использования эта область памяти должна затираться. Чтобы только в течение каких-то миллисекунд и можно было снять инфо.
0
Вы сами ответили на свой вопрос. Как хранится информация в БД любого современного движка? Хэш с солью. .htpasswd ведь не plain text хранит. Тем более «миллисекунды в памяти»- а не проще тогда кейлоггер поставить, чем читать дамп памяти в 2-4 Гб? Про чтение памяти- я и спросил, можно ли запретить юзеру чтение дампа памяти или нет. Читайте внимательнее.
0
Он и так доступен только руту:
$ 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
А если вы рут, то вы можете делать все, что угодно не только память читать. Так что никаких новых дыр это не несет.
+4
Вообще, /proc/kcore, /dev/mem и т.п. — это в первую очередь инструменты отладки. В production-системах их обычно отключают, во всяких hardened дистрибутивах и патчах (GRSecurity, OWL, Hardened *) — они отключены и запрещены по умолчанию, для затруднения доступа к паролям отдельных пользователей даже при какой-то компрометации root'а.
+3
chmod?
-6
Есть ли возможность запретить доступ к dev/mem или proc/kcore под юзером и оставить его только для root?
Так он и так запрещён под юзером, на это как бы намекает тот факт, что все команды в статье выполняются от имени рута (#).
А вот что будет для обычного пользователя:
$ less /proc/kcore
/proc/kcore: Permission denied
А для доп.защиты можно SELinux поставить…
+1
Глянул на генту-сервере:
$ 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 и наворотов с безопасностью. А у рута куча других способов узнать пароли своих юзеров.
Или я что-то не так понял или паника преждевременна.
+2
А у рута куча других способов узнать пароли своих юзеров.
Ну, если пароль хеширован и пользователь никогда не входил в систему, то будь вы хоть трижды рутом, а пароль этот достать сможете только брутом.
0
В данном случае тоже, если юзер не входил, то неоткуда скопировать пароль.
А если ты рут, то проще подменить бинарники, отвечающие за авторизацию, чем копаться в памяти :)
При первом же логине все будет у вас.
А если ты рут, то проще подменить бинарники, отвечающие за авторизацию, чем копаться в памяти :)
При первом же логине все будет у вас.
+1
А зачем руту пароль пользователя, который никогда не входил в систему? Да и вообще зачем руту искать пароль пользователя, когда он спокойно может его сменить… :-)
+2
Ну конечно может, если ядро соответствующим образом не пропатчить :) Но речь-то шла о том как узнать пароль, а не сменить.
+1
потому что этот же юзер johndoe так же имеет акк на соседнем сервере, с тем же паролем, куда мы (хакер-рут) не имеем пока доступа. Но расшифровав пароль, мы зайдем на тот сервер как белые люди, по ssh, и имея локальный доступ уже будет проще получить рута и там.
0
>-r-------- 1 root root 140737486262272 Мар 18 13:53 /proc/kcore
Это нормальный размер в 140TB памяти? О_о
Это нормальный размер в 140TB памяти? О_о
0
UFO just landed and posted this here
Проверить, содержится ли пароль в памяти можно было и проще:
strings /proc/kcore | grep «текущий реальный пароль»
А еще полезно восстанавливать утраченный текст, к примеру, из полей упавшего браузера.
strings /proc/kcore | grep «текущий реальный пароль»
А еще полезно восстанавливать утраченный текст, к примеру, из полей упавшего браузера.
0
Доволен, и то как работают с памятью nix системы мне очень даже нравится, а смысла так таскать пароли не вижу. Да, /etc/shadow не судьба глянуть?
-2
глянул у себя, размер файла kcore 1018 мегабайт, хотя на ноуте стоит 2 гига памяти, 2 планки по гигу, система 32 бита, генту, должно же быть 2 гигабайта длинна файла?
0
в Убунту шифрование идет по средством sha512
-4
UFO just landed and posted this here
>Мануалы говорят, что полная длина этого файла — это размер физической памяти (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
0
Вот две интересные ссылочки для заинтересованых
www.mcgrewsecurity.com/tools/msramdmp/
citp.princeton.edu/memory/
www.mcgrewsecurity.com/tools/msramdmp/
citp.princeton.edu/memory/
+1
Актуально только если локальные хеши есть, с сетевой аунтификации типа Kerberos не прокатит. Но все равно полезно было узнать, спасибо.
0
Любопытно. Какое ПО у Вас хранит в RAM пароли? Особенно не на desktop.
0
Автор статьи, судя по # в промте, сидит под рутом.
-1
Only those users with full accounts are able to leave comments. Log in, please.
А вы довольны памятью своей Linux системы?