Segíts tesztelni a ContainerSSH 0.4-et

Linux-security

A segítségetekre van szükségem. Tesztelem a készülő ContainerSSH 0.4 preview releaset és tesztadatokra lenne szükségem. Kérlek, teszteld le:

TÖRÖLVE

Tetszőleges felhasználónévvel/jelszóval jelentkezz be és légyszi jelezd ha találsz valamilyen anomáliát. Egy bugot már találtunk, MacOS/kitty kombóban a prompt kétszer jelenik meg.

Ha találtál valamit, légyszi küldd el az oprendszeredet, terminálod típusát, a teszt időpontját, az IP címedet, és egy képernyőképet a handshake@containerssh.io cimre. Igény szerint megtalálod a GPG kulcsunkat itt.

Az adataidat természetesen töröljük amint a release elkészült, illetve igény szerint értesítünk arról, hogy mi volt a probléma.

Köszönöm szépen a rászánt idődet.

Update: köszönjük  tesztelést, a honeypotot lekapcsoltuk.

Update 2: Megjelent, köszönjük mindenkinek a segítséget!

  • 1040 megtekintés

( uid_395 v | 2021. 01. 23., szo – 16:16 )

Egy 0.73 -as putty-al Win10 alól semmi extrát nem találtam. (emailt direkt nem küldök, mert nem fedeztem fel semmi hibát)

Pár parancsot futtatgattam, azt kb ennyi.

( ibenny v | 2021. 01. 23., szo – 16:19 )

Szerkesztve: 2021. 01. 23., szo – 16:19

Bejelentkeztem, éppen Win 10 alól, putty-t használva, hibát nem érzékeltem (ezért nem megy levél sem).

( STP | 2021. 01. 23., szo – 16:40 )

Android 10 (kernel: 4.14.116), Reflection 1.6.0.86

Session handshake: Encryption key exchange with host failed.

( Adamyno | 2021. 01. 23., szo – 16:53 )

Jónak tűnik.

Terminál: Yakuake 20.12.1

adam@adam-tp
OS: Manjaro 20.2.1 Nibia
Kernel: x86_64 Linux 5.4.89-1-MANJARO
Uptime: 20h 31m
Packages: 1341
Shell: bash
Resolution: 2820x1440
DE: KDE 5.78.0 / Plasma 5.20.5
WM: KWin
GTK Theme: Breath [GTK2/3]
Icon Theme: breath2
Disk: 55G / 211G (28%)
CPU: Intel Core i7-3740QM @ 8x 3.7GHz [54.0°C]
GPU: Mesa DRI Intel(R) HD Graphics 4000 (IVB GT2)
RAM: 5236MiB / 15716MiB

 

- Indítsd újra a gépet! - Az egészet? - Nem, a felét...

( Nyosigomboc v | 2021. 01. 23., szo – 17:09 )

Szerkesztve: 2021. 01. 23., szo – 17:14

A /home/-ba tehetnetek valami usert. Szoval ha bela/passwd-del jelentkezett be, akkor legyen egy /home/bela konyvtar, es onnan is induljon!

A sima ssh mukodott a desktop gepemen es a telefonomon. Viszont ha mountolni akartam, az disconnectalt. Nem tudom, hogy ez cel-e egyaltalan, hogy mukodjon, ha igen, akkor kuldok rola mailt (egyelore nem tettem). De az is lehet, hogy valamit felreirtam (sshfs-t scriptbol szoktam hasznalni, ezt is onnan vagtam ki). Repro:

nyos@hex:~$ sshfs -o reconnect,allow_other,uid=1000,gid=1000 194.182.184.97:/ testmnt/
nyos@194.182.184.97's password:  
remote host has disconnected

szerk: scp sem megy, ez lehet, hogy megint nem baj:

nyos@hex:~$ touch /tmp/x
nyos@hex:~$ scp /tmp/x 194.182.184.97:/tmp/
...
unknown user 1000
lost connection

Mi a cel? Hogy probalja altalaban a tamado feltenni a rootkitjet a honeypotra? curl/wget (elobbi nincs fent, utobbi igen)? Vagy ramasolja valami massal?

A strange game. The only winning move is not to play. How about a nice game of chess?

Köszi szépen a visszajelzést, tettem bele usert és pár utilityt. Az SSHFS nem fog működni, mivel jelenleg nincs megoldásunk arra, hogy a konténerbe beproxyzunk egy SCP kapcsolatot, viszont az SFTP menni fog. Ha szeretnél feltölteni, akkor mindenképpen SSH multiplexálással próbálkozz, mivel a konténerek a kilépés után törlésre kerülnek.

A cél jelenleg az, hogy leteszteljük, hogy az interaktív konzol normálisan működik-e, illetve hogy valakinek sikerül-e megborítania a szervert.

Debian Buster
OpenSSH_7.9p1

Rendellenes viselkedés nem volt tapasztalható. Pár fura dolog viszont gyanús lehet a humán támadónak.

Szokatlan, hogy /-be léptet be és nem a home-omba.
Ahogy Nyosi írta, ha bela userrel lépek be, létrejöhetne a /home/bela és azzal indulhatna, mint working directory. Így ahogy most van minimum gyanút keltő.

pid 1-et írták már
de gyanút kelt az is, hogy szegényes a pid lista

/etc/fstab üres

/etc/mtab felfedi, hogy docker-ben vagyunk
(/.dockerenv eleve sejteni engedi mondjuk)

mount mond egy olyat, hogy:
/dev/vda1 on /etc/hostname type ext4 (rw,relatime)
wtf

Fura, hogy nincs mondjuk egy less

Nem tudom mennyire cél a nem lelepleződés és emberi támadó számára meggyőzőnek levés. Egy script nem valószínű, hogy törődik ezekkel, de aki szokott linuxra ssh-zni annak pár dolog feltűnhet.

Köszönöm szépen, ezek mind jogosak. Futott már egyszer ez a konfiguráció és emberi támadó nem volt tapasztalható az alatt a 2-3 nap alatt. Jelenleg egyelőre az a cél, hogy stabilan működjön minden egy elég nagy refaktor után, azért is kértem segítséget. Ha kész a release szeretnék egy hosszabb távú elemzést futtatni a bejövő támadásokról.

( gyuri23 | 2021. 01. 23., szo – 17:25 )

xubuntu 20.04, tilix

ok

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

( zitev v | 2021. 01. 23., szo – 17:44 )

Legutóbbi JuiceSSH/Android alól rendbenlévőnek tűnik,  teszt userrel beléptem, pár parancsot próbáltam, aztán kiléptem... 

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

( kroozo v | 2021. 01. 23., szo – 18:47 )

Cuki a pid 1 :) De nem vagyok benne biztos, hogy nem vagy előrébb a dockerben levő dumbinittel (vagy tinivel, vagy a tök se tudja melyiket emelték bele végül). Illetve hosszasabb belegondolás nélkül egy kicsit furcsa, hogy a ppidje a valódi bash shellnek 0. Lehet, hogy nem egészen az történik ,mint amit gondoltál.

Illetve lehet, hogy egy unminimize ráférne, ha már interaktív. Pl man sincs így.

Egyébként nem verte ki a biztit semmi. yakuake meg konsole alól.

Köszi a tesztelést.

Az 1-es pidre már van az agentben support, csak ebbe a verzióba nem került bele. Hosszú távon az a cél, hogy az agenten kivül semmit ne kelljen betenned az imagebe.

Egyébként ez a default image, a use casek többségére az az elvárás, hogy saját imaget csinálsz. Nem akartuk a default image méretét túltolni.

( WG | 2021. 01. 23., szo – 18:51 )

Szerkesztve: 2021. 01. 23., szo – 18:58

Szerintem sikerült megborítanom, bár ez nem az ssh hibája:

cat /dev/zero > ~/zerofill

után nem tudok másik terminálbóé belépni

Permission denied, please try again.

Bocs :)

Egyébként Debian 10 latest és openSuse Tumbleweed latest alól minden más rendben.

( mogorva v | 2021. 01. 23., szo – 18:59 )

Android JuiceSSH egy idő után aktivitás közben kidob. Saját nick-kel voltam ha néztek logokat.

( kikuchiyo | 2021. 01. 23., szo – 20:08 )

Fedora 33, gnome-terminal, tmux: jonak tunt, probaltam kiiratni random binaris szemetet, azt is tulelte. Aztan kiprobaltam egy bash forkbombot, azutan szinte azonnal kidobott - szandekos?

( Mcsiv v | 2021. 01. 23., szo – 21:44 )

win10 / putty: nem futottam hibába

far manager 3.x / sftp: csatlakozás/letöltés/feltöltés közben nem futottam hibába

// Happy debugging, suckers
#define true (rand() > 10)

( Proxy | 2021. 01. 23., szo – 22:03 )

Üdv,

iPad 14.3 ios

prompt2 és WebSSH app, minden rendben volt.

( uid_17626 | 2021. 01. 23., szo – 22:09 )

Minden session saját chroot-ot kap?

Ahogy a kollégák mondták fentebb, a rendszer jelenleg két üzemmódot támogat: per-connection és per-session konténer. Az előbbi akkor csinál konténert amikor belépsz és kilépéskor takarít, az utóbbi pedig minden SSH-n belüli sessionnek csinál külön konténert. Tervben van egy olyan funkció ami perzisztensen meghagyja a konténereket, de ehhez a clusterezést végig kell gondolni. Egyelőre ez nem nagyon merült fel mint igény, mert ahol elvárás az adatok megtartása ott kintről kerül bemountolásra pl. a home könyvtár.

( arpi_esp v | 2021. 01. 23., szo – 22:18 )

root userrel belepve nem tudok belepni a /root dirbe...

ilyet is ir:

arpi-i7MacPro:~ arpi$ ssh root@194.182.184.97
...
root@194.182.184.97's password:
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)

ubuntu@bitcoin:/$ whoami
ubuntu

( koqsz | 2021. 01. 23., szo – 22:49 )

Linux Mint 20.1 ssh/sftp rendben minden.

( zither | 2021. 01. 23., szo – 23:45 )

Windows 10 + mintty 3.0.6 (régebbi cygwin telepítés)

Beléptem, pár parancsot futtattam, kiléptem. Rendben lévőnek tűnik.

Zavard össze a világot: mosolyogj hétfőn.

( BBoy v | 2021. 01. 23., szo – 23:46 )

Szerkesztve: 2021. 01. 23., szo – 23:47

Android fronton csináltam két programmal tesztet:

Termux 0.101

illetve

Termius 5.1.0

Egyikkel sem volt probléma! ;-)

( myk | 2021. 01. 24., v – 10:26 )

Szerkesztve: 2021. 01. 24., v – 10:30

Win10 PS

miklos account-tal, megy hiba nélkül (ezért nem megy levél)

Juice (3.2.1) Android 10 (1+7)

juice account-tal, megy hiba nélkül (ezért nem megy levél)

( arpi_esp v | 2021. 01. 24., v – 15:05 )

amugy ha en irtek botot ami probalgatja az ssh szervereket, tuti azt csinalnam, hogy eloszor valami biztosan rossz user+jelszo komboval probalkoznek es ha az is beenged akkor rogton tudom hogy ez csapda... 

vagy az ilyen honeypot-oknak nem az lenne a lenyege, hogy megtevesztesig hasonlitson az igazi rendszerre?

( miq | 2021. 01. 24., v – 19:18 )

Szerkesztve: 2021. 01. 24., v – 21:00

Az ssh bannerjét szerintem érdemes lehet valami szokványosra, mondjuk OpenSSH-ra cserélni. Lehet, hogy van akit/amit már ez elijeszt.

~# telnet  194.182.184.97 22
Trying 194.182.184.97...
Connected to 194.182.184.97.
Escape character is '^]'.
SSH-2.0-ContainerSSH

 

Belépve is sok dolog van, ami feltűnhet.  Pl. a gyanúsan kevés process, az init rendszer hiánya, a ssh-nál használt felhasználónévtől eltérő felhasználó, netstat nem mutatja az ssh-t, amivel bejöttem, nincs hálózat, a mount-ban rögtön elől az overlay. Ha kicsit is szétnéz a bejutott script, hamar gyanút foghat.

( Crayon | 2021. 01. 25., h – 11:12 )

hi! 

win10, kitty 0.74.4.2p: OK

ubuntu 20.04 terminal-ról: OK

illetve két megjegyzés:

érdemes lenne kipróbálni screen vagy tmux terminal multiplexer is működik-e rendesen, bár a látottak alapján nem tűnik problémásnak.

X11 forwardingnak van értelme? lesz GUI-s workload a konténerben?

Koszi szepen, a kitty erdekes mert MacOS-en sorduplikaciot tapasztalt a kollega. A terminal multiplexer mukodik, ahogy pl. az mc is. Ez annak koszonheto, hogy SSH szinten semmi kulonoset nem kell beallitani hozza.

Az X11-nel lehet ertelme, hiszen a megjelenites a kliens gepen van, bar utoljara 10 eve lattam olyat aki szerverrol szeretett volna X11-elni. Ezt jelenleg nem tamogatjuk, ha lesz ra igeny akkor beepitjuk. A TCP forwardingra es SSH agent supportra valoszinuleg nagyobb igeny van.

( Balooo v | 2021. 01. 25., h – 16:43 )

debian alatt connect ok

tegyetek a usernek sudo jogot, had érezze a törődést
emulálni neki valami  ethernet interface-t?  ne csak a loopback legyen :)
wget az mukoggy bár letölteni nem lehet semmit, az még jó lenne ha működne,  el lehetne kapni pár hasznos, haszontalan tool-t (is akár) plusz hozzá  való usert, passt.

Nincs a világon se jó, se rossz. A gondolkodás teszi azzá... (W. Shakespeare)

( krobi | 2021. 01. 25., h – 17:43 )

Windows 10 alól a Windows Terminal 1.4
Nincs gond, de pl. a su root esetén, bruteforce működne? vagy kivág egy időután ha sokat próbálkozom?

( janoszen v | 2021. 03. 09., k – 16:51 )

Kedves mindenki,

köszönjük szépen a kiadós teszteléseteket. Az eredmények alapján megtoltuk a 0.4-es fejlesztést még egy ciklussal és jópár egyenetlenséget kiküszöböltünk, valamint kapott egy új és részletesebb szöveges logot is. A, remélhetőleg utolsó, preview release 0.4.0-PR4 megjelent, és ha nincs vele komolyabb gond, akkor ez lesz a végleges 0.4.0 is.

Köszönjük a rászánt időtöket, amint megvan a végleges release jelentkezünk. :)