Welke exploit werd er bij jou gebruikt?

[Booster]

Yo All,

ik ben op zoek naar ervaringen van (het liefst) admins van productieservers...

Is er wel eens ingebroken in een van jou productieservers, en wat werd hiervoor gebruikt? Ik hoef niet te weten waar je werkt, alleen om welk OS het ging, hoe 'ingewikkeld' de exploit was die gebruikt werd en waar men op uit was.

Ik wil een beetje weten hoe veel moeite er gemiddeld door een scriptkid gedaan wordt om in te breken... Grotere sites worden natuurlijk vaker aangevallen met een hele reeks aan exploits, maar hoe zit dit met servers met relatief onbekende sites?

Reactie via email mag ook, hoeft niet hier.

[Verwijderd]

Aantal interessante sites om op te kijken:
http://project.honeynet.org/ leer je veel van aanvalstechnieken en gebruikte exploits.

http://defaced.alldas.de/ overzicht van defaced sites. Kun je zien welk OS de site draaide. Compleet met NMAP scan.

Verder wil ik nog een opmerken dat je met een kleine onbekende site niet per definitie minder kans loopt. Vaak wordt er gewoon een ip range gescanned van servers op zoek naar een server met een bekend exploit.

[Booster]

Ik ken de sites
Maar ik kan niet zien hoe goed deze servers beveiligd waren, of dat de admins zoiets hadden van 'bij ons wordt toch niet ingebroken'.

[edit]
Stel je voor:
Je draait je dns als chroot() (patched, dus niet de standaard die makkelijker te breken is) just to be sure, maar Apache 1.3.20 niet, en proFTPd 1.2.2rc3 ook niet omdat dit een hoop gezeik met zich meebrengt waar je je nu nog even niet in kunt verdiepen.
Je kunt hierbij dan vertrouwen op Apache en proFTPd maar in het verleden waren er al exploits met root als gevolg.

Andere kant is dat je checked naar die versies en het blijkt dat er op de proftpd en apache geen exploits zijn gevonden.

Hoe ver ga je? Is het 'veilig genoeg', wordt jou server niet aangevallen door iemand met genoeg kennis van zaken? Ben je beschermd tegen scriptkids, alleen niet tegen de mensen die serieus iets kunnen cracken?

[Verwijderd]

Op zaterdag 12 januari 2002 16:43 schreef Booster het volgende:
Ik ken de sites
Maar ik kan niet zien hoe goed deze servers beveiligd waren, of dat de admins zoiets hadden van 'bij ons wordt toch niet ingebroken'.

Mwah, als ik een NMAP scan zie op alldas van een server met zo'n beetje elke denkbare poort open heb ik toch wel een vermoeden dat de admin niet echt security minded is.

Wat wil je precies doen met die ervaringen van andere trouwens? Op honeynet kun je wel zeker een goed beeld krijgen van hoe een slecht beveiligde server wordt gehacked. Weet je dus ook gelijk waar je op moet letten voor het beveiligen van jouw server. Er zijn ook zat sites te vinden met goede security informatie.

Mijn enige ervaring overigens was een Domino mail server draaiende op NT4 die als mailrelay werd gebruikt. Dat was tijdens mijn stage en dat probleem heb ik toen gefixed.

[Booster]

Ok, ik zoek ervaringen omdat ik graag wil weten door wat voor soort iemand de gemiddelde bak wordt aangevallen...

Je zegt al dat er op alldas idd servers staan met zo ongeveer iedere poort open. Maar stel dat je een server hebt waar gewoon redelijk aan security gedacht is (maar die toch ook wel iets van services moet draaien), wordt deze dan ook 'zomaar' open gebroken, of wordt hij met rust gelaten omdat hij gewoon niet intressant is?

[Verwijderd]

Als je als een goed admin al je software updates bij houdt dan is de kans al redelijk klein dat je server wordt gehacked. Tenzij er natuurlijk een 0 day exploit is waar nog geen patch voor bestaat of omdat er een configuratie/design fout in je netwerk zit. Dit heeft dus allemaal met de kwaliteiten van de admin te maken.

Over het algemeen worden servers die door een goede admin worden beheerd dus niet zomaar gehacked. Pogingen tot hacken (zeker als je portscans daar ook onder verstaat) worden altijd ondernomen. Zoals ik al eerder zei zijn veel crackers op zoek naar een bekend exploit.

Bepaalde sites lopen natuurlijk wel een verhoogd risico. Het is natuurlijk erg cool om Microsoft te hacken, een grote ISP of Oracle na zo'n uitspraak over de beveiliging van hun producten.

Denk dat de meeste crackers hacken om het hacken en niet proberen een specifieke site te hacken tenzij het bijzonder interessant is om daar binnen te komen. Maar dan nog komen alleen komen misschien de echte profs binnen (is denk ik maar paar procent van alle hackpogingen) als ze door een goede admin worden beheerd. Onkraakbaar bestaat niet, maar als je zorgt dat jouw huis beter beveiligd als dat van de buren is de kans klein.

[JMW761]

mijn ervaring is dat je vooral te maken hebt met scriptkiddies, die na een simpele (mislukte) poging een DoS op je af sturen...
die kun je vrij simpel opvangen (kay, je bent ff je bandbreedte kwijt enzo, maar that's it..geen blijvende schade)

Draai een goeie firewall, hou je services een beetje bij en check je logs regelmatig.....een server is veilig als zijn admin kennis heeft, was het gezegde toch?

[Booster]

Op zaterdag 12 januari 2002 17:14 schreef balou het volgende:
Als je als een goed admin al je software updates bij houdt dan is de kans al redelijk klein dat je server wordt gehacked. Tenzij er natuurlijk een 0 day exploit is waar nog geen patch voor bestaat of omdat er een configuratie/design fout in je netwerk zit. Dit heeft dus allemaal met de kwaliteiten van de admin te maken.

Natuurlijk, dat zeker... Maarja, wat ben ik... een Admin in wording misschien, met op dit moment een gemiddelde Linux-kennis (wel al 5 jaar ervaring ondertussen) en een tique wat security-paranoia betreft.

De andere kant is echter: die server is hard nodig, om hem nog veiliger te maken moet ik het hele systeem weer omgooien (bv, apache en ftpd chroot()'en dit zorgt zover ik weet voor een *totaal* andere systeem-opbouw, waar ik geen ervaring mee heb). De kans dat ik bij dit een foutje maak is best groot waardoor de productie-server dus niet 100% naar behoren zou werken.

Over het algemeen worden servers die door een goede admin worden beheerd dus niet zomaar gehacked. Pogingen tot hacken (zeker als je portscans daar ook onder verstaat) worden altijd ondernomen. Zoals ik al eerder zei zijn veel crackers op zoek naar een bekend exploit.

Portscans versta ik daar zeker niet onder...

Zover ik gezien heb zijn er geen exploits in proFTPd 1.2.2rc3 (dacht wel iets gevonden te hebben maar dat had niet met de server te maken maar een client die crashte) en 1.2.4. Apache 1.3.20 heb ik een PHP-Nuke exploit voor gezien maar daar kom ik overheen...

Op zaterdag 12 januari 2002 18:37 schreef JMW het volgende:
mijn ervaring is dat je vooral te maken hebt met scriptkiddies, die na een simpele (mislukte) poging een DoS op je af sturen...
die kun je vrij simpel opvangen (kay, je bent ff je bandbreedte kwijt enzo, maar that's it..geen blijvende schade)

Ok, scriptkiddies zullen een harde domper hebben aan het systeem... Tripwire, encrypted logs, op zijn minst redelijke backup en security-policies, enkele admins die toch wel security-'fan' zijn en ik ben zelf best gevoelig wat security betreft...

Draai een goeie firewall, hou je services een beetje bij en check je logs regelmatig.....een server is veilig als zijn admin kennis heeft, was het gezegde toch?

Nouja, de firewall is altijd iptables natuurlijk, maar ik neem aan dat je op goed geconfigureerd doelt

En kennis... We zijn met meer mensen die (zeker als ze samenwerken) heel wat kennis kunnen ophoesten...

[Verwijderd]

Mijn ervaring met gehackte servers:

- passwords = usernames, zo easy te cracken.
- geen shadow passwords op het system en users die dan gewoon john the ripper loslaten op je password file en zo 100en accounts cracken.
- nooit updaten van packages. Debian is in dat opzicht wel zalig, gewoon elke dag apt-get updaten en upgraden.
- al je servers zo veel mogelijk achter een firewall zetten. Zeker workstations die toch niet van buiten te benaderen moeten zijn, dat helpt al heel veel, dan kunnen ze er gewoon niet aan (als ze je firewall niet hacken natuurlijk draai daarom gewoon geen enkele daemon op de firewall, zelfs geen ssh)
- switched network aanleggen, dan kunnen ze je network al niet sniffen als ze op 1 bak root krijgen.
- gebruik NOOIT trusted relations met bv. ssh keys zonder password.
- installeer kernel patches zoals grsecurity: restricted /proc, setuid restrictions, chroot restrictions, fork-bomb protections (ja, bescherm je ook tegen de users op je eigen bak !).

Da's zowat alles wat ik momenteel kan bedenken

[Verwijderd]

Eens een DNS van me gecracked. Draaide onder user nobody, dus schade viel mee. Paar files in de /tmp dir gevonden die er niet hoorden. Heb voor de zekerheid toen bak leeggehaald en opnieuw geinstalleerd, dit keer met versie 9 van BIND.

[Mior]

Mijn server is nog nooit gehacked, wel ligt ie vaak onder vuur omdat ik een aantal, niet nader te noemen, dubieuze domein namen heb.

Maar ik weet uit ervaring dat als je gewoon bij blijft, dat je dan voor 99% van de internet bevolking unhackbaar bent.

De bakken die gehacked worden (zie alldas e.d.) lopen meestal hopeloos achter (sshd, bind).

[TumbleCow]

Ok, ziet er dus allemaal goed uit als ik het zo bekijk.

Maar het algemene advies is dus een beetje: "Ga niet je hele systeem omgooien om bijv. apache in een chroot-jail te draaien, hierbij wegen de voordelen niet op tegen de evt. nadelen. "

correct?

[Booster]

Op zondag 13 januari 2002 14:10 schreef c9melvin het volgende:
Mijn ervaring met gehackte servers:

- passwords = usernames, zo easy te cracken.
- geen shadow passwords op het system en users die dan gewoon john the ripper loslaten op je password file en zo 100en accounts cracken.

Zucht... Dat is wel echt gewoon stom, maargoed... Dat hebben wij dus niet.

- nooit updaten van packages. Debian is in dat opzicht wel zalig, gewoon elke dag apt-get updaten en upgraden.

Het nooit updaten van packages is ook deadly stupid. Je hebt een server, je wilt scalability, security en max performance, DUS update je.

- switched network aanleggen, dan kunnen ze je network al niet sniffen als ze op 1 bak root krijgen.
- gebruik NOOIT trusted relations met bv. ssh keys zonder password.

Ok, die eerste zou ik niet aan gedacht hebben, maar het is switched dus daar hoef ik geen zorgen over te maken.
ssh-key's zonder pass is ook en

- installeer kernel patches zoals grsecurity: restricted /proc, setuid restrictions, chroot restrictions, fork-bomb protections (ja, bescherm je ook tegen de users op je eigen bak !).

Die chroot restrict moet er zowiezo komen. De bak zal verder niet toegankelijk zijn via een shell, maar als ze een service crashen met als gevolg een rootshell oid, dan zul je ze ook daar nog moeten kunnen tegenhouden.

Kernel patches moeten er dus nog in komen.

Da's zowat alles wat ik momenteel kan bedenken

Bedankt voor je reactie iig Ik denk dat ik een aardig beeld begin te krijgen van het niveau.

Op zondag 13 januari 2002 14:17 schreef janjanjansen het volgende:
Eens een DNS van me gecracked. Draaide onder user nobody, dus schade viel mee. Paar files in de /tmp dir gevonden die er niet hoorden. Heb voor de zekerheid toen bak leeggehaald en opnieuw geinstalleerd, dit keer met versie 9 van BIND.

Ok, het valt me zowiezo mee met die schade. Een compromise via BIND 8 zie ik als iets 'fataals'. BIND 9 heb ik op dit moment in gedachten, maar eigenlijk veel liever djbdns.

Op zondag 13 januari 2002 14:20 schreef Phantom_ het volgende:
Maar ik weet uit ervaring dat als je gewoon bij blijft, dat je dan voor 99% van de internet bevolking unhackbaar bent.

De bakken die gehacked worden (zie alldas e.d.) lopen meestal hopeloos achter (sshd, bind).

Ok... Ik krijg de indruk dat we op dit moment redelijk veilig zitten... Bijhouden maken wij geen punt van, we moeten er alleen wel even een routine van maken

Thnx voor jullie reacties iig

[franklin]

ik had een oude linuxserver staan in het serverpark die ik al aan het uitrangeren was... werd gebruikt voor virtual hosting.

die hadden ze met behulp van de bekende ssh1 exploit weten binnen te dringen en een rootkit geinstalled. Gelukkig waren ze niet al te slim en hadden we het systeem in no time weer onder controle.

vervolgens het tempo van uitrangeren ff opgehoogd zodat ik 3 dagen na de hack de stekker definitief uit het stopcontact kon trekken!

was me allemaal niet gebeurd als ik die machine netjes had onderhouden, eigen schuld dikke bult dus!

[Verwijderd]

Op zondag 13 januari 2002 14:44 schreef Booster het volgende:
Zucht... Dat is wel echt gewoon stom, maargoed... Dat hebben wij dus niet.

Dat was ook op een DEC UNIX server bij ons op de univ Die hebben een 24/7 onderhoudscontract met DEC en doen dus zelf helemaal NIETS aan die server. Daar stonden echten nog oude dingen op, zoals o.a. geen shadow paswoords, en die is zeker al meer dan 20 keer gehacked ofzo. Ze leren het nooit...

[Verwijderd]

Op zondag 13 januari 2002 14:10 schreef c9melvin het volgende:
- switched network aanleggen, dan kunnen ze je network al niet sniffen als ze op 1 bak root krijgen.

In tegenstelling wat veel mensen denken kan er in een switched netwerk wel degelijk gesniffed worden. Kijk maar eens op http://ettercap.sourceforge.net/

[Booster]

Op zondag 13 januari 2002 15:52 schreef balou het volgende:
In tegenstelling wat veel mensen denken kan er in een switched netwerk wel degelijk gesniffed worden. Kijk maar eens op http://ettercap.sourceforge.net/

Volgensmij ligt het er ook sterk aan wat voor switch het is en hoe die ingesteld is...?

[Verwijderd]

Op zondag 13 januari 2002 16:01 schreef Booster het volgende:

[..]

Volgensmij ligt het er ook sterk aan wat voor switch het is en hoe die ingesteld is...?

Ettercap maakt gebruik van ARP poisoning van de ARP cache in de switch. Dit kun je alleen voorkomen door static ARP entrys te gebruiken. Denk alleen niet dat dat iets is wat je wil in een groot lan. Hoop werk en niet flexibel.

[Booster]

Ok dat zou kunnen... maar zelfs met sniffen komen ze bij ons niet ver...

[Verwijderd]

Dat betwijfel ik, want zoals je in de feature lijst ziet kan ettercap ook nog een aantal protocollen decrypten, waarbij ik HTTPS wel de meest opmerkelijke vind:

code:

Characters injection in an established connection :
you can inject character to server (emulating commands) or
to client (emulating replies) maintaining the connection alive !!

SSH1 support : you can sniff User and Pass, and even the
data of an SSH1 connection. ettercap is the first software
capable to sniff an SSH connection in FULL-DUPLEX

HTTPS support : you can sniff http SSL secured data... and
even if the connection is made through a PROXY

Plug-ins support : You can create your own plugin using the
ettercap's API.

Password collector for : TELNET, FTP, POP, RLOGIN, SSH1,
ICQ, SMB, MySQL, HTTP, NNTP, X11, NAPSTER, IRC, RIP, BGP,
SOCKS 5, IMAP 4, VNC, LDAP, NFS, SNMP, HALF LIFE (other
protocols coming soon...)

Packet filtering/dropping: You can set up a filter that
search for a particular string (even hex) in the TCP or UDP
payload and replace it with yours or drop the entire packet.

OS fingerprint: you can fingerprint the OS of the victim
host and even its network adapter

Kill a connection: from the connections list you can kill
the connections you want 

Passive scanning of the LAN: you can retrive infos about:
hosts in the lan, open ports, services version, type of the
host (gateway, router or simple host) and extimated
distance in hop.

[Verwijderd]

Mijn persoonlijke idee/ervaring met exploits:

Ik ben zelf nooit gecrackt (afkloppen), wil ik natuurlijk graag zo houden. De meeste "gehackte" (populair misbruik vaan de term) sites zijn vaak gecrackt door skriptkiddies, deze zullen bekende exploits met publicly available exploit code gebruiken. Software updaten is in dit geval genoeg (feit is dat niet iedereen dit doet). Een firewall wil ook wel handig zijn.

Feit is dat je zelfs met uptodate code niet veilig bent - alles met een uitgaande weg heeft een ingaande weg, elke bak die op internet staat aangesloten heeft de theoretische mogelijkheid om gecrackt te worden, hetzij via onbekende exploits, hetzij via een volledig nieuwe manier van inbreken. Dit soort dingen zal de gemiddelde skriptkiddie niet kunnen en dus hoef je er op je huiscomputer gewoon niet bang voor te zijn. Als een echte cracker (n.b. een hacker is iets anders ) een nieuwe manier vindt om in te breken zal hij dat aan de developers melden of hij zal dat op een grote site of bedrijf uithalen (bedrijfsspionage/showoff), niet op jouw huisservertje.

Oftewel, voor jouw huisservertje hoef je niet bang te zijn als je je software uptodate houdt. En een hacker is een persoon met bijdrage aan de community, vaak in de vorm van opensource software programmeren of iets dergelijks, verwar hacker en cracker s.v.p. niet .

[Booster]

Op zondag 13 januari 2002 16:26 schreef balou het volgende:
Dat betwijfel ik, want zoals je in de feature lijst ziet kan ettercap ook nog een aantal protocollen decrypten, waarbij ik HTTPS wel de meest opmerkelijke vind:

code:

HTTPS support : you can sniff http SSL secured data... and
even if the connection is made through a PROXY

Nee, er staat dat het te sniffen is, niet decrypten. Dat is logisch. Maar wat willen ze er verder mee? Op 1 pakketje kunnen ze een Dnet project zetten voor een jaartje. En dan hebben ze dus nog niks.

Op zondag 13 januari 2002 17:14 schreef beelzebubu het volgende:
Mijn persoonlijke idee/ervaring met exploits:

[knip]

Feit is dat je zelfs met uptodate code niet veilig bent - alles met een uitgaande weg heeft een ingaande weg, elke bak die op internet staat aangesloten heeft de theoretische mogelijkheid om gecrackt te worden, hetzij via onbekende exploits, hetzij via een volledig nieuwe manier van inbreken. Dit soort dingen zal de gemiddelde skriptkiddie niet kunnen en dus hoef je er op je huiscomputer gewoon niet bang voor te zijn.

Nee prima... Het gaat dan ook niet over een thuiscomputertje

Maar ik ben niet iemand die een PC alleen laat met een of meer oude packages... Het gaat niet om het maken van een 100% secure systeem aangezien die niet bestaan, maar gewoon over het limiteren van 'de kans dat...'.

Als een echte cracker (n.b. een hacker is iets anders ) een nieuwe manier vindt om in te breken zal hij dat aan de developers melden of hij zal dat op een grote site of bedrijf uithalen (bedrijfsspionage/showoff), niet op jouw huisservertje.

Ok, maar zelfs dan nog zijn er admins die niet reageren. (bij meldingen van mogelijke holes/leaks) maar ook hier geld weer dat ik wel redelijk paranoia ben en dus zal ik proberen het gat dan samen met de cracker te dichten.

[knip]
En een hacker is een persoon met bijdrage aan de community, vaak in de vorm van opensource software programmeren of iets dergelijks, verwar hacker en cracker s.v.p. niet .

De meningen over wat een hacker/cracker is zijn verdeeld, ik denk niet dat het vastgelegt is en heb er een andere visie op dan jij. Maar ik begrijp prima wat je bedoeld.

[deadinspace]

Op zondag 13 januari 2002 18:19 schreef Booster het volgende:
De meningen over wat een hacker/cracker is zijn verdeeld, ik denk niet dat het vastgelegt is en heb er een andere visie op dan jij. Maar ik begrijp prima wat je bedoeld.

De Hacker HOWTO en de welbekende Jargon File zijn er toch vrij duidelijk over.

[odysseus]

Op zondag 13 januari 2002 19:02 schreef deadinspace het volgende:

[..]

De Hacker HOWTO en de welbekende Jargon File zijn er toch vrij duidelijk over.

Alhoewel ik het volledig met je eens ben, denk ik toch dat het noemen van twee bronnen die door een enkele persoon geschreven zijn niet als bewijs kan gelden, zeker als die ene persoon ESR is .

[Verwijderd]

Ik heb een redelijk populaire defacement mirror gedraaid (haxordot, staat nog gelinked op attrition.org als 't goed is ) maar de meesten zijn echt van die kiddie attacks, wu_ftpd.c enzo, msadc.pl, e.d. Ben zelf nog nooit gehacked, dus kan je niks over m'n persoonlijke ervaringen vertellen.

[deadinspace]

Op zondag 13 januari 2002 20:14 schreef odysseus het volgende:

[..]

Alhoewel ik het volledig met je eens ben, denk ik toch dat het noemen van twee bronnen die door een enkele persoon geschreven zijn niet als bewijs kan gelden, zeker als die ene persoon ESR is .

Mjah, ok, maar de Jargon file is toch wel widely accepted zeg maar...

[Booster]

Op zondag 13 januari 2002 20:22 schreef surreal het volgende:
Ik heb een redelijk populaire defacement mirror gedraaid (haxordot, staat nog gelinked op attrition.org als 't goed is ) maar de meesten zijn echt van die kiddie attacks, wu_ftpd.c enzo, msadc.pl, e.d. Ben zelf nog nooit gehacked, dus kan je niks over m'n persoonlijke ervaringen vertellen.

Ok, het motto is ondertussen een beetje 'A update a day, keeps the scriptkids away'.

Verder wil ik niet ingaan op wat nou een hacker en een cracker IS, ik heb het alleen over mijn eigen definitie en zover ik lees is die niet zo heel anders dan die in de jargon file.
En ja, dat in de jargon file is ook alleen maar hoe een aantal mensen erover dachten. Mijn visie erop is 'self-created'. Als je dat intressant vind mag je me daarover best mailen

[TumbleCow]

Op zondag 13 januari 2002 15:52 schreef balou het volgende:

[..]

In tegenstelling wat veel mensen denken kan er in een switched netwerk wel degelijk gesniffed worden. Kijk maar eens op http://ettercap.sourceforge.net/

De betreffende comp gaat direct op een router, dus als het goed is hoeven we ons over sniffen niet zo druk te maken..
(ok, pakketjes op het inet worden TOCH wel gesniffed, maar daar doe je nix tegen)

[Verwijderd]

Op zondag 13 januari 2002 21:59 schreef Booster het volgende:

[..]

Ok, het motto is ondertussen een beetje 'A update a day, keeps the scriptkids away'.

Verder wil ik niet ingaan op wat nou een hacker en een cracker IS, ik heb het alleen over mijn eigen definitie en zover ik lees is die niet zo heel anders dan die in de jargon file.
En ja, dat in de jargon file is ook alleen maar hoe een aantal mensen erover dachten. Mijn visie erop is 'self-created'. Als je dat intressant vind mag je me daarover best mailen

Hacker vs. cracker is inderdaad een beetje eindeloze discussie. Net zoals distributie battles bij linux.

[Booster]

Op zondag 13 januari 2002 22:05 schreef balou het volgende:
Hacker vs. cracker is inderdaad een beetje eindeloze discussie. Net zoals distributie battles bij linux.

Ja ok, van mij mag iedereen geloven wat hij wil dus ik stoor me niet aan andere visies

Maar het fijn om te weten dat je met goeie policies en een beetje opletten al flink wat buiten de deur kunt houden... Je moet er even proficient in worden...

edit:
en op dit moment lukt het even niet, dus ik kap nou met het configgen van die server... ik ben te moe ofzo

[jep]

Ik beheer nu een jaar productie servers van grote nederlandse websites. Ook een server met 120 locale users en bij dat alles geen enkele hack/crack. Dat is linux. Heb wel bij een NT4 bak die niet gebruikt werd een tag gehad. Lui van FXP boards die gingen uploaden omdat anonymous ftp een beetje erg open stond.

Niet door mij gedaan, maar dat ter zijde

Eigenlijk is dit bericht dus niet nuttig

[Mark]

In mijn hele tijd dat ik servers beheer die aan internet hangen (jaartje of 6-7) ben ik 1 keer geroot d.m.v. een security hole in wu-ftpd.
Als ik het me goed kan herineren was dit versie 2.5.0. Pas nadat ik geroot was kwam de patch hiervoor uit, dus daar had ik niks meer aan.
Toch geef ik mezelf wel de schuld daarvan, omdat ik altijd zo pleit om daemons met een slechte historie niet te draaien op productiemachines.
Waarom ik op dat moment nog wu-ftpd draaide op die doos snap ik nog steeds niet, op alle andere machines stond proftpd of ncftpd.

[sebas]

Op zondag 13 januari 2002 18:19 schreef Booster het volgende:

[..]

Nee, er staat dat het te sniffen is, niet decrypten. Dat is logisch. Maar wat willen ze er verder mee? Op 1 pakketje kunnen ze een Dnet project zetten voor een jaartje. En dan hebben ze dus nog niks.
[..]

Dan onderschat je denk ik ettercap een beetje. Het is zonder meer mogelijk om met ettercap passwords te verzamelen, ook passwords die via het *oh zo veilige* SSH gestuurd worden.

Ik heb het zelf gezien. Ettercap maakt gebruik van het man-in-the-middle model, er wordt, mits op het goede moment gesniffed, dus ook een key opgevangen waarmee je on-the-fly, plain and unencrypted zowat alles mee kunt lezen wat er via de verbinding gezegd wordt, en er kunnen packets injected worden. Feest voor elke admin dus. Tot nu toe werkt ettercap niet met ssh2, maar dat is denk ik "just a matter of time".
Voor de rest zal elke admin de specs van ettercap vrij eng vinden, maar het is belangrijk om je ervan bewust te zijn wat er op dit moment met sniffing allemaal mogelijk is.

[Booster]

Op maandag 14 januari 2002 02:41 schreef Sebas het volgende:
Dan onderschat je denk ik ettercap een beetje. Het is zonder meer mogelijk om met ettercap passwords te verzamelen, ook passwords die via het *oh zo veilige* SSH gestuurd worden.

SSH1 wist ik. Daarom is er SSH2

maar die heeft een totaal andere opbouw, en dat van SSH1 werkt volgensmij alleen als een admin zomaar accepteerd dat zijn key veranderd is (plotseling).

Ik heb het zelf gezien. Ettercap maakt gebruik van het man-in-the-middle model, er wordt, mits op het goede moment gesniffed, dus ook een key opgevangen waarmee je on-the-fly, plain and unencrypted zowat alles mee kunt lezen wat er via de verbinding gezegd wordt, en er kunnen packets injected worden. Feest voor elke admin dus.

Het staat iig niet in de feature-list dat hij kan decrypten, alleen dat hij encrypted-traffic zoals kan sniffen maar dat is zowiezo een eitje.

Tot nu toe werkt ettercap niet met ssh2, maar dat is denk ik "just a matter of time".
Voor de rest zal elke admin de specs van ettercap vrij eng vinden, maar het is belangrijk om je ervan bewust te zijn wat er op dit moment met sniffing allemaal mogelijk is.

Ok, maar jij beweert dus nu dat alle encryptieprotocollen die via het internet gebruikt worden nu met ease te decrypten zijn, dat vind ik op zijn minst een apart statement. Dus als je meer info hebt (in dit geval bewijzen voor mij) dan graag.

Zeggen dat je het gezien hebt is mij iets te vaag.

[TumbleCow]

Op maandag 14 januari 2002 02:41 schreef Sebas het volgende:

[..]

Dan onderschat je denk ik ettercap een beetje. Het is zonder meer mogelijk om met ettercap passwords te verzamelen, ook passwords die via het *oh zo veilige* SSH gestuurd worden.

<..>

Tot nu toe werkt ettercap niet met ssh2, maar dat is denk ik "just a matter of time".

Achteraf gezien zitten er gewoon grove fouten in ssh1, ssh2 is zo ontworpen dat het inprinciepe onmogelijk is om te sniffen.. (tenzij daarin ook weer fouten ontdekt worden, en dan is het tijd voor nieuwe ssh-versie. )

De enigste manier om ssh2 goed te sniffen op dit moment is:

- Bij het uitwisselen van de keys, een valse key ertussen gooien, dit is te voorkomen door goed op de fingerprints te letten. Als de keys eemaal uitgewisseld zijn is het lastig nog iets te sniffen.

- Er zijn methodes die beweren dat je de toetsaanslagen kan aflezen aan de tijd die er tussen zit. (en dus aan de tijd die tussen de verschillende tcp/ip-pakketjes zit) Deze methode heb ik nog nooit in werking gezien en ik vind em dan ook een bitje twijfelachtig.

edit: Na het lezen van de readme van ettercap: De 1e methode is de methode die voor SSH1 gebruikt, for some reason kan dat niet met ssh2? (nee, ik snap ook niet pcies waarom niet )

maar zelfs bij ssh1-sniffinh moeten de hosts nog NOOIT contact gehad hebben, en moeten de sysadmins erg slecht op hun fingerprints letten.

[Verwijderd]

Op zondag 13 januari 2002 22:05 schreef wHiTeRaZoR het volgende:

[..]

De betreffende comp gaat direct op een router, dus als het goed is hoeven we ons over sniffen niet zo druk te maken..
(ok, pakketjes op het inet worden TOCH wel gesniffed, maar daar doe je nix tegen)

Zolang je passwords encrypted verstuurt hoef je niet echt bang te zijn voor sniffers (ssh (okee, SSH2) ipv telnet, HTTPS ipv HTTP (voor je sourceforge account bijvoorbeeld), scp/sftp ipv ftp (als het niet anonymous FTP is), ...)

[Verwijderd]

Uit ervaring kan ik zeggen dat het ger00t enorm meevalt ten opzichte van de scans. Ik heb hier een netwerkje met meer als 100 server met allerlei besturingssystemen en er is er in het laatste jaar mischien 4 keer 1 gehackt waarvan ik weet. Waarvan 1 server door n00b-admins onderhouden wordt en de overige 3 (=schatting) van local-users bij een shell provider.

Dus wanneer je niet je hele inetd.conf vol hebt staan met rommel en netjes je telnet dicht hebt staan, ssh geupgraded, een degelijk ftp programma (ik zweer bij pureFTPD), de laatste postfix en verder apache webserver dan zit je redelijk veilig voor remote attacks.

En altijd leuk zijn de kernel patches like openWall of grsecurity, al is het voor het tweak gevoel wat je krijgt door de alle extra opties

[Verwijderd]

Op maandag 14 januari 2002 10:06 schreef beelzebubu het volgende:

[..]

Zolang je passwords encrypted verstuurt hoef je niet echt bang te zijn voor sniffers (ssh (okee, SSH2) ipv telnet, HTTPS ipv HTTP (voor je sourceforge account bijvoorbeeld), scp/sftp ipv ftp (als het niet anonymous FTP is), ...)

Hoeveel mensen halen hun POP3 email op via een SSL verbinding?

[TumbleCow]

Op maandag 14 januari 2002 10:14 schreef sproggle het volgende:

[..]

Hoeveel mensen halen hun POP3 email op via een SSL verbinding?

idd. en: Hoeveel isp's hebben SUPPORT voor ssl mail?

[Verwijderd]

Op maandag 14 januari 2002 10:21 schreef wHiTeRaZoR het volgende:

[..]

idd. en: Hoeveel isp's hebben SUPPORT voor ssl mail?

Ik laat men mail forwarden naar mijn eigen server en op die server heb ik dan POP3s en IMAPs geinstalleerd zodat ik thuis 'veilig' mail kan afhalen Maar niet iedereen heeft die luxe vrees ik...

edit:

Die ettercap is dus echt wel een very nice ding !

[Verwijderd]

Op maandag 14 januari 2002 10:14 schreef sproggle het volgende:

[..]

Hoeveel mensen halen hun POP3 email op via een SSL verbinding?

Hmm, good point ... Ik heb een privé mailserver op het interne netwerk hier en heb daar dus geen last van, maar zoals de persoon boven mij al zegt, niet iedereen heeft die luxe...

ISPs van Nederland, verenigt u... SSL for everyone! Gelukkig heeft demon een apart pop3 wachtwoord voor al haar gebruikers.

[Booster]

Die SSL voor pop3 wil ik er graag op, maar dat moet via een ssh-pipe geloof ik? Ik heb het niet geheel goed gelezen maar ik bestempelde het toen als 'een omweg'

Verder lijkt het sniffen al met al toch wat lastiger dan gesuggereerd wordt... Ik bedoel... Telebankieren e.d. werkt toch ook op HTTPS?
Als dat door banken e.d. gebruikt wordt is het denk ik een stuk moeilijker te kraken dan alleen sniffen.

[Verwijderd]

Maar als je op je eigen server een mail server draai is het dan ook belangrijk dat je ssl gebruikt. Ik heb altijd geleerd dat (vooral in kleinere netwerken) het spul achter de firewall als veilig kan worden beschouwd.

[Booster]

Op maandag 14 januari 2002 20:05 schreef eenprobleempje het volgende:
Maar als je op je eigen server een mail server draai is het dan ook belangrijk dat je ssl gebruikt. Ik heb altijd geleerd dat (vooral in kleinere netwerken) het spul achter de firewall als veilig kan worden beschouwd.

Een beetje veilig naar buiten, maar wat over werknemers en het compleet jatten van PC's?

Als je echt iets veilig wilt hebben moet ALLES restricted zijn... zo min mogelijk ruimte geven aan zo weinig mogelijk mensen.

[Verwijderd]

Op maandag 14 januari 2002 18:14 schreef Booster het volgende:
Die SSL voor pop3 wil ik er graag op, maar dat moet via een ssh-pipe geloof ik? Ik heb het niet geheel goed gelezen maar ik bestempelde het toen als 'een omweg'

Het makkelijkste doe je dat met stunnel. Dat is een ssl wrapper. En die kun je voor alle tcp-protocollen inzetten.

Verder lijkt het sniffen al met al toch wat lastiger dan gesuggereerd wordt... Ik bedoel... Telebankieren e.d. werkt toch ook op HTTPS?
Als dat door banken e.d. gebruikt wordt is het denk ik een stuk moeilijker te kraken dan alleen sniffen.

Klopt. Kom je precies weer op het punt van ettercap en ssh. Alleen wordt er door hele oude browsers nog WEL gebruik gemaakt van ssl v2 en hele kleine key's. (40 en 56 bit )

[Booster]

Op maandag 14 januari 2002 20:31 schreef Zon4jou het volgende:
Het makkelijkste doe je dat met stunnel. Dat is een ssl wrapper. En die kun je voor alle tcp-protocollen inzetten.

Uh ja, tunnelling dus... Haalde het even door de war met een pipe.

Klopt. Kom je precies weer op het punt van ettercap en ssh. Alleen wordt er door hele oude browsers nog WEL gebruik gemaakt van ssl v2 en hele kleine key's. (40 en 56 bit )

Je bedoeld dus te zeggen dat het wel ietsje lastiger is dan 'ettercap aan, sniffen maar' ?

[Verwijderd]

Wat betreft SSL support voor POP3 bij providers, misschien willen al die veiligheids instanties niet dat zoiets plaats vind ?
Wordt voor hun dan weer moeilijker om mailtjes mee te lezen/wachtwoorden sniffen.

En als dat het niet is, dan zullen die admins bij de meeste providers daar of geen tijd voor krijgen of gewoon die tijd niet hebben om zoiets te installeren...

En dat terwijl het redelijk eenvoudig is en een heleboel ellende scheelt.

[TumbleCow]

Op dinsdag 15 januari 2002 15:13 schreef Minotaur het volgende:
Wat betreft SSL support voor POP3 bij providers, misschien willen al die veiligheids instanties niet dat zoiets plaats vind ?
Wordt voor hun dan weer moeilijker om mailtjes mee te lezen/wachtwoorden sniffen.

En als dat het niet is, dan zullen die admins bij de meeste providers daar of geen tijd voor krijgen of gewoon die tijd niet hebben om zoiets te installeren...

En dat terwijl het redelijk eenvoudig is en een heleboel ellende scheelt.

Veiligheids instanties.. mwaa, zou kunnen. Maar dan kunnen ze net zo goed gewoon een backdoor op de mailserver zelf krijgen..

Over de tijd zal ook wel meevallen, het kost dermate veel tijd om zoiets op te zetten dat de tijd die nodig is voor de implementatie van mail-over-ssl daarbij in het niet valt.

Meestal is het gewoon het gebrek aan kennis. 'het staat niet in de documentation dus het zal wel niet nodig zijn', of een vals gevoel van veiligheid: Die mensen zitten toch op ons switched netwerk, dus waar kan het nou gesniffed worden ?

Terwijl ik eenvoudig het tegendeel kan bewijzen..

[Verwijderd]

Op dinsdag 15 januari 2002 16:35 schreef wHiTeRaZoR het volgende:

[..]

Veiligheids instanties.. mwaa, zou kunnen. Maar dan kunnen ze net zo goed gewoon een backdoor op de mailserver zelf krijgen..

Over de tijd zal ook wel meevallen, het kost dermate veel tijd om zoiets op te zetten dat de tijd die nodig is voor de implementatie van mail-over-ssl daarbij in het niet valt.

Meestal is het gewoon het gebrek aan kennis. 'het staat niet in de documentation dus het zal wel niet nodig zijn', of een vals gevoel van veiligheid: Die mensen zitten toch op ons switched netwerk, dus waar kan het nou gesniffed worden ?

Terwijl ik eenvoudig het tegendeel kan bewijzen..

Ik kan zometeen wel een paar redenen bedenken waarom ze het niet willen doen:

1. De meeste ISPs runnen een commercieel pakket voor hun mailserver, en een SSL kit daarvoor kost ze hopen geld. En mail werkt ook zonder dat extra, dus waarom zouden ze het kopen ?

2. CPU time. Al je daemons, gaande van www, pop, news, smtp, allemaal een SSL optie gaat geven, gaat dat een stuk meer van de cpu vragen. Op een druk belast systeem kan dat een grote rol spelen en doen ze het daarom niet.

Ik heb thuis eens wat zitten experimenteren met safeftp, die de control EN data channel van een FTP sessie encrypt, en dat ding eet dus CPU cycles Maar het is dan wel een stuk safer. 't is maar wat je wil.

[sebas]

Op maandag 14 januari 2002 10:06 schreef beelzebubu het volgende:

[..]

Zolang je passwords encrypted verstuurt hoef je niet echt bang te zijn voor sniffers (ssh (okee, SSH2) ipv telnet, HTTPS ipv HTTP (voor je sourceforge account bijvoorbeeld), scp/sftp ipv ftp (als het niet anonymous FTP is), ...)

dan heb je blijkbaar deze thread niet gelezen.

Hier staat zo'n beetje in elke tweede post hoe veilig encrypted verbindingen al dan niet zijn.

[sebas]

Op maandag 14 januari 2002 09:39 schreef Booster het volgende:

[..]

SSH1 wist ik. Daarom is er SSH2

maar die heeft een totaal andere opbouw, en dat van SSH1 werkt volgensmij alleen als een admin zomaar accepteerd dat zijn key veranderd is (plotseling).
[..]

Het staat iig niet in de feature-list dat hij kan decrypten, alleen dat hij encrypted-traffic zoals kan sniffen maar dat is zowiezo een eitje.
[..]

Ok, maar jij beweert dus nu dat alle encryptieprotocollen die via het internet gebruikt worden nu met ease te decrypten zijn, dat vind ik op zijn minst een apart statement. Dus als je meer info hebt (in dit geval bewijzen voor mij) dan graag.

Zeggen dat je het gezien hebt is mij iets te vaag.

- Een key kan zelfs al veranderen als je de sshd_conf aanpast.

- ik had het niet over decrypten, maar na opvangen van de key meelezen van de gesniffde informatie, unencrypted. Decrypten zou erg moeilijk zijn zonder key.

- Ik beweer niet dat alle encryptieprotocollen met ease te decrypten zijn, maar dat met de komst van software zoals ettercap het niet meer genoeg is om te denken "Ik gebruik SSL dus het is veilig, ik gebruik SSH dus het is veilig, hetzelfde geldt voor sftp, https ..."

Ook als je ettercap hebt geinstalleerd, (en je hebt voldoende bandbreedte om connections te hijacken) is het nog niet makkelijk om achter passwords te komen.

Bovendien denk ik dat een hoop admins als ze echt op een server in moeten loggen er niet lang bij stil staan dat ze nog even de nieuwe ssh key moeten accepteren.

[Booster]

Op woensdag 16 januari 2002 13:21 schreef Sebas het volgende:
- Een key kan zelfs al veranderen als je de sshd_conf aanpast.

En met een normale policy is elke admin hier van op de hoogte en verder niemand. En zelfs dan is SSH2 niet makkelijk mee te lezen, het is niet voor niets speciaal ontworpen om niet gesniffed te kunnen worden.
(iig niet zoals bij SSH1)

Ik neem aan dat er voldoende mensen naar de source van SSH2 gekeken hebben om te verifieren over het inderdaad echt veilig is of niet.

- ik had het niet over decrypten, maar na opvangen van de key meelezen van de gesniffde informatie, unencrypted. Decrypten zou erg moeilijk zijn zonder key.

Ja, maar indien je encrypte zooi, unencrypted mee wilt kijken, zul je het dus eerst moeten decrypten lijkt mij

- Ik beweer niet dat alle encryptieprotocollen met ease te decrypten zijn, maar dat met de komst van software zoals ettercap het niet meer genoeg is om te denken "Ik gebruik SSL dus het is veilig, ik gebruik SSH dus het is veilig, hetzelfde geldt voor sftp, https ..."

Natuurlijk niet, maar veel veiliger is het niet te krijgen, totdat er iemand wat veiligers ontwikkeld.
HTTPS en SSL zijn toch alweer redelijk oud kwa ontwerp dacht ik.

Ook als je ettercap hebt geinstalleerd, (en je hebt voldoende bandbreedte om connections te hijacken) is het nog niet makkelijk om achter passwords te komen.

Uiteraard, dat heb ik ook vernomen van enkele mensen.

Bovendien denk ik dat een hoop admins als ze echt op een server in moeten loggen er niet lang bij stil staan dat ze nog even de nieuwe ssh key moeten accepteren.

Dat ligt eraan, mijn SSH-key veranderd werkelijk nooit, de enige keer dat ik die heb moeten accepten is vlak na de installatie.

edit:
verkeerd stuk weggehaald

[Verwijderd]

Zelf maak ik wel eens gebruik van ettercap, dus weet wat mensen er mee kunnen doen, SSH1 decodering, password sniffers, man-in-the-middle attack, en dat soort dingen die niet door een firewall worden herkent.
een zeer gemeen tooltje dus

[Verwijderd]

Niks is secure. Deal with it.

Bij mij hoofdzakelijk Win32 worms (doh) en portscans. Een portscan geeft nogal een leuke output