2013. szeptember 27., péntek

Windows 7 port forward + NAT + Kali Linux 3G T-mobile stick

Ma két dolog beállítását fogom leírni. Az egyik a Windows 7 alatt a port forward és a NAT beállítása.
ez elsősorban akkor kellhet, ha virtuális gépekkel szeretnénk dolgozni, de csak egy hálózati kimenetet tudunk felhasználni. ez tipikusan az az eset, amikor mobil stick-ről használjuk a hálózatot és a virtuális gépünket is elérhetőve szeretnénk tenni.
Itt ugye azt a problémát kell megoldani, hogy a gép internetes ip címére érkező csomagok a virtuális gép adott portján landoljanak. Ehhez a virtuális gépen a hálózatot állítsuk Host-Only módba.
Utána adjuk ki a következő parancsot: (nem szükséges adminisztrátori jog hozzá)
netsh interface portproxy add v4tov4 listenport=3000 connectaddress=192.168.56.101 connectport=3000
Ez azt fogja előidézni, hogy a gépen a külső interfészen a 3000 portra érkező csomagokat a virtuális gépünk 3000 portjára fogja automatikusan (natolva) továbbítani. Így a virtuális gépen futó szolgáltatásokat elérhetővé tudjuk tenni az internet irányából. Ez a beállítás nagyon jó, de ha a virtuális gépről is akarunk kifelé forgalmat indítani, akkor az ebben a felállásban nem lehetséges.
Ha úgy próbáljuk meg a dolgot, hogy a virtualbox-ban a hálózati kártyát NAT-ra állítjuk, akkor pedig a visszairány nem fog működni. Adja magát tehát a logikus megoldás: Két hálózati kártya kell a virtuális gépbe: az egyik a kifelé menő kapcsolatokhoz (nat) a másik pedig a vissz irányú kapcsolatokhoz (Host only). Így most tudunk kifelé is kommunikálni a virtuális gépünkről és a visszairányú forgalom is működni fog.

A másik dolog amiről írok, hogy a virtuális gépünk alól hogy kell a mobil stick-et használni.
Nekem egy szimpla T-mobileos stickem van (Huawei) Virtuális Windows alól könnyű működésre bírni: A behelyezéskor létrejön egy virtuális CD, ezt le kell másolni egy iso fájlba és ezt át kell adni a virtuális gépbe. Ha ez megvan, innen fel tudjuk installálni a drivereket és utána már simán tudjuk használni a mobil sticket a virtuális gép alól is ha azon windows fut.

Kali linuxon se túl bonyolult a dolog: Indítsuk el a sakis3g --interactive parancsot és itt értelemszerűen válasszuk ki a megfelelő dolgokat. Ezután a hálózati beállításoknál Kattintsunk az alapértelmezett mobil csatlakozásra. Ha mindent jól csináltunk fent megjelenik egy GSM jelző kis ikon ami jelszi, hogy csatlakoztunk a mobil hálózathoz. Ha nem megy minden simán, akkor jöhet a troubleshooting :)

A fentiekhez már csak egy noip klienst kell telepíteni (vagy a fő gépre vagy a virtuális gépre) és az átmeneti ip címet egy no-ip-s néven keresztül el tudjuk érni. Ez akkor hasznos, ha olyan hivatkozást használunk valahol amiről bármikor visszafelé rá akarunk csatlakozni a gépünkre (például egy meterpreter reverse https shellel :)

Így egy db mobile stickkel tudunk tesztelni kliens oldali sebezhetőségeket. A tesztelendő windowsos virtuális kliensről felmegyünk egy free vpn-re, így lesz egy valós internetes ip címünk, amiről a no-ip-s néven keresztül vissza tudunk konnektálni a saját gépünkön egy másik virtuális gépre (pl egy Kali Linuxra) ahol a kliens oldali teszteket futtatni tudjuk. Csak a megfelelő portok forwardolásáról kell gondoskodnunk.

2013. szeptember 16., hétfő

Intercepter-NG

Ezt a szoftver a PWAD MITM tesztelésére töltöttem le, de nagyon jól lehet használni egyéb belső hálózati tesztelésekre is.

Itt van egy ki ismertető videó róla a youtube-ról:


Belső hálózaton MITM támadások és switchelt hálózat sniffírozására használható.
Itt a weboldala: http://sniff.su

Android alatt is megy!

2013. szeptember 15., vasárnap

Feketelista

Mivel ezek a támadások csak nem szűnnek elhatároztam, hogy készítek egy fekete listát azokról a címekről amik támadják a gépemet. Aki kéri annak MAJD elküldöm az aktuális listát (ip címeket)
(biztos lesz egy csomó, mert ezek nem alszanak ;)

A legutóbbi támadás innen jött: lucenttel.com


A reverse dns-e érdekes :)
Az nmap ezt mondja róla:
Starting Nmap 6.40 ( http://nmap.org ) at 2013-09-15 22:07 CEST
Nmap scan report for doesnt-think-he.kicks-ass.net (65.111.172.31)
Host is up (0.15s latency).
Not shown: 992 closed ports
PORT     STATE    SERVICE     VERSION
22/tcp   open     ssh         OpenSSH 4.3 (protocol 2.0)
25/tcp   filtered smtp
80/tcp   open     http        Apache httpd 2.2.3 ((CentOS))
111/tcp  open     rpcbind     2 (RPC #100000)
443/tcp  open     ssl/http    Apache httpd 2.2.3 ((CentOS))
2000/tcp open     cisco-sccp?
3306/tcp open     mysql       MySQL (unauthorized)
6005/tcp filtered X11:5
Device type: firewall|general purpose|specialized|WAP|webcam|media device
Running (JUST GUESSING): Juniper IVE OS 7.X (88%), Check Point Linux 2.6.X|2.4.X (87%), Linux 2.6.X|2.4.X (87%), Cisco embedded (86%), ISS Linux 2.4.X (86%), Linksys embedded (86%), Logitech Linux 2.6.X (86%), Sony embedded (85%)
OS CPE: cpe:/h:juniper:mag2600 cpe:/o:linux:linux_kernel:2.6.18 cpe:/o:checkpoint:linux_kernel:2.4 cpe:/o:iss:linux_kernel:2.4 cpe:/h:linksys:wap54g cpe:/o:linux:linux_kernel:2.4.20 cpe:/h:sony:bravia_kdl-46hs720
Aggressive OS guesses: Juniper MAG2600 SSL VPN gateway (IVE OS 7.3) (88%), Check Point GAiA (Linux 2.6.18) (87%), Linux 2.6.18 (87%), Check Point firewall (Linux 2.4.21) (86%), Check Point VPN-1 firewall (Linux 2.6.18) (86%), Cisco NME-NAM-80S network analysis module (86%), Linux 2.6.16 - 2.6.28 (86%), ISS Proventia GX3002C firewall (Linux 2.4.18) (86%), Linksys WAP54G WAP (86%), Linux 2.4.20 (86%)
No exact OS matches for host (test conditions non-ideal).
A sinfp3 pedig ezt:
root@kali:~# sinfp3.pl -target 65.111.172.31 -port 80
[+] [J:0] Loaded Input:  Net::SinFP3::Input::SynScan
[+] [J:0] Loaded DB:     Net::SinFP3::DB::SinFP3
[+] [J:0] Loaded Mode:   Net::SinFP3::Mode::Active
[+] [J:0] Loaded Search: Net::SinFP3::Search::Active
[+] [J:0] Loaded Output: Net::SinFP3::Output::Simple
[+] [J:0] Starting of Input [Net::SinFP3::Input::SynScan]
[+] [J:0] Estimated running time: 0 day(s) 0 hour(s) 0 minute(s) 3 second(s) for 1 host(s)
[+] [J:1] Starting of job with Next [65.111.172.31]:80 hostname[unknown] reverse[unknown] mac[XX:XX:XX:XX:XX:XX]
[65.111.172.31  ]:80     reverse: unknown  [ 98%: Linux 2.6.x]
[65.111.172.31  ]:80     reverse: unknown  [ 92%: Linux 2.4.x]
[65.111.172.31  ]:80     reverse: unknown  [ 71%: Linux 3.2.x]
[65.111.172.31  ]:80     reverse: unknown  [ 71%: Linux 3.0.x]
[+] [J:0] Done: operation successful
Ez egy Linux lesz ami a céges Juniperes Tűzfal mögül basztatja a jóembereket... Ráadásul ha jól látom, ezen a linuxon fut a céges http és https szolgáltatás. Ez nagyon derék!

Ahonnan eddig jöttek a támadások azokra spongyát rá, de akik ezután jönnek azokat felveszem egy jó kis listába - akiken majd lehet tesztelni különböző dolgokat... :)

Ez pedig itt a vnc szerveres windows 2003-as gép ip címe : 186.74.162.75

Mivel ezek kérdezés nélkül nekiálltak támadni a gépem ezért azt kell, hogy feltételezzem, hogy nem "jóemberek" ülnek a vonal tulsó végén ezért nem is olyan bánásmódot érdemelnek amit a rendes emberek. Ezért ha ők tesztelik a gépem, akkor majd én is az övéket. Ez így fair.

(miközben ezt a bejegyzést írtam jött egy újabb látogató innen : 187.174.135.146 (Mexikó)
Starting Nmap 6.40 ( http://nmap.org ) at 2013-09-15 22:51 CEST
Nmap scan report for customer-187-174-135-146.uninet-ide.com.mx (187.174.135.146)
Host is up (0.21s latency).
Not shown: 998 filtered ports
PORT   STATE SERVICE VERSION
23/tcp open  telnet  Netscreen ScreenOS telnetd
80/tcp open  http    Virata-EmWeb 6.0.1 (Netscreen administrative web server)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: firewall
Running: Juniper embedded
OS CPE: cpe:/h:juniper:networks_ssg_20
OS details: Juniper Networks SSG 20 firewall
Service Info: Device: firewall
[187.174.135.146]:80     reverse: unknown  [ 98%: ShoreGear unknown]
[187.174.135.146]:80     reverse: unknown  [ 98%: HP-UX 9.x]
[187.174.135.146]:80     reverse: unknown  [ 92%: SuperStack unknown]
[187.174.135.146]:80     reverse: unknown  [ 92%: Passport unknown]
[187.174.135.146]:80     reverse: unknown  [ 92%: BayStack 470 unknown]
[187.174.135.146]:80     reverse: unknown  [ 92%: JetDirect unknown]
[187.174.135.146]:80     reverse: unknown  [ 92%: ProCurve unknown]
Csak a próba kedvéért rátelneteltem a 23-as portra:
 root@kali:~# telnet 187.174.135.146
Trying 187.174.135.146...
Connected to 187.174.135.146.
Escape character is '^]'.
Remote Management Console
login: admin
password:
 ### Login failed
A remote management konzol kint figyel az interneten :) Kúl!
A 80-as porton se jobb a helyzet:






Admin name.... és Password. Pffff.  Mondjuk ez nem támadta a gépet - egyelőre. Csak rájelentkezett a 80-as portra pedig marhára nincs hirdetve sehol a cím, ez egy tök PRIVÁT szerver. Mondjuk, nem a céges infrastruktúráról kéne nyomulni kéretlenül ismeretlen privát szerverekre.

Ha jönnek újabb "versenyzők", updatelem vagy csak beírom megjegyzésbe...

Éles teszt.

Néhány hete elkezdtem egy olyan projektet tesztelni amihez ki kellett nyitom a routeren a gépem felé pár portot. Mondanom sem kell, hogy már pár óra után megjelentek tapogatódzó kérések.... ez rejtély, hogy hogy tudják ilyen hamar kiszúrni a neten, ha kinyitok egy portot. Brazil, francia és egyéb címekről jöttek a támadások. Igazából egyelőre még nem támadások csak sebezhetőségi vizsgálatok.

A Dfind nevű progi volt a leggyakoribb amit használtak , a többit egyelőre nem tudtam beazonosítani.

Eddig nem igazán foglalkoztam a dologgal, mert időm se volt rá meg úgyse tudnak az adott porton bejönni, mert ott nem egy normál webszerver fut (hanem egy metasploit autopwn). Érdekes, hogy párszot kaptam egy távoli shellt a támadó gépekre :). De idő hiányában ezzel se kezdtem semmit.

Viszont ma volt egy kis időm és az egyik támadót vissza nmapoltam. Valójában kettőt, mert ma ketten jöttek. Mind ketten az OVH SAS címeiről. az egyik egy Linux volt, ott csak a 22-es port volt nyitva - így ezzel nem foglalkoztam - egyelőre - de a másik egy Windows 2003 szerver volt amin elég sok port nyitva volt. Az 5900-esre (vnc) rá is engedtem egy brute force attackot a rockyou jelszó adatbázissal (130 mega szöveg fájl) Kíváncsi vagyok, hogy meddig fog futni... :) (persze nem a saját ip címemről megy a teszt :)

A másik, hogy a port kinyitás miatt a biztonság kedvéért ráengedtem egy Nessust a win7-es gépemre és két kritikus és 36db súlyos hibát talált. Amin eléggé meglepődtem, mert azt képzeltem, hogy up-to-date a gépem. De tévedtem. Mindenesetre kijavítottam ezeket a hibákat. Érdemes időnként lefuttatni mindenkinek egy ilyen vizsgálatot a saját gépére (ha windows ha linux) mert nagyon tanulságos eredménye lehet. (2-3 napos hibákat is megtalált, mert nem volt reboot pár napig a gépen és így nem tudtak lefutni az automatikus frissítések) Nagy királyság ez a Nessus...

Win7-en nem volt egyszerű megoldani, hogy a nessus normálisan lefusson. Előszöris az Adminisztrátori accountot aktívvá kellett teni, utána beállítani neki valami jelszót, a remote registry és a wmi szolgáltatásokat elindítani és a tűzfalat kikapcsolni. Ezek hiányában nem hozta ki a hibákat.

2013. szeptember 12., csütörtök

Stunnel

A mai bejegyzésben leírom, hogy hogy lehet két gépet egy stunnelen keresztül a legegyszerűbb módon biztonságosan összekötni. Csak azért írom le, mert sokféle leírással találkkoztam a neten és egyik hosszabb és bonyolultabb volt mint a másik, pedig ezt elég egyszerűen is meg lehet oldani.

Server oldal:

Installáljuk fel a stunnel legújabb verzióját és amikor a certet generálja adjuk meg a CommonName mezőben, hogy stunnel1 vagy hogy server (a többi mezőre üssünk entert -> nincs jelentőségük)
a stunnel.pem fájlból egy szövegszerkesztővel vegyük ki a ---Begin Certificate , ---End Certificate közötti részeket és mentsük el a certs.pem fájlba. (ebben lesznek a CA certek)
Ez így néz ki kb:
-----BEGIN CERTIFICATE-----
MIIDnjCCAoagAwIBAgIJAOdb/lnGNB7s
...
PMkArdl9ItUcAPbkL6/OwF45
-----END CERTIFICATE-----

Szerkesszük át a stunnel.conf-ot:
stunnel.conf:
debug = 7
; ez azért kell, hogy lássuk a hibákat
cert = stunnel.pem
;ez a server oldali cert + key file a stunnel automatikusan megcsinálja installáláskor
verify = 3
;ez állítja az ellenőrzés erősségét. Először célszerű 0-ra állítani és ha úgy minden ok akkor feljebb lehet venni
CAfile = certs.pem
;ebben vannak a ca certek

[service]
client = no
;ez nem a kliens
accept = 3333
;a port ahol figyel a stunnelünk, erre kell távolról kapcsolódni majd a másik stunnellel.
connect = 127.0.0.1:4444
;erre a lokális portra fog kapcsolódni a stunnel.

Kliens oldal
Installáljuk fel ugyanazt a verziót ami a szerveren fut és nyomkodjuk az entert a certificate elkészítésénél. A CommonName-hez írjuk be, hogy stunnel2 vagy hogy client.
a stunnel.pem fájlból egy szövegszerkesztővel vegyük ki a ---Begin Certificate , ---End Certificate közötti részeket és mentsük el a certs.pem fájlba
A serveren lévő és ezen lévő certs.pem fileokat egyesítsük (egy szövegszerkesztővel)
Másoljuk mindkét tartalmat mindkét fájlba bele.
Szerkesszük meg a stunnel.conf fájlt.
stunnel.conf
debug = 7
; ez azért kell, hogy lássuk a hibákat
cert = stunnel.pem
;ez a server oldali cert + key file a stunnel automatikusan megcsinálja installáláskor
verify = 3
;ez állítja az ellenőrzés erősségét. Először célszerű 0-ra állítani és ha úgy minden ok akkorfeljebb lehet venni 
CAfile = certs.pem
;ebben vannak a ca certek

[service]
client =yes
;ez a kliens
accept =127.0.0.1:4444
;a port ahol figyel a stunnelünk, erre kell  kapcsolódni majd a klienssel
connect =server.gép.ip.címe:3333
;erre a távoli portra fog kapcsolódni a stunnel.

Kész! (Nem kell külön CA-t installálni és egyéb hülyeségekkel bajlódni!)

Indítsuk el a stunneleket és netcattal teszteljük le:

Server oldalon :
nc -l -p 4444

Kliens oldalon:
nc 127.0.0.1 4444

Az eredmény: A kliens oldali 127.0.0.7:4444 át van stunnelezve egy biztonságosan védett csatornán a szerver oldali 127.0.0.1:4444 portra.

kliens app -> conn 127.0.0.1:4444 -> stunnel -> távoli gép:3333 - stunnel -> server app -> 127.0.0.1:4444

Ez abban az esetben jó megoldás, ha az interneten kell rácsatlakoznunk valamilyen szolgáltatásra de mégsem szeretnénk az adott szolgáltatást elérhetővé tenni a net felől. A szerver oldali routeren csak a 3333-as portra kell engedélyezni a forgalmat a valódi 4444-re nem így azt kívülről nem lehet elérni. a 3333-as porton pedig a stunnel miatt csak érvényes certificate-el rendelkező kliens tud csatlakozni.
Brute force és egyéb támadási felületek kivédve. Csak DoS-olni tudják az alkalmazást.