Хозяйничаем на чужом компе.

Итак дорогие мои, условия задачи:
Вы попали на чужой комп, без разницы физически или удалённо
Ваша задача упереть всё что можно, за небольшое время.
Итак кто что сопрёт? (напоминаю что во времени вы ограничины)

p.s. ответы типа: я сопру сидиром, и винт - заранее не принимаются, это низко воровать железо.

Итак дорогие мои, ежели говорить беспристрасно, то очень средне!
Не ожидал я от вас такого подлого удара в спину.
"А зачем, а может не надо, наверное не стоит". СОПЛИ!
Кому не надо - тому не место в рядах славных интернет партизан!

Но хватит о печальном!
Итак для истинно страждущих, и алчущих, скажу:

Я первым делом сопру

1.Куки.
2.Сертификаты (из хранилища сертификатов)
3.файлы .тхт (все в пределах прямой видимости)
4.Аккаунт и хистори от аськи.


На всё это потребуется не больше 2х-3х минут. и уместится на одной дискете.


Может кто-то удивится этому набору?
Прошу задавать вопросы, так же приветствуются ваши соображения и предположения.

Размытые, не конкретные, комментарии будут безжалостно сносится.
Нытьё типа: "а может не следует всё это воровать" будет каратся,
флудеры будут осмеяны, опозорены, их жалкие ники будут преданы забвению.

яб не спёр яб сначяло подарил троянца а потом уж издевался бы над подружками и кактусами попивая пиво из презерватива(это шутка)

если у компа есть выход в нет, то можно просто, как уже сказали постом выше, кинуть троянчик и ждать его выхода в нет и незаметнинько тащить потихоньку всё что хош!

Троянца могут поймать и принять меры, те вычислит кто и когда мог подходить к компу и всё такое. Короче троянец это улика. И после него уж точно к компу не пустят.

Куки мы прём для того чтобы с помощью Cooki Editor а поковырятся в них потом автоматом заходить в почтовые аккаунты, форумы и тд где чел лазил и регился.

Сертификаты (из хранилища сертификатов)- эт сразу понятно тем кто пользует вебмани http://mwp.eseconsult.biz/showthread.php?t=815

файлы .тхт (все в пределах прямой видимости)- Многие юзеры хранят ценную информацию(пассы, аккаунты, названия доменов и ящиков и тд) в тхт файлах, и не всегда далеко её убирают справедливо надеясь на то что пронесёт и у них переть не будут. (помните как ф фильмах шпионы лазиют в мусорных корзинах в надежде найти ценный клочок бумаги с инфой )

Аккаунт и хистори от аськи. - Это уже понятней, там можно тоже много ценного узнать. ..

Для настоящего интернет партизана не бывает мелочей.
Вот такие вот пироги!

В тему



"Логи - друзья хакера

Первое, что делает хакер, заходя на машину - старается вычистить логи. С одной стороны это правильно, применяя логвайпер взломщик никогда не запалится. Но с другой стороны, хакер может забыть, что с помощью логов реально выудить полезную информацию, в том числе и рутовый пароль. Как? Зацени зарисовки реальных взломов, и узнаешь всю правду о таинственных журналах.

1. История - великая наука.

Пошел я как-то на Гугл - ловить жертв. Так я называю поиск бажных скриптов. Задал поиск только php-сценариев с содержанием слова 'html'. То есть, я захотел найти сервера, где существуют скрипты, включающие статические html. Во-первых, я имел возможность проверить жертву на cross-side, во-вторых на баг в include(). Внезапно я столкнулся со сценарием, который показывал содержимое файлов, находящихся в папке "content/". То бишь, ссылка выглядела следующим образом: http://host.com/view.php?path=content/data.html. Я решил изменить патч и вставил туда ../../../../../../../etc/passwd, но сервер отрапортовал "Access Denied" и загрузил дефолтовый контент индексной страницы. Тогда я подумал, что проверка проводится по наличию слова 'content/' и не ошибся. Исправив запрос на content/../../../../../../../../../etc/passwd, я получил желаемый результат - пароли были на экране.

Следующий шаг, который я выполнил - проверил порты на сервере. К моему счастью открытыми оказались 21 и 22 порты. Брутать аккаунт по известному логину - последнее дело, поэтому я решил воспользоваться помощью логов. "Но причем тут логи?", спросишь ты. В системе существует замечательный журнал команд под названием .bash_history, который располагается в домашнем каталоге пользователя. В /etc/passwd присутствовали 10 аккаунтов с валидным шеллом, поэтому осуществить поиск хисторей можно было даже вручную. С третьей попытки мне удалось выцепить содержимое .bash_history одного юзера (запросом http://host.com/viev.php?path=conten.../.bash_history. Там были всякие неинтересные команды типа "vi test.c" и "gcc helloworld.c -o hello", но кроме этого я нашел инфу о том, что юзер активно использует ssh-клиент и лезет им в сторону локальной сети. Внезапно я увидел первый прокол - команду "ssj [email protected]", вслед за этой командой следовал пароль в ЧИСТОМ виде. Это самая распространенная запись, которая может встретиться в .bash_history . Думаю, ты понимаешь, что после обнаружения пароля, я проверил его на правильность и без проблем зашел в систему. Но тут же ощутил, что мне не повезло - на машине крутилась стабильная фряха с ядром 4.9 . Но не все так плохо - пользователь, права которого я получил, входил в группу wheel, посему имел право суидиться на рута (кстати, несколько команд su я узрел в .bash_history). Следующий лог, который я захотел изучить носил имя .mysql_history (лог кверизов к mysql). Выполнив команду grep -i pass .mysql_history, я получил строку, в которой юзер назначал права руту на все базы. Пароль передавался в качестве аргумента функции password() и выглядел очень впечатляюще (этакая строчка в 20 символов) . Я опробовал пассворд через su и тут же получил нулевой uid.

Выводы: файлы .bash_history и .mysql_history имеют важное значение как для хакера, так и для админа. Взломщик может удаленно выцепить конфиденциальные команды через бажный скрипт (нередко права на файл позволяют ему сделать это) и найти среди них пароли (это могут быть как аргументы вызова htpasswd, так и ввод пароля после ошибочных команд su и ssh). Второй файл может быть полезен, если хакер желает узнать пароль на определенную учетную запись. Файло необходимо проанализировать на наличие функции password() и строки 'indentifed by'. Админ может засечь неприметного взломщика по наличию посторонних команд в .bash(mysql)_history. Посему необходимо каждый раз выполнять команду unset HISTFILE, а также удалять историю запросов к БД.

2. Кривоватый радиус.

Как-то раз мне посчастливилось получить доступ к серверу, на котором крутился радиус. То есть сервак выполнял роль VPN-шлюза в какой-то сетке. Мои права на машине были жутко урезаны, но, несмотря на это, я очень хотел покопаться в расшаренных ресурсах локалки и опробовать VPN-подключение. Но, к сожалению, использовать снифер я не мог, поскольку мои привилегии не позволяли, да и расшифровывать MPPE я не умел . В связи с этим у меня оставался лишь один вариант - посмотреть конфиги от радиуса, ибо они были вполне читабельными. И как ты думаешь, что я в них увидел? Конечно же полный логгинг юзера и пароль (который, кстати говоря, рекомендуют включать только в режиме debug). Когда я перешел в /var/log/radius, то понял, что все радиусовые логи имеют пермишены 644! Это же надо быть таким идиотом, чтобы открыть драгоценные логи . Пропарсив журналы я быстро нарыл 40 VPN-аккаунтов, среди которых были какие-то админские учетки. Оставалось лишь прицепиться со своей тачки и просканить локалку. К моему удивлению, в сети я нашел 3 виндовых сервера, в которых имелись дыры ASN.1 библиотеки. Весь мой вечер я занимался установкой VNC, изучением информации на серверах и т.д. и т.п. Словом, день прошел не зря . И все благодаря логам.

Выводы: да, действительно, админы часто включают историю аутентификации к биллингу и хранят эту драгоценную инфу в читабельных логах. Случается, что в конфах радиуса светится слабо зашифрованный пароль к Циске (если таковая, конечно, имеется), а также много других вещей . Словом, за радиусом нужен глаз да глаз, в противном случае можно наплодить хакеров в якобы защищенной локальной сети.

3. Что Apache нам покажет?

И, наконец, последняя инфа о пользе логов. На этот раз админских. Было время, когда мне очень захотелось попасть в одну интересную админку, но к сожалению я не знал пароля. Надо сказать, что аутентификация была отнюдь не Апачевая, а скриптовая. То есть юзеру предлагалось ввести логин и пароль, после чего он перенаправлялся на скрипт проверки авторизации (все происходило с помощью метода GET). Потыкавшись в структуре сервера я чудом нашел каталог admin.host.com/logs/, где лежали 2 файла - access.log и error.log. Да, конечно, подобная вещь - редкость, но порой такие казусы случаются даже на весьма солидных порталах. Я слил access.log к себе на машину (журнал весил целых 10 метров) и стал его изучать. Внутри него я увидел обращения к скрипту, а также заветные параметры с логином и паролем. Зайдя внутрь я добрался до скриптов PhpMyAdmin и аплоадера файлов. Через второй сценарий я смог залить полноценный php-шелл. В общем то, история на этом и заканчивается, т.к. ядрышко на машине имело релиз 2.4.18 .

Выводы: апачевые логи следует прятать от посторонних глаз хакеров, и не в коем случае не передавать логины и пароли методом GET (QUERY_STRING бережно логируется в access.log, что подтверждает мой рассказ). Вообще, всю конфиденциальную информацию лучше транспортировать через SSL, но некоторые особо одаренные админы до сих пор не понимают этого . Часто в исходе удаленной атаки злоумышленник получает права nobody, которых хватает для прочтения access.log'а. Не вредно заглянуть и в error.log, бывает, что в STDERR запускаемых скриптов завалялся какой-нибудь пароль .

4. Время собирать камни.

Итак, ты понял, что история запросов всегда поможет не только получить права юзера, но и взять нулевой уид. Кривой радиус способствует проникновению в защищенную локальную сеть, а access.log позволяет завладеть ключевым паролем к админке. Помимо этих трех взломов, могут иметь место и другие атаки с помощью логов, если журналы ведутся сторонними приложениями с записью всех юзерских обращений. В конце концов, я не сказал о том, что пресловутый /var/log/wtmp всегда поможет тебе (то есть хакеру) определиться с логином, которому можно без проблем сменить пароль. Логи - самое ценное, что есть у хакера, и только они могут разрулить даже самую хреновастую ситуацию."