Aaaiii. Dat lijkt goed mis! Dat domein staat op immortal malware domains lijst: http://mirrors.usu.edu/malwaredomains/immortal_domains.txt (zoek in die pagina).

Dat lijkt veel op een mislukte (?) poging van een MITM aanval, door middel van SSL stripper.


De schaduw van Vladimir is hier niet zichtbaar, met uBlock in Tor Browser onder Tails OS 4.21


uMatrix en Quad9 voorkomen verbrande vingers. Pas op op wiens lange tenen je gaat staan.

Ja, had ik ook gezien.
Ping geeft niets, omdat het ook in mijn hosts bestand staat:


Ik kan mij niet voorstellen dat zowel mijn systeem als die virtual machine met malware zijn geïnfecteerd.
Kan het zijn dat Security.nl is gecompromitteerd?

Ik zie zo gauw ook niets verdachts in de bron van Security.nl, waarbij ik moet toegeven dat mijn kennis van JavaScript nul is.

Ik denk dat je daar de root-cause te pakken hebt. Deze site laadt geen rare dingen bij mij (tested in multiple vms). Ik gok dat je een weirde interactie te pakken hebt tussen umatrix en je hosts file. Maybe slim om voor de zekerheid toch even lokaal goed te kijken voor malware op je eigen pc?

https://www.debian.org/security/2021/dsa-4963

CVE-2021-3711 openssl An attacker able to present SM2 content for decryption to an application can take advantage of this flaw to change application behaviour or cause the application to crash (denial of service).

Aan de deskundigen;
Ik volg als niet iT geschoolde gebruiker deze site.
Nu zie ik dat t's min of meer gered lijkt te zijn door een scriptblokker umatriks.
Ik ben nal van meerdere berichten omtrent het nut van een scriptblokker begonnen met mijzelf te verdiepen in noscript.
Daar vielen de adressen die met een site meekomen natuurlijk op.
Nu vroeg ik mijzelf al af, hoe verifieer ik die adressen veilig op hun functie en/of reputatie?
Tot nu toe kan ik alleen Google gebruiken, maar hoe doen jullie die verificatie?
Jullie zullen er zeker vak-sites voor hebben.
Maar wat kan ik als leek veilig gebruiken om te zien of ik " gered ben" door noscript?
Dus hoe kan ik veilig nagaan waarmee ik te maken krijg?
Alvast bedankt.

Klik daarvoor de icoon van NoScript in de werkbalk aan, waardoor het menu met de verborgen URLs verschijnt. Laat de muiscursor in het NoScript venster over de getoonde domeinen van de third party's en trackers van de bezochte website zweven. De cursor neemt dan de vorm van een vraagteken aan. Als je de daaronder getoonde URL dan aanklikt, dan verschijnt de bijbehorende 'Security and Privacy Info' pagina van noscript.net, waarop je je oordeel mede kunt baseren.

Verificatie gaat op basis van reputatie van de gevonden trackers en / of met behulp van JavaScript malware scanners.

Verhaaltje van "one bitten twice shy". Van zo'n incident leert men. En u bent zo iemand. Vertrouw geen onbekend script van 3rd party sites. Voorbeeldhttps://thehackerblog.com/the-noscript-misnomer-why-should-i-trust-vjs-zendcdn-net/
De Russische site is kwaadaardig (o.a. via Magento webshop hacks). Verwacht kwaadaardig script - is dagelijkse geautomatiseerde kost ;).
luntrus

Ja, als ik het hosts bestand terugzet naar default, zie ik dat domein niet verschijnen...

Ik zou echter niet weten waar ik in dit geval moet kijken naar eventueel aanwezige malware.

OpenSSL is hier gister bijgewerkt:

In mijn Tor browser onder Mint 19.3 zie ik hem ook niet.

Ik denk dat je beter een nieuw topic kunt maken met deze vraag.

Vreemd...
Als ik die entry 'sseal.ru' uit mijn hosts bestand verwijder, verschijnt 'ssh.mi61l.cn'
En als ik die weg haal, krijg ik 'ssiapawz.com'.

Deze domeinen zijn opeenvolgend in het hosts bestand...

[Edit]
En als ik er nog een paar weg haal verschijnt de aloude 'ssl.google-analytics.com'...

ok gewoon een bug dus.
wellicht doet er ergens iets een reverse-lookup van 127.0.0.1 ?
het is ook niet handig om 127.0.0.1 te gebruiken als adres in een hostsfile die je wilt gebruiken om bepaalde domeinen
te "blokkeren". Neem dan iets anders bijv 127.1.1.1 ofzo.

Het lijkt er dus op dat:
- ssl.google-analytics.com JavaScript probeert op te halen van 127.0.0.1 (voor de mensen die dit niet weten, dat is altijd de computer zelf, dus niet iets op internet);
- je, bovenaan jouw hosts file, geen entries (zowel IPv4 als IPv6) hebt staan voor localhost;
- umatrix reverse lookups doet (IP-adres -> domeinnaam) en daar (al dan niet via het OS) de hosts file voor gebruikt.

De vraag blijft wel waarom Google dat doet (evt. onder welke omstandigheden).

Aan 1e anoniem 09.52 en de 2e (luntrus)
Bedankt voor jullie reactie!
Dit begrijp ik en kan er tenminste weer iets meer mee.
Vooral ook bedankt voor de duidelijke waarschuwing luntrus.
Ik ken mijn plaats in deze. :-)
Groetjes.

Ik gebruik

Header van mijn hosts bestand:


[Edit]
Als ik uMatrix uitschakel, krijg ik geen entry voor 'sseal.ru' in uBlock Origin's logger.
Ook niets in Developer tools.

Deze uitspraak is in tegenspraak met wat je eerder plaatste:

ping sseal.ru
PING sseal.ru (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.031 ms

Een tip.

Laat je webbrowser onder Windows in een container of sandbox draaien. Dat maakt het gebruik van het web veiliger:

https://en.wikipedia.org/wiki/Sandboxie


Eigenaren van een Linux systeem gebruiken een AppArmor profiel of een Firejail, waarin ze de browser opsluiten.

Waar maakt u zich druk om?
Ik maak gebruik van een centrale server waar Pi-Hole op staat.
Als je alle query's bekijkt van bv de afgelopen 15 minuten gaan je nekharen overeind staan.
De meest vreemde sites worden aangeroepen als je browst over het internet.

Weer een puzzelstukje ;-)

Volgens https://news.ycombinator.com/item?id=20397473 en https://unix.stackexchange.com/questions/99336/how-does-ping-zero-works geldt dat voor Linux (alle versies?).

Daar pas ik mijn analyse (op basis van erg weinig gegevens) op aan, het lijkt er dus op dat:
- ssl.google-analytics.com JavaScript probeert op te halen van 0.0.0.0 (of toch van 127.*.*.* en Firefox, een plug-in of Linux dat vertaalt naar 0.0.0.0);
- umatrix reverse lookups doet (IP-adres -> domeinnaam) en daar (al dan niet via het OS) de hosts file voor gebruikt, waarbij kennelijk de eerst gevonden domeinnaam gekoppeld aan 0.0.0.0 wordt geretourneerd.

De vraag blijft wel waarom Google dat doet (evt. onder welke omstandigheden). Of komt dit uit umatrix zelf? Maar waarom dan niet bij DoH?

Als test heb ik even de optie in uMatrix om CNAME's te onthullen uitgezet.
Resultaat: geen 'sseal.ru' meer!

De oorzaak van deze "bug" is denk ik: in 1 regel in het hosts bestand staan 9 entries (dat kan).
Betreffende regel:

Helder, zo lijkt sseal.ru een CNAME van ssl.google-analytics.com.

Wat me opviel (en verbaasde) in jouw screenshot was dat het "script" vakje van ssl.google-analytics.com groen was/is en "1" bevat. Daardoor ging ik er vanuit dat JavaScript vanaf ssl.google-analytics.com werd gedownload en uitgevoerd (wat niet gebeurt omdat jouw hosts file dat verhindert, maar dat weet umatrix niet).

Als je [*.]google-analytics.com in umatrix had geblokkeerd, was je niet op het verkeerde been gezet - maar dan had ook ik hier niets van geleerd ;-)

Ja, ik had het een keer groen gezet, omdat uBlock Origin het toch omleid naar een dummy script. ;)

https://github.com/gorhill/uBlock/blob/a94df7f3b27080ae2dcb3b914ace39c0c294d2f6/src/web_accessible_resources/google-analytics_ga.js

Misschien moet ik [*.]google-analytics.com maar uit het hosts bestand verwijderen.
Het schijnt dat er sites zijn die niet (helemaal) goed werken als het streng wordt geblokkeerd.
Daar helpt dan dat dummy script voor, schijnt het.

[Edit]
Of ondervangen uMatrix en uBlock Origin die netwerk aanvragen eerst?

[Edit2]
Ja dus.
Zie:
https://old.reddit.com/r/uBlockOrigin/comments/khkysa/is_using_a_hosts_file_block_list_in_windows_on/gglm0gg/

https://en.wikipedia.org/wiki/CNAME_record

Mijn kwestie is hierbij opgelost.

Met dank aan allen en vooral Erik van Straten voor het meedenken!

je nu hoe instructief dit soort draadjes zijn. Zonder de OP en Erik van Straten was dit niet over het voetlicht gekomen. Toont ook wederom aan hoe Google van allerlei obfuscerende aliassen gebruik maakt, die hun allomtegenwoordige tracking tracht te verdoezelen. Malscript fighters hebben het daardoor niet gemakkelijk en ook degenen die precies willen analyseren wat er op de stack gebeurt.
luntrus

Gerelateerd:
https://bugzilla.mozilla.org/show_bug.cgi?id=1544233

https://bugzilla.mozilla.org/show_bug.cgi?id=1616252

Uit die bugzilla threads maak ik op dat de issue resolved zou zijn, waarmee -neem ik aan- bedoeld wordt dat Firefox, met DoH ingeschakeld, éérst de hosts file checkt (en bij een match geen DoH request doet).

Als je in je hosts file tijdelijk opneemt:
en, met DoH aan, https://www.security.nl/ opent, wat gebeurt er dan?

Voor de zekerheid zou ik testen met die regel aan het begin van de hosts file, maar ook met die regel (uitsluitend) aan het einde van een lange hosts file.

Als, met DoH aan, deze site opent (zou niet moeten zoals zonder DoH), kan het zijn dat er iets (wellicht Firefox) herstart moet worden om de hosts file (na wijziging) opnieuw in te lezen. Ook kan het zijn dat Firefox wel werkt zoals verwacht, maar dat één of meer van jouw plugins het DNS gedrag veranderen als DoH aan staat.

Nou breekt mijn klomp!
Met www.security.nl in mijn hosts bestand laad de site wel (na herstart browser)!
Dat zou toch niet moeten neem ik aan.

[Edit]
Ook in een schoon nieuw profiel zonder add-ons.

[Edit2]
En ook in een andere browser zonder DoH...

Het hosts bestand wordt niet meer gelezen lijkt het...
(ook niet na herstart van de PC)

Ik zie nu hoe dat kon:
In mijn hosts bestand stond ook:
haha.

Weggehaald en nu wordt het hosts bestand wel gelezen door de andere browser en laadt de site niet.
Echter nog wel in Firefox met DoH...

Dat lijkt controversieel als ik die bugzilla threads lees. Deze spreekt boekdelen, uit https://bugzilla.mozilla.org/show_bug.cgi?id=1544233#a34643193_1689:

Voordat DoH in Firefox werd geïntroduceerd, raadpleegde Firefox gewoon het OS om domeinnamen naar IP-adressen te resolven (elk OS met een "TCP/IP stack" biedt die functionaliteit). Daarbij zorgt het OS voor het parsen van de hosts file (de meeste OS'en zullen er wel een in-memory cache voor hebben).

Voor zover ik weet bestaat er geen OS'en waaraan je kunt vragen een DNS-lookup in uitsluitend de hosts file te doen. Als Mozilla Firefox van DoH gebruik wil laten maken (buiten het OS om) zullen zij zelf die hosts file moeten parsen, en dat is duidelijk iets waar een deel van de Firefox ontwikkelaars geen zin in had (of heeft). Hoe ga je bijv. om met fouten daarin?

Nu zag ik dat je de ESR versie van Firefox gebruikt - ik gok, maar het zou kunnen dat de fix (of de "enhancement") wel in de main stream versie van Firefox, maar (nog) niet in ESR verwerkt is.

Dank voor het testen in elk geval: goed om te weten dat genomen beveiligingsmaatregelen in in de hosts file simpelweg genegeerd kunnen worden. Ik was al geen fan van DoH, maar deze kennis maakt het er niet beter op...

Ik checkte nog even in een nieuwe tab of je wellicht aanvullingen had gedaan, ja dus (ik laat de tekst hierboven maar voor wat het is).
Ik denk dat je het beste een paar bakken sterke koffie kunt nemen en dan een wandeling maken (neem een plu mee). En morgen dubbelchecken dat je geen tikfouten in de hosts file hebt gemaakt, en daarna uitzoeken wanneer die hosts file wel en wanneer niet wordt geraadpleegd :-)

Aanvulling: we raken out of sync 8-/

Je had die latere post (20:40) nog niet gelezen denk ik. ;)

En nee, ik maak zelden tikfouten (beetje autistisch). ;)
Nee, ESR was in die Debian VM.
Firefox hier is 91.0.2.

Juist inrichten van een host file is belangrijk. Name server switch, waarbij DNS niet voor files kan komen. In dat laatste geval wordt etc/host namelijk eerst bevraagd. Gebruik host commando om te testen. Voor Erik is dat natuurlijk gesneden koek. Maar toch nog dit even ten overvloede.
luntrus

Nou nee, ook ik word voortdurend verrast (en niet alleen m.b.t. DNS). Als Firefox zelf DoH gebruikt en daarbij de hosts file links laat liggen, heb je -helaas- niks aan met je OS meegeleverde tools om te checken of DNS werkt zoals verwacht.

@Nicolaasjan: ik heb gisteravond verder gezocht, maar geen uitsluitsel gevonden of c.q. met welke instellingen, Firefox-met-DoH toch de hosts file evalueert.

In een antwoord in https://superuser.com/questions/1433325/does-firefox-ignore-the-hosts-file-how-to-make-firefox-honor-the-hosts-file wordt gesuggereerd dat het op false zetten van network.dns.offline-local (via about:config) Firefox-met-DoH de hosts file zou laten parsen, maar iemand anders meldt dat dit pas werkte in een vers profiel.
Bovendien lijkt dit een ongedocumenteerde instelling (placebo?) - want ik kan er verder weinig over vinden en false suggereert het tegenovergestelde (de key network.dns.offline-localhost bestaat overigens wel). Ik kan het niet pinpointen maar er zou ook nog een verschil kunnen bestaan tussen Firefox versies waarbij DoH de default is, en waarbij je DoH zelf hebt aangezet.

[rant] Firefox verliest onnodig gebruikers doordat stijfkoppige Mozilla ontwikkelaars onvoldoende aan verwachtingsmanagement doen. Ook al zouden er uitstekende redenen zijn om, bij gebruik van DoH, de hosts file niet meer te parsen: als je, als gebruiker, die redenen niet kent (d.w.z. ze je niet onder je neus zijn gedrukt) is dit totaal onlogisch, en m.i. -onder bepaalde omstandigheden- zelfs een security issue. Temeer daar veel Firefox-gebruikers een weloverwogen browserkeuze hebben gemaakt en dus vaak aanvullende beveiligingsmaatregelen zullen hebben genomen. Zo erger ik me er ook aan dat bij de gewone Firefox voor Android je about:config niet kunt openen (wel in de Nightly versie). [/rant]

Back on topic, ook hier geldt weer: it's always DNS (https://www.cscdbs.com/blog/wp-content/uploads/2021/05/Its-always-DNS-06-SSBroski.jpg. En neem toch die bak koffie, maar dan uit deze beker: https://i.etsystatic.com/7781014/c/740/588/149/255/il/8713bf/1663355705/il_340x270.1663355705_sepe.jpg :-)

@ Erik van Straten,
Samen met jou een bakkie doen met onderwijl een uitwisseling van gedachten hierover lijkt me een prima idee.
Inlezen, inlezen en selectief inlezen. Die zich juist weet in te lezen en info weet te vergaren is soms beter af als de l33t h@cker.
De bronnen zijn online te vinden. Die zoekt, die vindt.
Groetjes,
luntrus

Er bestaan Wiki's: https://wiki.mozilla.org/Trusted_Recursive_Resolver.
Hun plannen van de browser ontwikkelaars: https://support.mozilla.org/en-US/kb/firefox-dns-over-https
luntrus

Een oplossing? https://live.paoaltonetworks.com/t5/custom-signatures/custom-app-id-for-dns-over-https/td-p/229784[/URluntrus

Beide config opties doen helaas niets hier.
Ook niet in een vers profiel...

Dat verwachtte ik al...

Jaaaaren geleden heb ik kort met Unbound [1] gespeeld (nog onder XP) omdat het misbruiken van de hosts file als blocklist een slechte oplossing is: je kunt immers alleen volledige domeinnamen blokkeren (niet met 1 regel alle potentiële sub-, sub-sub- domeinen etc. onder example.com), noch TLD's blokkeren; met Unbound kan dat (beide als ik me goed herinner) wel.

[1] https://www.nlnetlabs.nl/projects/unbound/about/

Heb je al eens nagedacht over het lokaal draaien van een DNS resolver, of een PiHole gebruiken? Naar verluidt ondersteunt PiHole ook upstream DoH [2] en Unbound ondersteunt zelfs downstream DoH [3]. Nb. met de PiHole heb ik zelf geen ervaring en mijn kennis van Unbound is grotendeels weggezakt (en sowieso niet up-to-date).

[2] https://docs.pi-hole.net/guides/dns/cloudflared/
[3] https://blog.nlnetlabs.nl/dns-over-https-in-unbound/

Zijn de nameserver lines goed ingegeven?
luntrus

Hmm...
Ik denk dat dit toch een beetje te ingewikkeld wordt voor mij... Haha.

Ondertussen heb ik de kwestie maar even naar voren gebracht op de Firefox subreddit:
https://old.reddit.com/r/firefox/comments/pc1dic/with_doh_enabled_firefox_doesnt_read_hosts_file/

Mocht daar niets uit komen, dan kan ik wellicht een issue openen op Bugzilla?

Misschien heb je hier wat aan:
https://support.mozilla.org/en-US/questions/1266680

(heb het zelf niet uitgeprobeerd)

Weet ik, maar er staan ruim 42000 domeinen in mijn hosts bestand, dus dat is helaas geen optie.

Het kan een probleem met stabilieit zijn, dat veroorzaakt wordt door de systeem instellingen. Bij Windows zijn dat vaak registerproblemen en/of maximale file grootte. Google Chrome wil de grootte van blokkeringsfiles ook mettertijd gaan beperken. De redenen hiervoor kan een ieder wel bedenken. Ze geven niet voor niets geld aan Mozilla Firefox.
luntrus

Daarom heb ik het even getest met een hosts bestand met slechts 1 entry:
'0.0.0.0 www.google.com'
Dan wordt het geblokkeerd, maar het duurt even voordat de foutmelding wordt weergegeven.

Ik vind dit duidelijk een bug, omdat het volgens:
https://bugzilla.mozilla.org/show_bug.cgi?id=1616252
zou zijn opgelost.

Heb maar even een comment geplaatst daar:
https://bugzilla.mozilla.org/show_bug.cgi?id=1616252#c7
Of ze er wat mee doen is maar de vraag...

@nicolaasjan,
In ieder geval heb jij je verantwoordelijkheid genomen en het hier en daar gemeld aan de community. Wat meer kun je doen? Deed een ieder dat, leefden we met z'n allen in een veel veiliger wereld. Mij boeit het wel. Ik heb weer heel wat doorgenomen en het nodige ervan opgestoken. Alle ervaring onderwijst de mens, althans zo zou het moeten zijn. Ga zo door zou ik zeggen en een gemeende groet van mij,
luntrus

Ja Rusland is wel heel kwaadaardig misschien net zo erg zoniet erger dan diegenen die vreemde SIDs in execuables achterlaten , zo vond ik een bekende hash S-1-5-21-708247480-2834978148-2381576337-1001 die ik eerst maar niet kon verklaren. De md5sum van een bestand klopte niet. Kwam ik achter toen ik de exe proberen te draaien en een DLL vreemd ging doen.

Zouden de Russische malware boeren (vermoedelijk hebben ze gewoon bedrijven in Nederland die net nog geen kinderen in kantoorhuizen opsluit tot de malware klaar is want het de phishing mail was heel netjes in het Nederlands) deze code hebben gestolen en gebruikt in de malware?

Hoe leer ik hier meer over? Ik wil weten wie zijn de threatactoren bijvoorbeeld in het Westen de NSA CIA enzovoortz in het Oosten de CCP, Rusland, Iraan, Turkije enzovoortz.

Kan iemand laten zien in een overzichtje wie wat doet onder water / in de oceaan van het internet zowel offline als online?

BVD (Bij voorbaat dank!)

Het oude Sovjet systeem kun je van alles aanwrijven, maar hun technische opleidingen waren puik te noemen, vaak nog met surplus. Net als onze opleidingen van voor de Mammoetwet.
Tegenwoordig speelt criminaliteit een rol overal en de interesse van de grote investeringsmaatschappijen kent letterlijk geen grenzen.
Russian Business Netwerk zit ook in Groot Mokum, maar ook bij de kleine hostertjes in het donkere zuidendes lands (achter Eindhoven) Via zit in Frankfurt, Krakau, Belgrado etc. Interpol bij alle AV binnen en Google overal op elk netwerk. Zoek het nu maar uit.
#sockpuppet

Dank je!
Heb maar een nieuw bug report geplaatst:
https://bugzilla.mozilla.org/show_bug.cgi?id=1728073

Ik hoop dat het geen domme fout van mij is, die dit probleem veroorzaakt, haha.