Linux за българи: Форуми

Като root:


После връзвате ssh към localhost на порт 12345:


И ще установите нещо забавно - всяка парола работи (без празната).

Мистериозно направо, човек ще си помисли че това е някакъв бекдор в sshd :)

Награда за първия, който открие защо се получава така (хинт: sshd не е виновен) :)

Хм ОК може би sshd все пак е донякъде виновен на второ четене.

Това не обяснява ли нещата
sshd (OpenSSH Daemon) is the daemon program for ssh. Together these programs replace rlogin(1) and rsh(1), and provide secure encrypted communications between two untrusted hosts over an insecure network

В случаят няма да е особено secure при положение че всяка парола работи.

Това ти си го проверявал. Не разбрах, това няква недомислица ли е?

Недомислица не е много точно казано. Въпреки това ми е трудно да дам определение. Безспорно има не особено смислено решение, което обаче само по себе си е невинно. В комбинация с други, външни фактори обаче, се получава много интересно стечение на обстоятелствата. Няма на кой да се набива канчето в случая, защото нищо фатално лошо не се е случило в крайна сметка. Просто ситуацията е забавна. Няколко безобидни неща (не казвам че всички от тях са силно смислени де) се комбинират и се получават странни странични ефекти :)

Смяташ ли да пишеш където трябва? Не е безобидно. Ама изобщо. Външните фактори са си почти винаги налице. Както се разбра, не е необходимо да си вързан за мрежата, за да нямаш външни фактори.  ;D

Не смятам поради няколко причини - първо не съм го открил аз, второ openssh са представили опция за отстраняването му (пребилдвайки sshd по съответния начин, дори не се налага да се пачва кода - но очевидно на всички дистрибуции които видях не го правят) и трето и най-важно: това не е уязвимост и не е опасно. За да го направиш, трябва вече да си root, а ако вече си root има безброй други начини да бекдорнеш машината, въпреки че този е доста лесен. Не е дори достатъчно "скрит" поради ред причини.

Външните фактори нямат нищо общо с мрежата, имат общо с друг софтуер, който на практика е стандарт в линукс и не се сещам да не се ползва някъде (освен в разни embedded системи, където отсъства просто защото целта е да се пести памет).

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

Крайният резултат не е интересен, забавното е защо се случва.

Позабравил съм. Имаше нещо с подменяне на области в паметта, с каквото искаш. Хубава идея, само не помня доколко беше възможно.

Няма мазане по чужда памет. Съвсем просто е обяснението, същевременно много елегантно навързано :)

ОК още малко подсказване: ltrace, ls и cat (евентуално и less или grep) са напълно достатъчни за да стане ясно какво се получава. Няма нужда да се рови по сорсове да се търси обяснението, не че няма да помогне, ама е доста по-трудния път.

Дебиян : Хака работи без никакви проблеми,мога да се логна не само в root, но и в който си искам юзър от съществуващите.

FreeBSD : Не става!

Mac OS X : Не става !

Тъй че спим спокойно :P

Между другото, преди време забелязах, че
#scp нещо-от-някъде ~
създава файл с име ~

За MacOSX съм повече от убеден че няма да стане, но за FreeBSD съм учуден честно казано. Мислех че и там се ползва същото като в линукс. Можеш ли да го пуснеш (ssh) с -vvv и да видим какво ще изплюе, много ми е интересна причината поради която те отрязва :)

Интересно. Само, че за да се наиграеш с това, трябва да знаеш малко езици. Коя функция, какво прави. И да знаеш какво търсиш. Обачееее.... толкова е интересно.  ;D Преди доста време се бях хванал със С, но липсата на достъп  до компютър си каза думата.
А как може да се чете от определен адрес в паметта? Вижда се например, че има отворен файл от някоя програма и с какво може да се прочете този файл в  RAM. В /proc някъде ли в "папката" на процеса? Или има друг начин? И има ли смисъл да се разглеждат разни FIFO файлове?
Тук ($2) намерих доста интересно четиво. Но пак - за да си толкова гъвкав в мисленето и да търсиш отговори, са нужни малко повече от базови познания. Колкото и да ти щрака сивото, трябва да има върху какво да стъпиш.
Ти беше писал статия за нарочно пробитите GSM мрежи, но как стои въпроса с преноса на данни в тези мрежи и ако има едно подобаващо количество натрупани captcha, до колко е възможно да бъдат разкрити от това разни пароли за мейли, скайп, фейсбуци? Аз съм с  телефон дето има само календар и будилник на него, та не съм притеснен относно това, но може би и за това съм с такъв телефон.  :D

Специално за разплитането на този казус мисля че 90% от това което ти трябва са си сисадмински умения, няма толкова много общо с програмиране като цяло, по-скоро с това как работи софтуера.

Също така не мисля че трябва толкова да се обвързват нещата с конкретен език - да, става въпрос за API имплементирано на C, но същото твърде вероятно си има и питонски и java и тем подобни wrapper-и и езикът няма огромно значение. Може да го приемеш просто като функция и да се абстрахираш от всякакви подробности на езика. Определено не се изисква да имаш особено задълбочени познания в програмирането и C за да "разплетеш" загадката. Ще ти помогне може би само за да изясниш доколко голяма е вината на sshd :)

Не мога да го reproduce-на, но ми изглежда, че PAM бърка sshd => su. Но не мога да си обясня защо паролата в случая няма значение?

root@XXX /etc/pam.d> cat su

# This allows root to su without passwords (normal operation)
auth       sufficient pam_rootok.so

Ясна е работата :)

Доста топло :)

Сега остава да се разбере защо като преименуваш sshd на su, pam решава че е su, а не sshd. Защото примерно
същата работа можеш да я сътвориш линквайки login или passwd като su, но в този случай няма да мине всяка парола (алтернативно с passwd като те пита за старата парола, няма да мине всяка парола).

Тук за съжаление мисля вече са тези 10% дето са по-свързани с C.

Между другото каква е дистрибуцията и дали sshd-то не е конфигурирано да автентицира само на база ключове? В последният случай няма как да се reproduce-не, но е възможно и да са си поиграли малко при билдването на openssh :)

При мен хака не работи.: Centos 5

Това е доста странно...сигурен съм че тествах на VM с centos, беше 6.нещо и работеше. Сега ще трябва да дърпам ISO-та с по-стара версия и да разбера откъде идва тая работа.

Ако нещо логовете ти говорят:
~/su -oPort=12345 -oLogLevel=DEBUG


Jan 18 23:46:10 localhost su[4028]: debug1: Bind to port 12345 on ::.
Jan 18 23:46:10 localhost su[4028]: Server listening on :: port 12345.
Jan 18 23:46:10 localhost su[4028]: debug1: Bind to port 12345 on 0.0.0.0.
Jan 18 23:46:10 localhost su[4028]: error: Bind to port 12345 on 0.0.0.0 failed: Address already in use.
Jan 18 23:46:10 localhost su[4028]: Generating 768 bit RSA key.
Jan 18 23:46:10 localhost su[4028]: RSA key generation complete.

Jan 18 23:47:28 localhost su[4031]: debug1: rexec start in 4 out 4 newsock 4 pipe 6 sock 7
Jan 18 23:47:28 localhost su[4028]: debug1: Forked child 4031.
Jan 18 23:47:28 localhost su[4031]: debug1: inetd sockets after dupping: 3, 3
Jan 18 23:47:28 localhost su[4031]: Connection from 127.0.0.1 port 44582
Jan 18 23:47:28 localhost su[4031]: debug1: Client protocol version 2.0; client software version OpenSSH_4.3
Jan 18 23:47:28 localhost su[4031]: debug1: match: OpenSSH_4.3 pat OpenSSH*
Jan 18 23:47:28 localhost su[4031]: debug1: Enabling compatibility mode for protocol 2.0
Jan 18 23:47:28 localhost su[4031]: debug1: Local version string SSH-1.99-OpenSSH_4.3
Jan 18 23:47:28 localhost su[4032]: debug1: permanently_set_uid: 74/74
Jan 18 23:47:28 localhost su[4032]: debug1: list_hostkey_types: ssh-rsa,ssh-dss
Jan 18 23:47:28 localhost su[4032]: debug1: SSH2_MSG_KEXINIT sent
Jan 18 23:47:28 localhost su[4032]: debug1: SSH2_MSG_KEXINIT received
Jan 18 23:47:28 localhost su[4032]: debug1: kex: client->server aes128-cbc hmac-md5 none
Jan 18 23:47:28 localhost su[4032]: debug1: kex: server->client aes128-cbc hmac-md5 none
Jan 18 23:47:28 localhost su[4032]: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
Jan 18 23:47:28 localhost su[4032]: debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
Jan 18 23:47:28 localhost su[4032]: debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
Jan 18 23:47:28 localhost su[4032]: debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
Jan 18 23:47:28 localhost su[4032]: debug1: SSH2_MSG_NEWKEYS sent
Jan 18 23:47:28 localhost su[4032]: debug1: expecting SSH2_MSG_NEWKEYS
Jan 18 23:47:28 localhost su[4032]: debug1: SSH2_MSG_NEWKEYS received
Jan 18 23:47:28 localhost su[4032]: debug1: KEX done
Jan 18 23:47:28 localhost su[4032]: debug1: userauth-request for user root service ssh-connection method none
Jan 18 23:47:28 localhost su[4032]: debug1: attempt 0 failures 0
Jan 18 23:47:28 localhost su[4032]: debug1: userauth-request for user root service ssh-connection method keyboard-interactive
Jan 18 23:47:28 localhost su[4032]: debug1: attempt 1 failures 1
Jan 18 23:47:28 localhost su[4032]: debug1: keyboard-interactive devs
Jan 18 23:47:28 localhost su[4032]: debug1: auth2_challenge: user=root devs=
Jan 18 23:47:28 localhost su[4032]: debug1: kbdint_alloc: devices ''
Jan 18 23:47:38 localhost su[4032]: debug1: userauth-request for user root service ssh-connection method password
Jan 18 23:47:38 localhost su[4032]: debug1: attempt 2 failures 2
Jan 18 23:47:38 localhost su[4031]: Failed password for root from 127.0.0.1 port 44582 ssh2
Jan 18 23:47:42 localhost su[4032]: debug1: userauth-request for user root service ssh-connection method password
Jan 18 23:47:42 localhost su[4032]: debug1: attempt 3 failures 3
Jan 18 23:47:42 localhost su[4031]: Failed password for root from 127.0.0.1 port 44582 ssh2
Jan 18 23:47:44 localhost su[4032]: debug1: userauth-request for user root service ssh-connection method password
Jan 18 23:47:44 localhost su[4032]: debug1: attempt 4 failures 4
Jan 18 23:47:44 localhost su[4031]: Failed password for root from 127.0.0.1 port 44582 ssh2
Jan 18 23:47:44 localhost su[4032]: Connection closed by 127.0.0.1
Jan 18 23:47:44 localhost su[4032]: debug1: do_cleanup
Jan 18 23:47:44 localhost su[4031]: debug1: do_cleanup

Сега като се замисля тази мойта система Centos 5 е ъпгрейт на много стар линукс. Бях затъркал всичко /usr /bin /sbin ... и т.н. но си запазих /etc и хоме

Та мисълта ми е да не би все още да ми използва някоя стара конфигурация от /etc/.....  ??? ??? ???

Мне става много ясно за жалост. Вероятно са билднали openssh както трябва (ltrace може да даде повече информация, ама това всичкото да се изсипе тук няма да е много добра идея).

Сега съм в малко странно положение - интересно ми е защо не се получава, но ако помоля за това, което би ми помогнало да разбера причината, ще издам защо се получава :)

Може да направим така, след няколко (примерно 3 или пък 5) поста или пък просто докато решим, ако не е разгадано всичко, обяснявам как и защо работи това в детайли. Аз като гледам вече сме много близо така или иначе :)

А изследването защо не сработва ще е поне толкова интересно и на мен специално :)

Доколкото виждам openssh вика pam_start по следния начин:

pam_start(SSHD_PAM_SERVICE, user, &store_conv, &sshpam_handle);

SSHD_PAM_SERVICE е:

# define SSHD_PAM_SERVICE      __progname

__progname = ssh_get_progname(argv[0]);

което пък връща или argv[0], така че явно pam е невинен :) странно решение на авторите на openssh

Иначе на Debian го тествах и проработи, просто първия път не го бях пуснал с root заради параноя :)

Под OSX пак тръгва да ползва pam/su, но гърми с:

Jan 19 01:57:55 XXX su: root [pam][27913]: in pam_sm_acct_mgmt(): Unable to obtain the remote username.

Ако си бил root юзер:
----------------------------

и напишеш:

или даже да се пробваш отново като root

Няма да ти иска никаква парола - и така е правилно. Нали и без това като root юзер вече си имал всички права върху обикновенните юзери.

Доколкото виждам openssh вика pam_start по следния начин:

pam_start(SSHD_PAM_SERVICE, user, &store_conv, &sshpam_handle);

SSHD_PAM_SERVICE е:

# define SSHD_PAM_SERVICE      __progname

__progname = ssh_get_progname(argv[0]);

което пък връща или argv[0], така че явно pam е невинен :) странно решение на авторите на openssh

Иначе на Debian го тествах и проработи, просто първия път не го бях пуснал с root заради параноя :)

Загадката е разгадана :)

Ако билднеш sshd с -DSSHD_PAM_SERVICE=sshd, нещата ще се оправят.

Защо sshd избира argv[0] като servicename за pam е не много смисленото. Не е осъдително де, но не виждам огромен смисъл. Предполагам са искали да оставят възможност да преименуваш sshd демона, въпреки че на кой му трябва това не знам. За друга причина не мога да се сетя. Забавното става като го преименуваш на su и sshd отвори pam сесия със servicename "su". Това задейства su конфигурацията на pam откъдето вече минава всяка парола. За да се "задейства" pam_rootok.so обаче, трябва uid на процеса да е 0. Обаче sshd се стартира като root и "сдава" правата (със setuid()) по-късно, поради което първия ред в /etc/pam.d/su сработва и автентицира само защото преименувания sshd работи като root.

или даже да се пробваш отново като root
Код:

su root

Няма да ти иска никаква парола

Не мисля че това е много правилно поведение и не би трябвало да се случва. Дали няма някакъв механизъм за кеширане на пароли, както в sudo и оттам да идва...макар че ме съмнява. Изглежда странно.

Това е доказателство, че не може да имаш доверие на стрингове (в настоящата им имплементация) при организация на правата.
За съжаление при подобно положение, добавянето на нов layer от абстракция ще причини повече проблеми отколкото положителен ефект.
Според мен трябва да се промени самия код на sshd демона (дали чрез rebuild или patch), защото ако трябва да се пипа логиката в линукс, ще стане доста грозно. sshd е entry point-a на проблема, и трябва да се обърне внимание на него.

От гледна точка на сигурност няма проблем наистина. Защо - защото ние вече сме root и това предполага, че защитата вече е преодоляна без значение правомерно или не. Така че проблема е комплексен и се решава с допълнителна сложност, която не оправдава целта :)

Това е доказателство, че не може да имаш доверие на стрингове (в настоящата им имплементация) при организация на правата.
За съжаление при подобно положение, добавянето на нов layer от абстракция ще причини повече проблеми отколкото положителен ефект.
Според мен трябва да се промени самия код на sshd демона (дали чрез rebuild или patch), защото ако трябва да се пипа логиката в линукс, ще стане доста грозно. sshd е entry point-a на проблема, и трябва да се обърне внимание на него.

От гледна точка на сигурност няма проблем наистина. Защо - защото ние вече сме root и това предполага, че защитата вече е преодоляна без значение правомерно или не. Така че проблема е комплексен и се решава с допълнителна сложност, която не оправдава целта :)

Това мнение силно ми напомня на http://weknowmemes.com/generator/uploads/generated/g1390401315884110280.jpg :-)

Само да кажа, че на NetBSD 6.x това не работи.

А-а-а-а аз повече с отворен код няма да се занимавам !!! (За пояснение - това беше соларис 11.1 не опенсоларис )