---

Hei.

nmap mot en box jeg drifter,

me @ <host>$ sudo nmap -sS -O -v -oN ~./nmap_tmp -S <from_ip>
<to_ip>
Starting nmap V. 2.53 by fyodor @insecure.org ( www.insecure.org/nmap/
)
WARNING: If -S is being used to fake your source address, you may
also have to use -e <iface> and -P0 . If you are using it to specify
your real source address, you can ignore this warning.
Host (<to_ip>) appears to be up ... good.
Initiating SYN half-open stealth scan against (<to_ip>)
Adding TCP port 110 (state open).
Adding TCP port 22 (state open).
Adding TCP port 21 (state open).
Adding TCP port 80 (state open).
Adding TCP port 25 (state open).
The SYN scan took 154 seconds to scan 1523 ports.

<snip>

Interesting ports on (217.118.32.217):
(The 1016 ports scanned but not shown below are in state: filtered)
Port State Service
20/tcp closed ftp-data
21/tcp open ftp
22/tcp open ssh
25/tcp open smtp
80/tcp open http
110/tcp open pop-3
113/tcp closed auth

<snip> Alle andre porter opp til 65301 var stengt.


TCP Sequence Prediction: Class=truly random
Difficulty=9999999 (Good luck!)

No OS matches for host (If you know what OS is running on it, see
http://www.insecure.org/cgi-bin/nmap-submit.cgi).
TCP/IP fingerprint:
TSeq(Class=TR)
T1(Resp=Y%DF=Y%W=403D%ACK=S++%Flags=AS%Ops=MNWNNT)
T2(Resp=N)
T3(Resp=Y%DF=Y%W=403D%ACK=S++%Flags=AS%Ops=MNWNNT)
T4(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)
PU(Resp=Y%DF=N%TOS=C0%IPLEN=164%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)


Nmap run completed -- 1 IP address (1 host up) scanned in 161 seconds

Burde vaere fornoeyd her..? :}
--
"COBOL programmers understand why women hate periods..."

---

Shoes wrote:

> Burde vaere fornoeyd her..? :}

Hvilket OS kører du da, og hvordan har du tweaket TCP/IP?

--
Hroi Sigurdsson hroi@netgroup.dk
Netgroup Datacenter http://www.ngdc.dk

---

Shoes wrote:

> Burde vaere fornoeyd her..? :}


Hvad med en banner scanning, dvs. hvordan ser headerne ud for de enkelte
porte?

Hvad siger mailserveren til at modtage en mail til en brugere der ikke
eksistere.

Hvordan ser fejlmeddelserne ud fra webserveren, og de andre services?

Hvad med UDP?

Svarer den på andre IP protokoller?

---

Shoes <no-shoes@pobox.dk> wrote:
> nmap mot en box jeg drifter,
[..]
>
> Burde vaere fornoeyd her..? :}

Jeg forstaar ikke dit indlaeg. Skal vi gaette hvilket OS du koerer?

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.area51.dk/

---

On Fri, 28 Dec 2001 18:53:18 +0100, Alex Holst <a@area51.dk> wrote:

>Shoes <no-shoes@pobox.dk> wrote:
>> nmap mot en box jeg drifter,
>[..]
>>
>> Burde vaere fornoeyd her..? :}
>
>Jeg forstaar ikke dit indlaeg.

Det gjoer kanskje ikke jeg heller naar jeg tenker meg om.

>Skal vi gaette hvilket OS du koerer?

Neida, men synes det var ok at systemet viser saapass lite
av hva der er at nmap og venner ikke gjetter hva der er som kjoerer.

Tester mot andre boxer har vist exempelvis "Linux kerne ditt og datt".
--
My reality check just bounced...

---

Shoes <no-shoes@pobox.dk> wrote:
> On Fri, 28 Dec 2001 18:53:18 +0100, Alex Holst <a@area51.dk> wrote:
>>Skal vi gaette hvilket OS du koerer?
>
> Neida, men synes det var ok at systemet viser saapass lite
> av hva der er at nmap og venner ikke gjetter hva der er som kjoerer.
>
> Tester mot andre boxer har vist exempelvis "Linux kerne ditt og datt".

Det er ikke vigtigt om folk kan regne ud hvilket OS du koerer eller ej.

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.area51.dk/

---

Alex Holst wrote

>>Tester mot andre boxer har vist exempelvis "Linux kerne ditt og datt".

> Det er ikke vigtigt om folk kan regne ud hvilket OS du koerer eller ej.


Hvorfor ikke?

Jeg mener da det er sværet at angribe et system man ikke kan genkende,
eller som lyver omkring hvilket system det er.

Derimod er det næsten trivielt, hvis man kan genkender systemet, ja
faktisk kan man kode en robot der genkender systemer og automatisk
inficere disse med exploits fra en database. Hermed kan man scanne mange
maskiner, og finde dem med exploits, hurtigt.

Fx hvis en apache server, udgav sig som en IIS4.0 server, med headers,
fejlmeddelser, og .asp-scripts, herefter kan man så oprette regulærer
udtryk til logfilen der fangede almidelig angreb på en IIS4.0 server.
Det er specielt sjovt hvis et firma der lever af auditeringer, ej kan se
at det er en apache der i virkeligheden kører.

---

Christian E. Lysel wrote:

>>>Tester mot andre boxer har vist exempelvis "Linux kerne ditt og datt".

>> Det er ikke vigtigt om folk kan regne ud hvilket OS du koerer eller ej.

>Hvorfor ikke?

Det er ikke systemer, men services "man" angriber. Et system der ikke
kører nogen services, kan ikke brydes ind i.

>Fx hvis en apache server, udgav sig som en IIS4.0 server <snip>

Ja, men det er jo også en service.

--
http://chran.dyndns.dk - Nu med nedbrud!

---

Christian Andersen wrote:

> Det er ikke systemer, men services "man" angriber. Et system der ikke
> kører nogen services, kan ikke brydes ind i.

Men systemet siger også noget om hvilke services der er pr. default.

Endvidere hvorfor kan man ikke bryde ind i et system uden services, det
er jo også programkode med evt. fejl?

---

Christian E. Lysel <chlyshoswmdatapunktumcom@example.net> wrote:
> Alex Holst wrote
>> Det er ikke vigtigt om folk kan regne ud hvilket OS du koerer eller ej.
>
> Hvorfor ikke?
>
> Jeg mener da det er sværet at angribe et system man ikke kan genkende,
> eller som lyver omkring hvilket system det er.

Jeg tillader mig at gaa ud fra, systemet ikke koerer services med kendte
sikkerhedsfejl. Security through obscurity i meget smaa maengder er
acceptabelt saalaenge det ikke er den primaere form for beskyttelse. Jeg
synes nu mest det er fjollet.

Hvis du virkeligt moeder en angriber som kan se at du koerer OpenSSH 3.0.2,
og han efterfoelgende saetter sig ned og bruger 4 uger paa at finde et
sikkerhedshul i koden og udvikle et exploit er der ikke meget du kan goere
for at stoppe ham. Det vil vaere op til opsaetningen af systemet og
overvaagningen af ditto at opdage ham.

> Fx hvis en apache server, udgav sig som en IIS4.0 server, med headers,
> fejlmeddelser, og .asp-scripts, herefter kan man så oprette regulærer
> udtryk til logfilen der fangede almidelig angreb på en IIS4.0 server.

Hvis en af mine ansatte sad og satte Apache op til at ligne en anden httpd
for at beskytte mod sikkerhedsproblemer ville jeg fyre ham oejeblikkeligt
pga. komplet misforstaaelse af problemet OG loesningen. Jeg haaber dog ikke
saadan et menneske overlever interviewet.

> Det er specielt sjovt hvis et firma der lever af auditeringer, ej kan se
> at det er en apache der i virkeligheden kører.

Det kan jeg slet ikke se det underholdende i. Script kiddies har langt mere
tid til at smide exploits efter en server end sikkerhedspersonale har til at
bekraefte overholdelse af politikken.

Jeg har moedt systemer som tog lang tid at portscanne pga. firewall regler
og andet som ejeren af maskinen fandt smart. Det eneste man kan skrive i
rapporten er, at man ikke fandt specifikke problemer ved den paagaeldende
maskine men at man ellers ikke kan udtale sig om hvor godt systemet kan
modstaa et angreb da man ikke aner hvordan det er sat op.

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.area51.dk/

---

Hej Alex Holst <a@area51.dk>

>Jeg har moedt systemer som tog lang tid at portscanne pga. firewall regler
>og andet som ejeren af maskinen fandt smart. Det eneste man kan skrive i
>rapporten er, at man ikke fandt specifikke problemer ved den paagaeldende
>maskine men at man ellers ikke kan udtale sig om hvor godt systemet kan
>modstaa et angreb da man ikke aner hvordan det er sat op.

Er det ikke en ret essentiel del i et professionelt sikkerhedscheck at
afgøre om man med eller uden kendskab til hvordan det er sat op kan
bryde ind? Eller er det mig der misforstår hvad du skriver?

--
Lars Kim Lund
http://www.net-faq.dk/

---

Lars Kim Lund wrote:

>>Jeg har moedt systemer som tog lang tid at portscanne pga. firewall regler
>>og andet som ejeren af maskinen fandt smart. Det eneste man kan skrive i
>>rapporten er, at man ikke fandt specifikke problemer ved den paagaeldende
>>maskine men at man ellers ikke kan udtale sig om hvor godt systemet kan
>>modstaa et angreb da man ikke aner hvordan det er sat op.


> Er det ikke en ret essentiel del i et professionelt sikkerhedscheck at
> afgøre om man med eller uden kendskab til hvordan det er sat op kan
> bryde ind? Eller er det mig der misforstår hvad du skriver?


....med eller uden kendskab... men her har man som auditør, intet kendskab.

Hvis man nu havde kendskabet eller var mere heldig, kunne man måske
finde nogle huller.

---

Lars Kim Lund wrote:

>>Jeg har moedt systemer som tog lang tid at portscanne pga. firewall regler
>>og andet som ejeren af maskinen fandt smart. Det eneste man kan skrive i
>>rapporten er, at man ikke fandt specifikke problemer ved den paagaeldende
>>maskine men at man ellers ikke kan udtale sig om hvor godt systemet kan
>>modstaa et angreb da man ikke aner hvordan det er sat op.

>Er det ikke en ret essentiel del i et professionelt sikkerhedscheck at
>afgøre om man med eller uden kendskab til hvordan det er sat op kan
>bryde ind? Eller er det mig der misforstår hvad du skriver?

Jeg blander mig lige...

Jeg skulle mene at en af hovedformålene med et "professionelt
sikkerhedscheck" (hvad det så end er) skulle være at få bekræftet, eller
afkræftet, ens opfattelse af ens eget netværk. Hvis du forstår.

Altså, IT-administrator Adam tror at hans Oracle-databaseserver henne i
hjørnet kun kører Oracle og kun vil snakke med lønsystemet ude i
Brønshøj. Hvis sikkerhedskonsulent Bob så finder ud af at der hænger en
port og lytter på tcp/666 og at den tilgås hver nat fra en IP i Taiwan,
er der måske et lille problem på netværket.

Eller mere subtilt:

Adam har sat to net op, administration- og medarbejdernettet, og
tillader ikke kommunikation imellem dem. Hvis Bob kommer på banen og
viser at der godt kan kommunikeres imellem dem, er der også et problem.

Altså, ikke et check efter deciderede sikkerhedshuller (som der
alligevel findes nye af, hurtigere end man kan nå at sige "jobskifte"),
men også et reality/sanity-check af ens netværk.

--
http://chran.dyndns.dk - Nu med nedbrud!

---

Christian Andersen wrote:

> Jeg skulle mene at en af hovedformålene med et "professionelt
> sikkerhedscheck" (hvad det så end er) skulle være at få bekræftet, eller
> afkræftet, ens opfattelse af ens eget netværk. Hvis du forstår.
>
> Altså, IT-administrator Adam tror at hans Oracle-databaseserver henne i
> hjørnet kun kører Oracle og kun vil snakke med lønsystemet ude i
> Brønshøj. Hvis sikkerhedskonsulent Bob så finder ud af at der hænger en
> port og lytter på tcp/666 og at den tilgås hver nat fra en IP i Taiwan,
> er der måske et lille problem på netværket.


Vil en netværksauditering finde ovenstående?

Nogle trojer lytter først når der kommer en speciel designet ICMP pakke.


> Eller mere subtilt:
>
> Adam har sat to net op, administration- og medarbejdernettet, og
> tillader ikke kommunikation imellem dem. Hvis Bob kommer på banen og
> viser at der godt kan kommunikeres imellem dem, er der også et problem.

Vil en netværkauditering finde ovenstående?

---

Christian E. Lysel wrote:

>> Altså, IT-administrator Adam tror at hans Oracle-databaseserver henne i
>> hjørnet kun kører Oracle og kun vil snakke med lønsystemet ude i
>> Brønshøj. Hvis sikkerhedskonsulent Bob så finder ud af at der hænger en
>> port og lytter på tcp/666 og at den tilgås hver nat fra en IP i Taiwan,
>> er der måske et lille problem på netværket.

>Vil en netværksauditering finde ovenstående?

Ja. Hvis den er professionel

Seriøst. Hvis fyren(m/k) kan sit kram, vil han netop kigge på netværket
som helhed og ikke bare på delkomponenter.

En holistisk auditering, om du vil.

>Nogle trojer lytter først når der kommer en speciel designet ICMP pakke.

Nå? Og hvordan ved den så, når der kommer en special designet
ICMP-pakke?

>> Adam har sat to net op, administration- og medarbejdernettet, og
>> tillader ikke kommunikation imellem dem. Hvis Bob kommer på banen og
>> viser at der godt kan kommunikeres imellem dem, er der også et problem.

>Vil en netværkauditering finde ovenstående?

Yes!

--
http://chran.dyndns.dk - Nu med nedbrud!

---

Christian Andersen wrote:

>>Vil en netværksauditering finde ovenstående?
> Seriøst. Hvis fyren(m/k) kan sit kram, vil han netop kigge på netværket
> som helhed og ikke bare på delkomponenter.


Men det vil kræve mere end blot en netværksauditering.


>>Nogle trojer lytter først når der kommer en speciel designet ICMP pakke.
> Nå? Og hvordan ved den så, når der kommer en special designet
> ICMP-pakke?


Tja, trojen venter på en ICMP pakke hvori der står "Hejsa, åben lige en
listner på port 666", hvorefter den åbner en listner på port 666. Når
angriberen er færdig med at bruges listneren, lukker den af sig selv igen.

Derved vil en port scanning ikke vise en pind.

>>>Adam har sat to net op, administration- og medarbejdernettet, og
>>>tillader ikke kommunikation imellem dem. Hvis Bob kommer på banen og
>>>viser at der godt kan kommunikeres imellem dem, er der også et problem.
>>Vil en netværkauditering finde ovenstående?
> Yes!


Nix, den vil hvis man er heldig finde ovenstående.

Jeg har auditeret flere IT installationer, hvor man kunne vade fra det
ene net til det andet, men hvor en netværksauditering ikke ville finde
fejlen.

---

Christian E. Lysel wrote:

>>>Vil en netværksauditering finde ovenstående?

>> Seriøst. Hvis fyren(m/k) kan sit kram, vil han netop kigge på netværket
>> som helhed og ikke bare på delkomponenter.

>Men det vil kræve mere end blot en netværksauditering.

Muligvis har vi forskellige opfattelser af hvad en netværksauditering
er. Eller måske snarere af, hvor grundig den bør være.

--
http://chran.dyndns.dk - Nu med nedbrud!

---

Alex Holst wrote:

> Christian E. Lysel <chlyshoswmdatapunktumcom@example.net> wrote:
>>Jeg mener da det er sværet at angribe et system man ikke kan genkende,
>>eller som lyver omkring hvilket system det er.

> Jeg tillader mig at gaa ud fra, systemet ikke koerer services med kendte
> sikkerhedsfejl. Security through obscurity i meget smaa maengder er


Ved ovenstående forudsætning har du 100% ret :) ellers ikke :)

Som det er i dag kan man lave forspørgelser efter sårbarheder i servere
i kende søgesystemer. Således er det meget nemt at finde sårbar servere.

> acceptabelt saalaenge det ikke er den primaere form for beskyttelse.
> Jeg synes nu mest det er fjollet.

Læs slutningen af dette indlæg.

> Hvis du virkeligt moeder en angriber som kan se at du koerer OpenSSH 3.0.2,
> og han efterfoelgende saetter sig ned og bruger 4 uger paa at finde et
> sikkerhedshul i koden og udvikle et exploit er der ikke meget du kan goere
> for at stoppe ham. Det vil vaere op til opsaetningen af systemet og
> overvaagningen af ditto at opdage ham.


Men hvorfor skal OpenSSH daemonen fortælle at den er i version 3.0.2,
det er unødig information.

Endvidere, hvordan ville han kunne sætte sig ned i 4 uger og finde en
sårbarhed, hvis han ikke ved hvilken implementation af ssh, hvilken
version den kører, på hvilken maskine arkitektur, på hvilket operativ
system, etcetera???

Den eneste måde han kan finde en sårbarhed på, er ved at vide hvilken
implementation, version, arkitektur og OS, det er!

Hvis han derimod brugte 4 uger på at udvikle en sårbarhed til IIS5.0, og
serveren i virkeligheden kører apache, har han brugt 4 uger på ingen
ting, udover at vi kan monitorer hans angreb.


Endvidere ville jeg som angriber, indsamle information omkring
ovenstående (host-databasen), og sammenholde det op imod min exploit
database. Hver gang exploit databasen vokser, vil jeg sammenkører den op
imod host-databasen. Ved evt. matches ville jeg teste om host-databasen
stadigvæk afspejler virkelighen, og hvis dette er tilfældet, ville jeg
exploite host'ene.

>>Fx hvis en apache server, udgav sig som en IIS4.0 server, med headers,
>>fejlmeddelser, og .asp-scripts, herefter kan man så oprette regulærer
>>udtryk til logfilen der fangede almidelig angreb på en IIS4.0 server.
> Hvis en af mine ansatte sad og satte Apache op til at ligne en anden httpd
> for at beskytte mod sikkerhedsproblemer ville jeg fyre ham oejeblikkeligt
> pga. komplet misforstaaelse af problemet OG loesningen. Jeg haaber dog ikke
> saadan et menneske overlever interviewet.


Det er ikke for at beskytte imod sikkerhedshuller! Men derimod for at
forvirrer angriberen.

Så ovenstående.

> Jeg har moedt systemer som tog lang tid at portscanne pga. firewall regler
> og andet som ejeren af maskinen fandt smart. Det eneste man kan skrive i
> rapporten er, at man ikke fandt specifikke problemer ved den paagaeldende
> maskine men at man ellers ikke kan udtale sig om hvor godt systemet kan
> modstaa et angreb da man ikke aner hvordan det er sat op.


Problemet er nok at auditeringen er en netværksauditering, i stedet for
en consol auditering. Dog har mange det indtryk af en rapport der er
skrevet på baggrund af en consol auditering, at hullerne "kun" er
teoretiske og ikke kan bruges i virkeligheden, hvorimod en
netværksauditering jo viser virkelige huller. Dette finder jeg som en
begrænsende tankegang.

Er det ikke det samme med passwords. Hvis man ved login taster det
forkerte password 3 gange i træk, disables passwordet i en tidsperiode.

Jeg kan godt se det fornuftige i ovenstående, dog er der nok andre ting
man bør løse først :)

---

Christian E. Lysel <chlyshoswmdatapunktumcom@example.net> wrote:
> Alex Holst wrote:
>
>> Jeg tillader mig at gaa ud fra, systemet ikke koerer services med kendte
>> sikkerhedsfejl. Security through obscurity i meget smaa maengder er
>
> Ved ovenstående forudsætning har du 100% ret :) ellers ikke :)

Det er lidt af et problem med diskussionerne i denne gruppe. Naar der
diskuteres abstrakte situationer (i modsaetning til specifikke spoergsmaal)
er det let at fokusere paa detailer som kan goere stor forskel i praksis
afhaengig af situationen, eller afvise problemet som en "policy decision."

> Men hvorfor skal OpenSSH daemonen fortælle at den er i version 3.0.2,
> det er unødig information.

Versionsoplysningerne bruges blandet andet til at tage hoejde for
kompatibilitetsproblemer mellem forskellige versioner. Noget som er meget
savnet i andre protokoller.

> Endvidere, hvordan ville han kunne sætte sig ned i 4 uger og finde en
> sårbarhed, hvis han ikke ved hvilken implementation af ssh, hvilken
> version den kører, på hvilken maskine arkitektur, på hvilket operativ
> system, etcetera???

Angriberen skal naturligvis vide hvor han skal lede efter fejl. Jeg vil dog
paastaa, at hvis du har data som nogen vil goere saa meget for at faa fat i,
boer du benytte airgaps eller hvertfald maskiner som ikke IP forwarder
mellem net.

Jeg mindes en email jeg modtog for noget tid siden i forbindelse med en job
annonce vi havde sendt ud. Det var fra en IT risk manager som var chokeret
over, at et firma som vores frit beskrev i job annoncen hvilke
operativsystemer vi brugte (og dermed forventede at kandidaten havde
erfaring med) da det var lidt af en risiko at tage, mente han.

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.area51.dk/

---

Alex Holst wrote:

>>Ved ovenstående forudsætning har du 100% ret :) ellers ikke :)
> Det er lidt af et problem med diskussionerne i denne gruppe. Naar der
> diskuteres abstrakte situationer (i modsaetning til specifikke spoergsmaal)
> er det let at fokusere paa detailer som kan goere stor forskel i praksis
> afhaengig af situationen, eller afvise problemet som en "policy decision."


Ja, men hvad hentyder du til?


>>Men hvorfor skal OpenSSH daemonen fortælle at den er i version 3.0.2,
>>det er unødig information.
> Versionsoplysningerne bruges blandet andet til at tage hoejde for
> kompatibilitetsproblemer mellem forskellige versioner. Noget som er meget
> savnet i andre protokoller.


Men at OpenSSH er i version 3.0.2 siger ikke direkte noget om
kompatibilitetsproblemer. Jeg kan bedre forstå hvis den siger at der
kører ssh version 1.0 eller 2.0, hvilket også kommer senere i sessionen.

Hvilke andre protokoller?

> Angriberen skal naturligvis vide hvor han skal lede efter fejl. Jeg vil dog
> paastaa, at hvis du har data som nogen vil goere saa meget for at faa fat i,
> boer du benytte airgaps eller hvertfald maskiner som ikke IP forwarder
> mellem net.


Der kan være mange andre grunde til at bryde ind i et system, det ved du
godt.

Det holder ikke stik med min forstilling af en ond hacker, der holder to
databaser, en over hosts og en anden over exploits. Tiden er kun på
hackerens side.

Er han først inde, kan det være umuligt at opdage det i et miljø der er
i produktion.


> Jeg mindes en email jeg modtog for noget tid siden i forbindelse med en job
> annonce vi havde sendt ud. Det var fra en IT risk manager som var chokeret
> over, at et firma som vores frit beskrev i job annoncen hvilke
> operativsystemer vi brugte (og dermed forventede at kandidaten havde
> erfaring med) da det var lidt af en risiko at tage, mente han.


Man få mere at vide til en job samtale.

Men ja, stillingsopslag fortæller de mest mærkelige ting, jeg har da et
par venner der ikke gider at læse nyheder, men i stedet bladre over i
stillingsannoncer-sektionen, da de siger mere om hvad der forgår i det
danske erhvervsliv, end almindelige artikler.

---

Christian E. Lysel <chlyshoswmdatapunktumcom@example.net> wrote:
> Alex Holst wrote:
>
>>>Ved ovenstående forudsætning har du 100% ret :) ellers ikke :)
>> Det er lidt af et problem med diskussionerne i denne gruppe. Naar der
>> diskuteres abstrakte situationer (i modsaetning til specifikke spoergsmaal)
>> er det let at fokusere paa detailer som kan goere stor forskel i praksis
>> afhaengig af situationen, eller afvise problemet som en "policy decision."
>
> Ja, men hvad hentyder du til?

At vi hver isaer kan blive ved i en uendelighed med at komme med argumenter
for vores synspunkter, da vi ikke har begraenset debatten.

> Men at OpenSSH er i version 3.0.2 siger ikke direkte noget om
> kompatibilitetsproblemer. Jeg kan bedre forstå hvis den siger at der
> kører ssh version 1.0 eller 2.0, hvilket også kommer senere i sessionen.

Klippe, klippe - /usr/src/usr.bin/ssh/sshconnect.c:

414 server_version_string = xstrdup(buf);
415
416 /*
417 * Check that the versions match. In future this might accept
418 * several versions and set appropriate flags to handle them.
419 */
420 if (sscanf(server_version_string, "SSH-%d.%d-%[^\n]\n",
421 &remote_major, &remote_minor, remote_version) != 3)
422 fatal("Bad remote protocol version identification: '%.100s'",
buf);
423 debug("Remote protocol version %d.%d, remote software version
%.100s",
424 remote_major, remote_minor, remote_version);
425
426 compat_datafellows(remote_version);
427 mismatch = 0;
428
429 switch(remote_major) {
430 case 1:
431 if (remote_minor == 99 &&
432 (options.protocol & SSH_PROTO_2) &&
433 !(options.protocol & SSH_PROTO_1_PREFERRED)) {
434 enable_compat20();
435 break;
436 }
437 if (!(options.protocol & SSH_PROTO_1)) {
438 mismatch = 1;
439 break;
440 }
441 if (remote_minor < 3) {
442 fatal("Remote machine has too old SSH software version.");
443 } else if (remote_minor == 3 || remote_minor == 4) {
444 /* We speak 1.3, too. */
445 enable_compat13();
446 minor1 = 3;
447 if (options.forward_agent) {
448 log("Agent forwarding disabled for protocol 1.3");
449 options.forward_agent = 0;
450 }
451 }
452 break;

Og saa videre. Baade OpenSSH og PuTTY tager hoejde for naar den skaber
forbindelse til visse aeldre sshd's med kendte protokol implementationsfejl.
Ikke at dette er ret relevant for denne gruppe.

> Det holder ikke stik med min forstilling af en ond hacker, der holder to
> databaser, en over hosts og en anden over exploits. Tiden er kun på
> hackerens side.
>
> Er han først inde, kan det være umuligt at opdage det i et miljø der er
> i produktion.

Igen maa man forvente at ejeren af maskinen har vurderet risiko ved et
indbrud og hvad det koster at forhindre et indbrud. Hvis maskinen paa nogen
maade er kritisk maa man forvente korrekt brug af en integrity checker der
kan sikre at systemets kerne, systemfiler og brugerkontoer ser ud som de
skal.

VVS-mand Jensen har maaske en kontor assistent som lige kan finde ud af at
koere Windows Update en gang om ugen paa den maskine som udelukkende
haandterer en lille hjemmeside og lidt email, og det er passende for deres
risiko budget.

Hvis Team Teso eller ADM beslutter sig for at finde en ny fejl i IIS
udelukkende med det formaal at deface VVS-mand Jensen's webserver har
VVS-mand Jensen's lille server jo ikke en chance.

En lidt stoerre organisation vil nok installere sikkerhedsopdateringer samme
dag som de bliver frigivet, og der er maaske brugt tid paa at fjerne ubrugte
komponenter fra IIS for at formindske risikoen.

Det handler i sidste ende om penge.

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.area51.dk/

---

Alex Holst wrote:
>
> Klippe, klippe - /usr/src/usr.bin/ssh/sshconnect.c:
>
> 414 server_version_string = xstrdup(buf);
> 415
> 416 /*
> 417 * Check that the versions match. In future this might accept
> 418 * several versions and set appropriate flags to handle them.
> 419 */
> 420 if (sscanf(server_version_string, "SSH-%d.%d-%[^\n]\n",
> 421 &remote_major, &remote_minor, remote_version) != 3)

Ved første øjekast er det svært at se, hvorfor der ikke er en
bufferoverflow exploit her. Men hvis man kigger lidt længere
oppe i koden, ser man dette:

void
ssh_exchange_identification(void)
{
char buf[256], remote_version[256]; /* must be same size! */

Men, er det nu en fornuftig måde at forhindre bufferoverflows?

--
Kasper Dupont

Notice: By sending SPAM (UCE/BCE) to this address, you are
accepting and agreeing to our charging a $1000 fee, per
email, for handling and processing, and you agree to pay any
and all costs for collecting this fee.

---

Kasper Dupont wrote:

>Ved første øjekast er det svært at se, hvorfor der ikke er en
>bufferoverflow exploit her. Men hvis man kigger lidt længere
>oppe i koden, ser man dette:
>
>void
>ssh_exchange_identification(void)
>{
> char buf[256], remote_version[256]; /* must be same size! */
>
>Men, er det nu en fornuftig måde at forhindre bufferoverflows?

**Jeg aner intet om programmering, undtagen BASIC**

Ja, er den ikke meget fornuftig? Så vidt jeg kan se bliver der fastsat
en bufferstørrelse i ovenstående linier. Alt input udover
bufferstørrelsen bliver vel smidt væk? Eller hvad?

--
http://chran.dyndns.dk - Nu med nedbrud!

---

Christian Andersen <m4jni76ztglp001@sneakemail.com> wrote:

>Kasper Dupont wrote:
>
>>void
>>ssh_exchange_identification(void)
>>{
>> char buf[256], remote_version[256]; /* must be same size! */
>>
>>Men, er det nu en fornuftig måde at forhindre bufferoverflows?
>
>**Jeg aner intet om programmering, undtagen BASIC**
>
>Ja, er den ikke meget fornuftig? Så vidt jeg kan se bliver der fastsat
>en bufferstørrelse i ovenstående linier. Alt input udover
>bufferstørrelsen bliver vel smidt væk? Eller hvad?

Nej, ikke medmindre programmøren selv sørger for det. I C (og
C++) er der ingen automatisk mekanisme der hindrer at man bare
skriver videre i lageret efter sådan en variabel.

Det er C's primære ulempe, og det er grunden til at begyndere bør
holde sig langt fra C indtil de vha. et sikrere sprog er blevet
erfarne programmører. Til gengæld er det medvirkende til den
enorme fleksibilitet som C giver og som især er en fordel når man
skriver lavniveauprogrammel.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).

---

Jesper Dybdal wrote:

>>Ja, er den ikke meget fornuftig? Så vidt jeg kan se bliver der fastsat
>>en bufferstørrelse i ovenstående linier. Alt input udover
>>bufferstørrelsen bliver vel smidt væk? Eller hvad?

>Nej, ikke medmindre programmøren selv sørger for det. I C (og
>C++) er der ingen automatisk mekanisme der hindrer at man bare
>skriver videre i lageret efter sådan en variabel.

Ok. Mange tak.

--
http://chran.dyndns.dk - Nu med nedbrud!

---

Christian Andersen wrote:
>
> Kasper Dupont wrote:
>
> >Ved første øjekast er det svært at se, hvorfor der ikke er en
> >bufferoverflow exploit her. Men hvis man kigger lidt længere
> >oppe i koden, ser man dette:
> >
> >void
> >ssh_exchange_identification(void)
> >{
> > char buf[256], remote_version[256]; /* must be same size! */
> >
> >Men, er det nu en fornuftig måde at forhindre bufferoverflows?
>
> **Jeg aner intet om programmering, undtagen BASIC**

Så må jeg hellere uddybe det lidt.

>
> Ja, er den ikke meget fornuftig? Så vidt jeg kan se bliver der fastsat
> en bufferstørrelse i ovenstående linier. Alt input udover
> bufferstørrelsen bliver vel smidt væk? Eller hvad?

Mellem erklæringen af de to arrays og sprintf linien står noget
kode, der modtager identifikationsstrengen i buf og checker at
der er plads nok. Og så længe remote_version er mindst lige så
stor som buf vil sscanf linien ikke kunne give bufferoverløb,
men taget ud af sammenhængen ser sscanf linien meget risikabel
ud.

Det der gør mig nervøs er, at når der arbejdes videre på denne
kode kunne der meget nemt opstå et bufferoverløb her.

F.eks. vil mange C programmører tro at det altid er sikkert at
udvide et array. Hvis man ændrede størelsen af buf til 512 uden
at tænke over kommentaren ville fanden være løs.

Jeg kender ikke detaljerne af ssh protokollen, men jeg vil
formode der er en øvre grænse for længden af identifikations-
strengen. Det ville IMHO være bedre at checke denne grænse i
første omgang i stedet for bufferstørelsen, og afbryde
kommunikationen hvis strengen er for lang.

Der er et par andre detaljer, der undrer mig. Hvorfor er der
overhovedet to buffere? Man bruger så vidt jeg kan se kun en
ad gangen, hvis man brugte den samme buffer begge stedder
ville man ikke skulle bekymre sig om hvorvidt de har samme
størelse. Man skulle blot ændre fatal udskriften midt i
funktionen til at bruge kopien af buf i stedet for buf selv.

Det andet der undrer mig er, hvorfor man ved kopieringen af
buf meget omhygeligt allocerer præcist den rigtige plads
med noget kode der kan håndtere vilkårlig længde strenge
mens man andre stedder har bundet sig til maks 255 tegn.

Det undrer mig også hvorfor man ved modtagelse af et carriage-
return tegn sætter et nul tegn i slutningen af strengen, og
straks efter henter det næste tegn oven i nul tegnet.

Men jeg har ikke fundet egentlige fejl i koden, kun særheder.

>
> --
> http://chran.dyndns.dk - Nu med nedbrud!

Her er koden, hvis nogen skulle være i tvivl om, hvad jeg
snakker om.

/*
* Waits for the server identification string, and sends our own
* identification string.
*/
void
ssh_exchange_identification(void)
{
char buf[256], remote_version[256]; /* must be same size! */
int remote_major, remote_minor, i, mismatch;
int connection_in = packet_get_connection_in();
int connection_out = packet_get_connection_out();
int minor1 = PROTOCOL_MINOR_1;

/* Read other side\'s version identification. */
for (;;) {
for (i = 0; i < sizeof(buf) - 1; i++) {
int len = atomicio(read, connection_in, &buf[i], 1);
if (len < 0)
fatal("ssh_exchange_identification: read: %.100s", strerror(errno));
if (len != 1)
fatal("ssh_exchange_identification: Connection closed by remote host");
if (buf[i] == '\r') {
buf[i] = '\n';
buf[i + 1] = 0;
continue; /**XXX wait for \n */
}
if (buf[i] == '\n') {
buf[i + 1] = 0;
break;
}
}
buf[sizeof(buf) - 1] = 0;
if (strncmp(buf, "SSH-", 4) == 0)
break;
debug("ssh_exchange_identification: %s", buf);
}
server_version_string = xstrdup(buf);

/*
* Check that the versions match. In future this might accept
* several versions and set appropriate flags to handle them.
*/
if (sscanf(server_version_string, "SSH-%d.%d-%[^\n]\n",
&remote_major, &remote_minor, remote_version) != 3)
fatal("Bad remote protocol version identification: '%.100s'", buf);
debug("Remote protocol version %d.%d, remote software version %.100s",
remote_major, remote_minor, remote_version);

compat_datafellows(remote_version);

--
Kasper Dupont

Notice: By sending SPAM (UCE/BCE) to this address, you are
accepting and agreeing to our charging a $1000 fee, per
email, for handling and processing, and you agree to pay any
and all costs for collecting this fee.

---

Kasper Dupont wrote:

>> **Jeg aner intet om programmering, undtagen BASIC**

>Så må jeg hellere uddybe det lidt.

Jeg siger mange tak for gennemgangen.

Jeg skal vist til at lære det der C, der. Det lyder vist som noget grov'
noget.

--
http://chran.dyndns.dk - Nu med nedbrud!

---

Kasper Dupont <kasperd@daimi.au.dk> wrote:
>F.eks. vil mange C programmører tro at det altid er sikkert at
>udvide et array. Hvis man ændrede størelsen af buf til 512 uden
>at tænke over kommentaren ville fanden være løs.

Ja. Hvis man virkelig har brug for at to buffere har samme
størrelse så kan man skrive:

#define BUFFERSIZE 256
char buf[BUFFERSIZE], remote_version[BUFFERSIZE];
/* must be same size! */

og/eller eksplicit tjekke det:

if (sizeof buf != sizeof remote_version)
   FatalError(...);

(En ordentlig oversætter genererer selvfølgelig slet ingen kode
for den if-sætning når størrelserne er ens.)

Christian Andersen <m4jni76ztglp001@sneakemail.com> wrote:
>Jeg skal vist til at lære det der C, der. Det lyder vist som noget grov'
>noget.

Det er helt korrekt forstået. C og C++ er sprog hvor man kan
rode med sine data stort set lige så ubegrænset som i assembler,
men hvor man alligevel har et egentligt programmeringssprogs
kodekonstruktioner (rekursive funktioner, typetjek når man ønsker
det, objekter i C++, osv.). Man kan skrive nydelig letlæselig
kode i C - og man kan så sandelig også gøre det modsatte.

Selv om C/C++ generelt er mit foretrukne programmeringssprog,
bl.a. fordi jeg kender det særdeles godt og har vænnet mig til
den frihed man har i C, så mener jeg grundlæggende at
sikkerhedskritisk kode ikke bør skrives i sprog der ikke har
indekstjek, herunder strenglængdetjek. Hvis alle de
netværksprogrammer der hele tiden findes bufferoverløbsfejl i var
skrevet i et mere restriktivt sprog, så ville bufferoverløbene
(normalt) ikke føre til noget værre end at programmet døde - det
kan selvfølgelig være en ubehagelig DOS, men det er dog ret meget
bedre end at angribere kan slippe ind.

Med C++ kan man komme noget af vejen, fordi man kan lave klasser
der implementerer databuffere med indbygget længdetjek (fx
standardtypen String). Hvis man kun bruger den slags
"højniveautyper" i C++ kan man opnå god beskyttelse mod
bufferoverløb.

Så kører det naturligvis lidt langsommere end den rå C-kode - men
det er jo de færreste (i antal, ikke nødvendigvis i trafik)
netværksservere der har CPU-forbrug som et egentligt problem.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).

---

Alex Holst wrote:

>>Ja, men hvad hentyder du til?
> At vi hver isaer kan blive ved i en uendelighed med at komme med argumenter
> for vores synspunkter, da vi ikke har begraenset debatten.


Ja.

>>Men at OpenSSH er i version 3.0.2 siger ikke direkte noget om
>>kompatibilitetsproblemer. Jeg kan bedre forstå hvis den siger at der
>>kører ssh version 1.0 eller 2.0, hvilket også kommer senere i sessionen.


> Klippe, klippe - /usr/src/usr.bin/ssh/sshconnect.c:

I den stump kode du vedlage, bekræfter du blot hvad jeg skrev! Både
remote_major og remote_minor bliver brugt men ikke remote_version.

remote_major og remote_minor er protokol versionen og remote_version er
software versionen.

Dog kaldes compat_datafellows(remote_version), så du skulle måske i
stedet have includeret compat.c:

compat_datafellows(const char *version)
{
int i, ret;
char ebuf[1024];
regex_t reg;
static struct {
char *pat;
int bugs;
} check[] = {
{ "^OpenSSH[-_]2\\.[012]",
SSH_OLD_SESSIONID|SSH_BUG_BANNER|
SSH_OLD_DHGEX|SSH_BUG_NOREKEY },
{ "^OpenSSH_2\\.3\\.0",
SSH_BUG_BANNER|SSH_BUG_BIGENDIANAES|
SSH_OLD_DHGEX|SSH_BUG_NOREKEY},
{ "^OpenSSH_2\\.3\\.", SSH_BUG_BIGENDIANAES|SSH_OLD_DHGEX|
SSH_BUG_NOREKEY},
{ "^OpenSSH_2\\.5\\.[01]p1",
SSH_BUG_BIGENDIANAES|SSH_OLD_DHGEX|
SSH_BUG_NOREKEY },
{ "^OpenSSH_2\\.5\\.[012]",
SSH_OLD_DHGEX|SSH_BUG_NOREKEY },
{ "^OpenSSH_2\\.5\\.3",
SSH_BUG_NOREKEY },
{ "^OpenSSH", 0 },
{ "MindTerm", 0 },
{ "^2\\.1\\.0", SSH_BUG_SIGBLOB|SSH_BUG_HMAC|
SSH_OLD_SESSIONID|SSH_BUG_DEBUG|

SSH_BUG_RSASIGMD5|SSH_BUG_HBSERVICE },


Her ses det tydeligt hvad du mener :)

> Og saa videre. Baade OpenSSH og PuTTY tager hoejde for naar den skaber
> forbindelse til visse aeldre sshd's med kendte protokol implementationsfejl.
> Ikke at dette er ret relevant for denne gruppe.


Men hvad har dette med sikkerhed at gører?

Ovenstående er nødvendligt grundet programfejl, hvilket er et dårligt
argument for at skulle give disse informationer.

Jeg mener forudsat at det er forkert af en service at give information
ud omkring systemet.

Du har dog lige kommet vist en situation hvor der ligger et argument bag

Men du har stadigvæk ikke argumenteret for hvorfor www.redhat.com
fortæller at de kører "Apache/1.3.19 (Unix) (Red-Hat/Linux)
mod_ssl/2.8.1 OpenSSL/0.9.5a" eller hvorfor en telnet session siger:
"Red Hat Linux release 7.1 (Seawolf) Kernel 2.4.2-2 on an i586"

Hvis man skulle bruge det positivt, ville det være at serveren fortælle
brugerne hvis de kører klienter der kan exploits, og derfor bør
opgraderes. :)

---

In article <3C2DAEAB.7060709@example.net>, Christian E. Lysel wrote:
>
>>>Men at OpenSSH er i version 3.0.2 siger ikke direkte noget om
>>>kompatibilitetsproblemer. Jeg kan bedre forstå hvis den siger at der
>>>kører ssh version 1.0 eller 2.0, hvilket også kommer senere i sessionen.
>
>> Klippe, klippe - /usr/src/usr.bin/ssh/sshconnect.c:
>
> Dog kaldes compat_datafellows(remote_version), så du skulle måske i
> stedet have includeret compat.c:

[...]

> Her ses det tydeligt hvad du mener :)

Ja, klart, det var nemlig voldsomt svært at regne ud fra
compat_datafellows(remote_version)

--
Andreas Plesner Jacobsen | Money may buy friendship but money cannot buy love.

---

On Fri, 28 Dec 2001 23:45:36 +0100, "Christian E. Lysel"
<chlyshoswmdatapunktumcom@example.net> wrote:

>Som det er i dag kan man lave forspørgelser efter sårbarheder i servere
>i kende søgesystemer. Således er det meget nemt at finde sårbar servere.

Det holder kun, hvis du forudsætter at et systen kun bliver angrebet
ved at nogen tilfældigvis falder over et sikkerhedshul.

Ved et egentligt målrettet angreb, kan du roligt regne med at noget af
det letteste at finde ud af, er hvilken webserver, der køres, så at
nogen bruger tid på at lade deres Apache-webserver præsentere sig som
MS-IIS, er mildest talt til grin - specielt i betragtning af at mange
orme fyrer al skytset af, uden fx at checke på webserver-navn først.

Jeg havde på et tidspunkt lavet en lang, lang liste over simple
"kradse-i-lakken"-muligheder, man kunne lave overfor en webserver. Der
var alt lige fra at forsøge at requeste .htaccess-filer (og håbe på en
afslørende 403'er), requeste robots.txt (eller et link med en
stavefejl og håbe på en default 404-fejlside), at requeste et link med
et /fakedir tilføjet til URL'en for at kigge efter
serverside-scripting, at POST'e (og checke for en 405'er ved statiske
sider), at POST-uploade en fil for at checke efter PHP, at lave
conditional requests, og så fremdeles. Meget af dette kan
automatiseres.

Jeg valgte dog at opgive at lave et offentligt program til det. For
det første er der ingen grund til at hjælpe folk med den slags
multi-opslag (der er ret noisy; den slags må folk gøre fra deres eget
IP-nummer), og for det andet vil det blot betyde, at folk uden
forstand på sikkerhed blot ville rette deres webserver til, indtil mit
automatiske script ikke længere havde et kvalificeret gæt på hvilken
webserver, der køres - og SÅ ville de tro, at de havde gjort et godt
stykke arbejde...

--
- Peter Brodersen
24 Days of Crashmas - julekalender:
http://jul.bums.dk/

---

Hej Alex,

Jeg har taget lidt af det foregående og kommenteret det :
------
> Jeg tillader mig at gaa ud fra, systemet ikke koerer services med kendte
> sikkerhedsfejl. Security through obscurity i meget smaa maengder er
> acceptabelt saalaenge det ikke er den primaere form for beskyttelse. Jeg
> synes nu mest det er fjollet.
Så længe at det ikke er den primære beskyttelse, jo. Ellers er der intet i
vejen for at gøre livet besværligt for folk, det giver dig mere tid.

> Hvis du virkeligt moeder en angriber som kan se at du koerer OpenSSH
> 3.0.2, og han efterfoelgende saetter sig ned og bruger 4 uger paa at finde
> et sikkerhedshul i koden og udvikle et exploit er der ikke meget du kan
> goere for at stoppe ham. Det vil vaere op til opsaetningen af systemet og
> overvaagningen af ditto at opdage ham.
Enig, men når du finder cracket er det for sent

>> Fx hvis en apache server, udgav sig som en IIS4.0 server, med headers,
>> fejlmeddelser, og .asp-scripts, herefter kan man så oprette regulærer
>> udtryk til logfilen der fangede almidelig angreb på en IIS4.0 server.
>
> Hvis en af mine ansatte sad og satte Apache op til at ligne en anden httpd
> for at beskytte mod sikkerhedsproblemer ville jeg fyre ham oejeblikkeligt
> pga. komplet misforstaaelse af problemet OG loesningen. Jeg haaber dog
> ikke saadan et menneske overlever interviewet.
Om den ikke udgiver sig for at være noget eller om den udgiver sig for at
være en IIS. Det kommer vel ud på et. Endnu engang : Det gælder om at gøre
livet surt for en angriber. Hvis vi tager din SSH fra før er det vel ikke
så dårligt at di IP ikke bliver logget som interessant når en script kiddie
scanner en klasse b.
Og om 'han' overlever et interview (jeg går ud fra at du mener til et evt.
job hos dig) er vel i denne sammenhæng ligegyldigt.

>> Det er specielt sjovt hvis et firma der lever af auditeringer, ej kan se
>> at det er en apache der i virkeligheden kører.
>
> Det kan jeg slet ikke se det underholdende i. Script kiddies har langt
> mere tid til at smide exploits efter en server end sikkerhedspersonale har
> til at bekraefte overholdelse af politikken.
Det er ikke sjovt at skulle til at tænke, og script kiddies kaster som
regel alt efter en server. Det er lige fedt for dem om det er exploits til
en IIS når det er en UNIX kværn de angriber.
Hvis et auditerings firma ikke har tid til at bruge andet en et færdigt
scanne efter fejl program, så er det stærkt begrænset hvad de finder
alligevel. Det de sikrer mod er stort set kun script kiddies. De bruger jo
de samme værktøjer.

> Jeg har moedt systemer som tog lang tid at portscanne pga. firewall regler
> og andet som ejeren af maskinen fandt smart. Det eneste man kan skrive i
> rapporten er, at man ikke fandt specifikke problemer ved den paagaeldende
> maskine men at man ellers ikke kan udtale sig om hvor godt systemet kan
> modstaa et angreb da man ikke aner hvordan det er sat op.
Hvis det pga. en firewall er vanskeligt at scanne et netværk eller en host
skulle det vel næppe ende op med en rapport som ikke fortæller noget ??
Hvis det er vanskeligt for dig at lure systemet bag er det jo også
vanskeligt for en angriber. Hvis man ikke kan finde specifikke problemer er
det vel heller ikke helt ringe, men hvis det du ser som et problem er at
scanner programmet ikke kan finde ud af det. Så er det vist mere dit
problem
---------

Mvh

Per R Laursen

---

PRL wrote:

> Hvis et auditerings firma ikke har tid til at bruge andet en et færdigt
> scanne efter fejl program, så er det stærkt begrænset hvad de finder
> alligevel. Det de sikrer mod er stort set kun script kiddies. De bruger jo
> de samme værktøjer.


Derfor er det også sjovt, hvis de ikke kan se det _er_ en apache.

>>Jeg har moedt systemer som tog lang tid at portscanne pga. firewall regler
>>og andet som ejeren af maskinen fandt smart. Det eneste man kan skrive i
>>rapporten er, at man ikke fandt specifikke problemer ved den paagaeldende
>>maskine men at man ellers ikke kan udtale sig om hvor godt systemet kan
>>modstaa et angreb da man ikke aner hvordan det er sat op.
> Hvis det pga. en firewall er vanskeligt at scanne et netværk eller en host
> skulle det vel næppe ende op med en rapport som ikke fortæller noget ??
> Hvis det er vanskeligt for dig at lure systemet bag er det jo også
> vanskeligt for en angriber. Hvis man ikke kan finde specifikke problemer er

> det vel heller ikke helt ringe, men hvis det du ser som et problem er at
> scanner programmet ikke kan finde ud af det. Så er det vist mere dit
> problem


Men måske er angriberen heldigere eller klogere end mig. Så er det jo
problematisk at auditøren ikke kan finde huller, fordi det skjuler sig.

---

Groft klippet :

Christian E. Lysel wrote:

> Derfor er det også sjovt, hvis de ikke kan se det _er_ en apache.
Ja, det er sjovt, for så virker det jo
Der er ikke noget bedre end at se de 'onde' spilde tiden.

> Men måske er angriberen heldigere eller klogere end mig. Så er det jo
> problematisk at auditøren ikke kan finde huller, fordi det skjuler sig.
Ja, man må indse at der altid er en eller anden som er smartere derude et
sted.
Det er i hvertfald problematisk at man ser det som et problem at det er
vanskeligt at lave en test af netværket/hosten. Det er da lige netop
sådanne ting som skal med i en rapport. Ellers er vurderingen af
sikkerheden da ubrugelig.



Mvh

Per R Laursen

---

On Sat, 29 Dec 2001 00:29:01 +0100, PRL <guffe@prl.dk> wrote:

>Der er ikke noget bedre end at se de 'onde' spilde tiden.

Med al respekt er det nok dig, der spilder tid, ved at sidde og
overvåge simple "fælder", der ikke fører til andet end nogle
automatiske angrebsforsøg på features, der alligevel ikke kører på den
webserver.

Hvis man tror, man virkelig har generet nogen, vil jeg mene, at man
overvurderer sin egen arbejdsindsats. Eller evt. undervurderer ens
arbejdstid.

--
- Peter Brodersen
24 Days of Crashmas - julekalender:
http://jul.bums.dk/

---

Peter Brodersen wrote:
> Med al respekt er det nok dig, der spilder tid, ved at sidde og
> overvåge simple "fælder", der ikke fører til andet end nogle
> automatiske angrebsforsøg på features, der alligevel ikke kører på den
> webserver.
De skal stadig ikke ignoreres, der er altid et forstadie.
Du kan selvfølgelig altid vurdere, hvilket nivaue du vil have.

> Hvis man tror, man virkelig har generet nogen, vil jeg mene, at man
> overvurderer sin egen arbejdsindsats. Eller evt. undervurderer ens
> arbejdstid.
Hvis et bare et fatalt forsøg afværges er det fint for mig.
Der er nu ikke meget mere arbejdstid i at kigge på 7 eller 15 linier.

Mvh

Per R Laursen

---

On Sat, 29 Dec 2001 18:59:05 +0100, PRL <guffe@prl.dk> wrote:

>> Hvis man tror, man virkelig har generet nogen, vil jeg mene, at man
>> overvurderer sin egen arbejdsindsats. Eller evt. undervurderer ens
>> arbejdstid.
>Hvis et bare et fatalt forsøg afværges er det fint for mig.

Hvorfor tror du, det er afværget?

Forestil dig at du har et Apache-webserver, som du forsøger at fremstå
som en MS-IIS-webserver, og du så har nogle triggers, der fortæller at
nogle fejlagtigt har forsøgt et angreb beregnet mod en
MS-IIS-webserver.

Er din konklusion så: "Det var godt, vi præsenterede os som en
MS-IIS-server, for de angreb virker ikke på os"? I så fald er der jo
ikke meget andet at sige til, end at de angreb ikke ville have virket
alligevel. Og hvis holdningen er, at man ved, der er sikkerhedshuller
i sin Apache, men man blot vælger at "sminke" webserveren til ikke at
afsløre, at der er tale om en Apache, så har man misforstået noget
angående sikkerhed.

--
- Peter Brodersen
24 Days of Crashmas - julekalender:
http://jul.bums.dk/

---

Peter Brodersen wrote:
> Hvorfor tror du, det er afværget?
Jeg tror ikke at der er noget som er afværget. Læs det jeg skriver.

> Er din konklusion så: "Det var godt, vi præsenterede os som en
> MS-IIS-server, for de angreb virker ikke på os"? I så fald er der jo
> ikke meget andet at sige til, end at de angreb ikke ville have virket
> alligevel. Og hvis holdningen er, at man ved, der er sikkerhedshuller
> i sin Apache, men man blot vælger at "sminke" webserveren til ikke at
> afsløre, at der er tale om en Apache, så har man misforstået noget
> angående sikkerhed.
Hvis du har læst tidligere indslag vil du se at jeg mener at det ikke er en
dårlig ting at gøre livet besværligt for en evt. cracker.
Men hvis jeg skal konkludere på et ligeså løst grundlag, så mener du
åbenbart det
Og, nej jeg konkluderer intet. Jeg kan overhovedet ikke se hvorfor du
drejer tråden i denne retning.

Skal jeg absolut konkludere noget i denne efterhånden temmeligt udvandede
diskussion, så må det være at er der nogen som prøver at pille på nogen som
helst måder ved mine maskiner så vil jeg kunne finde tilbage til det når
jeg ønsker det. Også selv om det set med dine øjne er ligegyldigt.

Mvh

Per R Laursen

---

Peter Brodersen wrote:
>
> Og hvis holdningen er, at man ved, der er sikkerhedshuller
> i sin Apache, men man blot vælger at "sminke" webserveren til ikke at
> afsløre, at der er tale om en Apache, så har man misforstået noget
> angående sikkerhed.

Dårligt eksempel, der er alt for få huller i Apache.

Hvis man nu havde fået sin IIS server til at præsentere
sig selv som Apache, ville man så have undgået Code Red
m.m.? Nej, for ormene angreb uden at checke hvilken
server der kørte. Om det overhovedet er muligt at få
IIS til at fremstå som noget andet ved jeg ikke, men
det vil alligevel ikke hjælpe.

--
Kasper Dupont

Notice: By sending SPAM (UCE/BCE) to this address, you are
accepting and agreeing to our charging a $1000 fee, per
email, for handling and processing, and you agree to pay any
and all costs for collecting this fee.

---

On Fri, 28 Dec 2001 12:14:26 +0000, Shoes <no-shoes@pobox.dk> wrote:

>TCP Sequence Prediction: Class=truly random
> Difficulty=9999999 (Good luck!)
>
>No OS matches for host (If you know what OS is running on it, see
>http://www.insecure.org/cgi-bin/nmap-submit.cgi).
>TCP/IP fingerprint:
>TSeq(Class=TR)
>T1(Resp=Y%DF=Y%W=403D%ACK=S++%Flags=AS%Ops=MNWNNT)
>T2(Resp=N)
>T3(Resp=Y%DF=Y%W=403D%ACK=S++%Flags=AS%Ops=MNWNNT)
>T4(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
>T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
>T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
>T7(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)
>PU(Resp=Y%DF=N%TOS=C0%IPLEN=164%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)
>
>
>Nmap run completed -- 1 IP address (1 host up) scanned in 161 seconds
>
>Burde vaere fornoeyd her..? :}

Får meg til å tenke på OpenBSD 3.0, men det er mulig jeg er litt for
religiøs.


- Eirik
--
Eirik Seim System Administrator
eirik.seim@mi.uib.no Math. Department
http://www.mi.uib.no/~eirik University of Bergen

---

* (Eirik Seim)

| Får meg til å tenke på OpenBSD 3.0, men det er mulig jeg er litt for
| religiøs.

At nmap ikke greier å gjette OS?

arabella# nmap -O localhost

Starting nmap V. 2.54BETA30 ( www.insecure.org/nmap/ )
[snip]
No exact OS matches for host (If you know what OS is running on it, see http://www.insecure.org/cgi-bin/nmap-submit.cgi).
TCP/IP fingerprint:
SInfo(V=2.54BETA30%P=i586-pc-linux-gnu%D=12/31%Time=3C307832%O=22%C=1)
TSeq(Class=RI%gcd=1%SI=48E6E5%IPID=Z%TS=100HZ)
TSeq(Class=RI%gcd=1%SI=48EC78%IPID=Z%TS=100HZ)
TSeq(Class=RI%gcd=1%SI=48D802%IPID=Z%TS=100HZ)
T1(Resp=Y%DF=Y%W=7FFF%ACK=S++%Flags=AS%Ops=MNNTNW)
T2(Resp=N)
T3(Resp=Y%DF=Y%W=7FFF%ACK=S++%Flags=AS%Ops=MNNTNW)
T4(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
PU(Resp=Y%DF=N%TOS=C0%IPLEN=164%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)
[snip]
arabella# uname -a
Linux arabella 2.4.16 #1 Mon Dec 10 01:30:35 CET 2001 i686 unknown
arabella#

--
Tollef Fog Heen
Unix _IS_ user friendly... It's just selective about who its friends are.

---

On 31 Dec 2001 15:39:06 +0100, Tollef Fog Heen <tollef-news@add.no>
wrote:

[...]

>arabella# nmap -O localhost
>
>Starting nmap V. 2.54BETA30 ( www.insecure.org/nmap/ )
>[snip]
>No exact OS matches for host (If you know what OS is running on it, see

[...]

>[snip]
>arabella# uname -a
>Linux arabella 2.4.16 #1 Mon Dec 10 01:30:35 CET 2001 i686 unknown

Er da 'arabella' en rett ut av boxen, eller fixet etter behov..?

---

On Tue, 01 Jan 2002 15:22:53 +0000, Shoes <no-shoes@pobox.dk> said:

> On 31 Dec 2001 15:39:06 +0100, Tollef Fog Heen <tollef-news@add.no>
> wrote:

>> [snip]
>> arabella# uname -a
>> Linux arabella 2.4.16 #1 Mon Dec 10 01:30:35 CET 2001 i686 unknown

> Er da 'arabella' en rett ut av boxen, eller fixet etter behov..?

«arabella» er det samme som output av kommandoen «hostname», og vil f
eks for min gamle maskin være «tsathoggua.rlyeh.net».

--
Diagnose: Manisk-imbesill

«"Amatør" og "inkompetent gjøk" er ikke helt det samme.»
- Erik Naggum, no.it.programmering.c, 2001-12-13 00:41:02 UTC

---

On 01 Jan 2002 16:43:12 +0100, Jan Ingvoldstad <jani@ifi.uio.no>
wrote:

>On Tue, 01 Jan 2002 15:22:53 +0000, Shoes <no-shoes@pobox.dk> said:
>
>> On 31 Dec 2001 15:39:06 +0100, Tollef Fog Heen <tollef-news@add.no>
>> wrote:
>
>>> [snip]
>>> arabella# uname -a
>>> Linux arabella 2.4.16 #1 Mon Dec 10 01:30:35 CET 2001 i686 unknown
>
>> Er da 'arabella' en rett ut av boxen, eller fixet etter behov..?
>
>«arabella» er det samme som output av kommandoen «hostname», og vil f
>eks for min gamle maskin være «tsathoggua.rlyeh.net».

Det forstod jeg :}, tenkte mer på om Linux'en var 'ut av boxen' eller
om du har firewallet den elns.
Ettersom nmap ikke fattet at det var kjerne 2.4.16 som kjorte.

'tsathoggua' var jaggu et lett og greit navn. :}
--
remove no- to reply.

---

On Tue, 01 Jan 2002 15:57:57 +0000, Shoes <no-shoes@pobox.dk> said:

> Det forstod jeg :}, tenkte mer på om Linux'en var 'ut av boxen' eller
> om du har firewallet den elns.

Ah, duh, sånn sett. Trege Jan. Det kan nok Tollef svare best på,
dog.


> 'tsathoggua' var jaggu et lett og greit navn. :}

Ja, og shub-niggurath og nyarlathotep var jo opptatt allerede.

--
Diagnose: Manisk-imbesill

«"Amatør" og "inkompetent gjøk" er ikke helt det samme.»
- Erik Naggum, no.it.programmering.c, 2001-12-13 00:41:02 UTC

---

* Shoes

| >arabella# uname -a
| >Linux arabella 2.4.16 #1 Mon Dec 10 01:30:35 CET 2001 i686 unknown
|
| Er da 'arabella' en rett ut av boxen, eller fixet etter behov..?

Som jani skriver -- arabella er navnet på boksen. Jeg kjører ikke med
iptables eller noe slikt. Ei heller patcher som har noe med nettverk
å gjøre (jeg kjører preempt-kernel-patchen, men jeg håper ikke den har
noe med TCP/IP-fingerprinting å gjøre. :)

--
Tollef Fog Heen
Unix _IS_ user friendly... It's just selective about who its friends are.

---

On 31 Dec 2001 15:39:06 +0100, Tollef Fog Heen <tollef-news@add.no> wrote:
>* (Eirik Seim)
>
>| Får meg til å tenke på OpenBSD 3.0, men det er mulig jeg er litt for
>| religiøs.
>
>At nmap ikke greier å gjette OS?

Nei, fingerprintet :)

Jeg hadde ihvertfall litt rett, det er en form for netbsd, hvis jeg ikke
(fremdeles) tar helt feil.


- Eirik
--
Eirik Seim System Administrator
eirik.seim@mi.uib.no Math. Department
http://www.mi.uib.no/~eirik University of Bergen

---

On 2 Jan 2002 13:41:25 GMT, eirik@peter.mi.uib.no (Eirik Seim) wrote:

>On 31 Dec 2001 15:39:06 +0100, Tollef Fog Heen <tollef-news@add.no> wrote:
>>* (Eirik Seim)
>>
>>| Får meg til å tenke på OpenBSD 3.0, men det er mulig jeg er litt for
>>| religiøs.
>>
>>At nmap ikke greier å gjette OS?
>
>Nei, fingerprintet :)
>
>Jeg hadde ihvertfall litt rett, det er en form for netbsd, hvis jeg ikke
>(fremdeles) tar helt feil.

Message-ID: <oll33ukfpbt6m7kqgkc2gj103cpqttlue4@4ax.com>
---
Det må dog nevnes at de porter som er åpne i orginal posting, blir
forwardet til en FreeBSD-4.4 . {110,22,21,80,25}
---
Så det var ikke så galt tippet da. :}

For min del er det litt sånn 'valgets kvaler' mht hva jeg skal basere
meg på, Linux , {Free/Open/Net}BSD er alle fine, og har sine gode
egenskaper, så jeg havner på en salig blanding... *s*

Saken blir jo self ikke bedre at denne postingen er skrevet via en
WinNT4-server... *s*

>- Eirik

---

[Tollef Fog Heen]

| | Får meg til å tenke på OpenBSD 3.0, men det er mulig jeg er litt for
| | religiøs.
|
| At nmap ikke greier å gjette OS?
...
| arabella# uname -a
| Linux arabella 2.4.16 #1 Mon Dec 10 01:30:35 CET 2001 i686 unknown

At nmap ikke uten videre greier å gjette OS er egentlig ganske positivt,
det betyr at TCP/IP implementasjonene omkring etterhvert begynner å bli
ganske brukbare! Her er tilsvarende for en FreeBSD 4.5-PRERELEASE boks i
nærheten:

TCP Sequence Prediction: Class=truly random
Difficulty=9999999 (Good luck!)
No OS matches for host (If you know what OS is running on it, see http://www.insecure.org/cgi-bin/nmap-submit.cgi).
TCP/IP fingerprint:
TSeq(Class=TR)
T1(Resp=Y%DF=N%W=FFFF%ACK=S++%Flags=AS%Ops=M)
T2(Resp=N)
T3(Resp=Y%DF=N%W=FFFF%ACK=S++%Flags=AS%Ops=M)
T4(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)
PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=0%ULEN=134%DAT=E)

Til sammenligning, nmap mot en eldre boks som forlengst burde vært tatt
av nettet:

TCP Sequence Prediction: Class=64K rule
Difficulty=1 (Trivial joke)

Sequence numbers: 32869200 32878C00 32888600 32898000 328A7A00 328C6E00
Remote operating system guess: SunOS 4.1.1 - 4.1.4 (or derivative)

Og gjettingen på operativsystem var helt korrekt.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

---

On 31 Dec 2001 15:52:10 GMT, sthaug@nethelp.no (Steinar Haug) wrote:

[...]

>At nmap ikke uten videre greier å gjette OS er egentlig ganske positivt,
>det betyr at TCP/IP implementasjonene omkring etterhvert begynner å bli
>ganske brukbare!

Jupp. :}

>Her er tilsvarende for en FreeBSD 4.5-PRERELEASE boks i
>nærheten:
>
>TCP Sequence Prediction: Class=truly random
> Difficulty=9999999 (Good luck!)
>No OS matches for host (If you know what OS is running on it, see http://www.insecure.org/cgi-bin/nmap-submit.cgi).

Bra, er den 'ut av boxen' {standard install}..?

[...]

>Til sammenligning, nmap mot en eldre boks som forlengst burde vært tatt
>av nettet:
>
>TCP Sequence Prediction: Class=64K rule
> Difficulty=1 (Trivial joke)
>
>Sequence numbers: 32869200 32878C00 32888600 32898000 328A7A00 328C6E00
>Remote operating system guess: SunOS 4.1.1 - 4.1.4 (or derivative)
>
>Og gjettingen på operativsystem var helt korrekt.

Hehe,
litt som mot en annen box jeg har litt a gjore med ,

~$ sudo nmap -O localhost

TCP Sequence Prediction: Class=random positive increments
Difficulty=3472834 (Good luck!)
Remote operating system guess: Linux 2.1.122 - 2.2.14

Ikke så langt fra sannheden,
Linux <hostname> 2.2.18 #2 Fri Mar 2 21:06:41 CET 2001 i686 unknown

Med tanke pa at burken jeg nmap'ed i orginal posting ogsa kjorer Linux
kjerne 2.2.18 synes jeg svaret fra nmap var greit nok. :}

Det må dog nevnes at de porter som er åpne i orginal posting, blir
forwardet til en FreeBSD-4.4 . {110,22,21,80,25}

Ettersom port 25 er åpen mot verden og jeg ikke er nogen expert på
mail-oppsett, sjekket jeg mot ordb.org og fikk,
---
The host you submitted at ORDB.org (<ip>), has been thoroughly
checked, and does not seem to permit relaying.
--- /
Mail-oppsettet mitt var mao greit nok. :}

Godt nytt år btw. :}

---

[Shoes ]

| >Her er tilsvarende for en FreeBSD 4.5-PRERELEASE boks i
| >nærheten:
| >
| >TCP Sequence Prediction: Class=truly random
| > Difficulty=9999999 (Good luck!)
| >No OS matches for host (If you know what OS is running on it, see http://www.insecure.org/cgi-bin/nmap-submit.cgi).
|
| Bra, er den 'ut av boxen' {standard install}..?

Stort sett ja.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no