Ik denk dat je iets niet begrepen hebt: het feit dat een stuk software gesigned is door een bepaald bedrijf zegt NIETS
maar dan ook helemaal NIETS over de goedaardigheid/kwaadaardigheid van dat stuk software. Het zegt alleen maar
dat het ondertekend is als gemaakt door dat bedrijf. Er is voor Thawte geen enkele reden om dit certificaat in te trekken
als het aan dat bedrijf verstrekt is en dat bedrijf dit vervolgens gebruikt om malware mee te signen. Dat is gewoon een
geldig gebruik van certificaten.
Het zou kunnen dat de sleutel publiek geworden is of de build server gekraakt, maar dan is het aan "Media Lid" om
hun certificaat in te laten trekken, niet aan Symantec of andere AV boeren en al helemaal niet aan jou.
Als iedereen zomaar anders certificaten kan laten intrekken omdat het volgens iemand anders gebruikt is om malware
te ondertekenen dan is het eind zoek, want wat nou precies malware is en wat niet dat is natuurlijk een glijdende schaal.
Straks gaan mensen Microsoft's certificaten intrekken omdat ze vinden dat Windows malware is.

Dit is wel een belangrijk detail wat nogal eens over het hoofd wordt gezien. Een signatuur betekent precies dat iemand in het bezit was van een bepaalde private sleutel en daarmee een signatuur gezet heeft. Niets minder, maar ook niets meer.

Vandaar dus dat "gesigneerde code" vooral met controle, en weinig met veiligheid van de code zelf van doen heeft. Dat betekent dus ook dat "gesigneerde drivers", "gesigneerde boot", of wat er verder zoal gesigneerd moet zijn, alweer vooral over controle gaat. De belangrijke vraag is altijd, "wie heeft de sleutel?"

Dit is dus nog voordat we het hebben over kraakbaarheid, hash collisions, en andere subversieve truukerij. Zelfs perfect gebruikte cryptografische signaturen hebben een hele beperkte betekenis, en daar moet je je niet op verkijken.

Dat klopt maar dat schrijf ik nergens. Integendeel, ik heb er vaak genoeg tegen geageerd dat Microsoft voor jou vindt dat als een ActiveX object signed is, je deze "dus" kunt vertrouwen. Zelfs in de laatste W10 (Creators Update) zijn dit de default security instellingen onder "Internet Settings":
- Download signed AciveX controls: Prompt (recommended)
- Download unsigned AciveX controls: Disable (recommended)
Alsof signed betrouwbaarder is dan unsigned...

Ik denk dat je iets niet begrepen hebt, uit [1]:

Als CSP's certificaten, die duidelijk worden misbruikt, niet ASAP intrekken, krijgen ze ruzie met het CABforum en de partijen die rootcertificaten uitleveren. En terecht.

Maar primair ging het mij helemaal niet om het intrekken van certificaten, maar om het feit dat AV boeren simpelweg op basis van een (hash van een) certificaat + timestamp software eenvoudig als malware kunnen classificeren (signature based dus) en dat overduidelijk nalaten.

[1] https://www.thawte.com/assets/documents/repository/cps/Thawte_CPS_3_7.17.pdf

De AV detectie mag dan werken via andere wegen, er is wel degelijk iets goed mis met de certificering, er wordt namelijk geen SSL certificaat gevonden. Waarom stootte onlangs Symantec haar certiceringspoot af door hem door te verkopen, een soort "pass the bucket" beleid wellicht en dus geldt waar rook is, is meestal ook vuur.

Bij Comodo wordt het voorlopig niet ontdekt: https://app.webinspector.com/public/reports/74268097

En het gebeurt weer op het non-public net, bij Tencent Cloud Computing: http://toolbar.netcraft.com/site_report?url=moviessupper.men%2Fsupport.php%3Ff%3D1.dat met een 9 rood uit 10 op de Netcraft risico-schaal.

Vreemde naamserver configuratie met software versies zichtbaar: 1.0.1104.00 met een arbitraire file upload kwetsbaarheid en dat hebben we hier al vastgesteld voor (1.dat): https://www.virustotal.com/en/file/0a6c754a28566a1bb7158729279f1c178d27bebc026fc45e1c7f235aaadfb83d/analysis/1501842167/

En bij het mogelijk onderzoeken van het scenario krijgt Bitwiper toch wel enigszins gelijk: https://www.slideshare.net/phdays/exploiting-redundancy-properties-of-malicious-infrastructure-for-incident-detection
Het is een kat en muis spel tussen av-vendors en malcreanten, waarbij de Chinese autoriteiten in Peking het misbruik deels in de weg zitten en deels het misbruik faciliteren.

Meer voorbeelden van DNSPOD abuse: http://www.malwareurl.com/ns_listing.php?as=AS12301

Ook moet je hierbij bedenken, dat AV oplossingen ook steeds een selectie moeten maken welke malware men wel en niet in de detectie wensen op te nemen.

Men kan nu eenmaal nooit beveiligen tegen het gehele scala, dat er aan bedreigingen bestaat
Dat is misschien ook waar je dit manco moet plaatsen en een verklaring voor een deel van wat je beweert te zien.

No one detects them all.

Waar hebben ze die eigenlijk nu weer verstopt?

Als ik in mijn PC met (Engelstalige) W10 op de start knop druk en "Internet Settings" intik, verschijnt deze.

Maar inderdaad bizar is dat veel instellingen nog steeds alleen in het Control Panel zijn te vinden, terwijl de snelkoppeling daarnaar in het rechter-muistoets-start-menu is verdwenen sinds de Creators Update.

[cynisme aan]
WAAAT? Virusscanners die niet alle malware detecteren? Er zijn er die meer halen dan 100%, wat zwets jij nou!
Uit https://www.security.nl/posting/525382/Test%3A+18+anti-viruspakketten+voor+Windows+10+vergeleken:

Uit https://www.security.nl/posting/521364/Gratis+virusscanners+bovenaan+tijdens+%27real-world%27+anti-virustest:
[cynisme uit]
Niets dan leugens door die testers (wie betaalt hen trouwens). En die meer dan 100% komt waarschijnlijk doordat MS Defender Paint tegenwoordig als PUP beschouwt...

Ik heb de malware van vanochtend nogmaals geüpload, deze wordt nu door 35 van 64 scanners herkend. Het is dus niet zo dat AV fabrikanten er geen detectie voor kunnen of willen maken, alleen doen ze dat pas op het moment dat iedereen haar of zijn mail gelezen heeft en de aanvallers allang weer nieuwe malware hebben gemaakt en verspreid, snap je? (Ik niet).

Zoals deze van tussen de middag met 13/64... https://www.virustotal.com/en/file/9e95f90c8bdd43f2ba0ec4a48ea56270d688e99d17a1b8a03a79807d2745515e/analysis/1501841439/
Momenteel 36/65, maar deze had geen digitale handtekening waar de vorige dat wel had, en daarmee juist eenvoudig te detecteren zou zijn geweest.

Overigens is het code signing certificaat van Media Lid met SHA1 van "08 15 93 99 87 9e 46 d4 64 ed 09 0e c1 05 9c 7c 30 21 9a 3a" (voor de Googelaars: AKA "08:15:93:99:87:9e:46:d4:64:ed:09:0e:c1:05:9c:7c:30:21:9a:3a" AKA "08159399879e46d464ed090ec1059c7c30219a3a") nog steeds niet ingetrokken (die hash komt nog niet voor in http://tl.symcb.com/tl.crl van 20170804 11:01:34 lokale tijd = 20170804090134Z).

Daarom heefft een virusscanner ook geen zin!
Malware moet je niet detecteren door patronen in de programma's te herkennen, maar door te herkennen dat er programma's
gedownload en uitgevoerd worden en dat dan te verbieden. Doe je het niet op die manier dan ga je vroeg of laat voor de bijl.

Helaas kijken de vier grote (Magic Quadrant) AV partijen ook of een bestand (terecht of onterecht) is gesigneerd. NotPetya was ook gesigneerd met een fake Microsoft certificaat.

Vergeet de bekende AV's en ga voor echt Next-Gen zoals bv CylanceProtect of SentinelOne. Ook Sophos InterceptX is heel effectief.

Binnen de Enterprise tests in mijn lab met onbekende samples komen Cylance, SentinelOne en InterceptX het beste uit de test, waarvan Cylance het meest effectief is. Cylance was de enige die de onbekende Powershell ransomware samples zonder payload wist stoppen.

@00:22 door SecGuru_OTX

Wat is daar mis mee? Het is prima te controleren of er een valse signatuur is. De kwestie is eerder hoe je omgaat met self-signed en de grijze gebieden van niet algemeen geaccepteerde of niet betrouwbare CA's en hoe je resultaten cached.

Verkijk je niet op Gartner methodologie, hun "magic quadrant" is niet zaligmakend. Gebruik je eigen programma van eisen. Ik vermoed dat je het daar wel mee eens bent gezien je voorkeur in jouw eigen tests.

@10:57 door Anoniem
Wat je met certificaten doet op het gebied van bescherming is aan de gebruiker, er is in een vrij land niemand die kan afdwingen dat je een bepaalde CA 100% vertrouwd.

Excuses, ik had het iets anders moeten formuleren. Ik bedoel: helaas zijn er een aantal van deze grote AV partijen die het bestand automatisch vertrouwen wanneer hij is gesigneerd, ongeacht het gedrag van het bestand.

We zitten dus op 1 lijn ;-)

Detectie nu 38/62 https://www.virustotal.com/en/file/320008650befd4d89bae59eb57029064b7695e2ad56278ef583b61d9b8d0438d/analysis/1501947229/

Certificaat is nog niet ingetrokken.

Dat je een virus of malware o.i.d. oploopt komt zo sporadisch voor, daar zou ik mijn kaarten niet op inzetten.
Want vaak staat er bij AV-scanners (iets van) je privacy op de tocht, ze werken in de praktijk niet 100% ondanks de theoretisch mooie cijfertjes, laten bij https het originele certificaat niet zien, en vergroten het aanvalsoppervlak voor hackers. En dan nog de onnodige schrik en wantrouwen en extra werk bij false positives. Bijvoorbeeld een doodnormale afbeelding waar heel toevallig een verdachte byte-reeks in voorkomt, omdat de kleurtinten voorgesteld door die verdachte bytereeks in het plaatje nu eenmaal zo zijn.

Ik zou liever inzetten op een robuust systeem dat niet gemakkelijk is te besmetten, en goede backups die gemakkelijk en snel zijn terug te zetten. Die heb je toch al nodig zonder een RAID redundantie, i.v.m. risico op plotselinge diskcrash.
En verder misschien nog een Firewall erbij om ter plekke abnormaal netwerkverkeer niet toe te staan.
Ten slotte kun je soms een vertrouwde offline virusscanner toepassen als je iets echt niet vertrouwt.
Die zendt tenminste geen data over je systeem en bestanden terug naar de AV-makers.

O ja, en last but not least: zorg dat firmware en instellingen van je router up-to date resp. in orde zijn en niet meer toestaan dan nodig plus een sterk administratorwachtwoord voor de router instellen.

Helaas correct weergegeven! Maar waar dit toe leidt merkte ik eind juli op. Via het "Chinese" kanaal kwam ik achter het bestaan van z.g. Overheidsspyware uit China met de bedoeling bepaalde groepen in de samenleving te controleren. Je zou zeggen dat de AV-bedrijven hier meteen opspringen, omdat in het verleden gezegd werd dat Overheidsspyware genadeloos aan hun detectielijst zou worden toegevoegd. Dus nu konden we de woorden die uitgeproken waren eens testen hoeveel die waard waren. Maar wat blijkt? Tot op de dag van vandaag detecteert geen enkele virusscanner deze Chinese Overheidsspyware. Het enige wat een Android bezitter nog kan doen als hij of zij Google Play Protect aanzet. Die monitort het gedrag van de applicaties. Alleen F-Secure reageerde op mijn verzoek tot onderzoek. Kaspersky heeft niets meer van zich laten horen na een eerste e-mail de sample ontvangen te hebben. Van de AV-bedrijven hoef ik niet veel meer te verwachten.

https://www.hybrid-analysis.com/sample/306ccab13ca5ba76c9213169599c549a432c97e7332b87db8ed5afb32d0d7749?environmentId=200
https://virustotal.com/en/file/306ccab13ca5ba76c9213169599c549a432c97e7332b87db8ed5afb32d0d7749/analysis/

https://bof.nl/2017/07/28/de-week-van-verplichte-spyware-el-paquete-semanal-en-next-level-wachtwoorden/#comments

Waarschijnlijk dat Verizon ook 'meewerkt' om geen alert af te geven voor deze staatsspyware, zie https://www.scumware.org/report/173.76.170.69.html

Het thuisfront in mainland China doet het wat dat betreft beter: https://www.maldun.com/analysis/YXNkZmRzZmFkc2YxMDQ3NzJkc2Zhc2RmYXNkZg==/

Dit sterkt mij in het vermoeden dat het westerse surveillance spyware betreft, die men in mainland China uittest.
Ik heb sterk het idee dat China en de USA (zeker Silicon Valley bedrijven) al "hand in foot" samenwerken bij dit testbed.

Interessante additionele info hier: https://virustotal.com/en/file/306ccab13ca5ba76c9213169599c549a432c97e7332b87db8ed5afb32d0d7749/analysis/#item-detail

Officieel geeft men toe dat het adware betreft, maar dan 1 met duidelijke bedoelingen: http://www.avgthreatlabs.com/en-ww/android-app-reports/app/com.example.dzsjga met een piek detectie tussn 15 en 19 juli j.l.

Anoniem van 16:41 legt een vinger direct op de zere plek.

Dit is ook interessant, waar het scanresultaat een lege file opleveren, gezien de hash d41d8cd98f00b204e9800998ecf8427e
voor een "empty string". Zie: https://zulu.zscaler.com/submission/169839eb-c278-4cda-a21c-1b0d480cbf93
Maakt contact met een site met AV: HEUR:Trojan.Script.Agent.gen: zie het gedecodeerde resultaat: http://ddecode.com/hexdecoder/?results=fe990f41c464d6bf903612f7bc91de99 (een powershell bypass) -> https://virustotalcloud.appspot.com/ko/user/PayloadSecurity/ misbruik op server.

Detectie nu 46/63 https://www.virustotal.com/en/file/320008650befd4d89bae59eb57029064b7695e2ad56278ef583b61d9b8d0438d/analysis/1502130023/

Certificaat is nog steeds niet ingetrokken, maar ook vandaag nog (om 06:36:01) gebruikt om malware mee te signeren - zie "20170807043601Z" in https://www.hybrid-analysis.com/sample/76282e7506de8f2d97eaa0957873ac55741768783b6062e07de952eeeddfbb73?environmentId=100.

Correctie 20:39: een file gedownload vanaf de URL (hxxp://foolerpolwer.info/admin.php?f=3) genoemd in de hybrid-analysis pagina is ondertussen alweer een andere, die niet digitaal ondertekend is. Die laatste file doet nu 10/64, zie https://www.virustotal.com/en/file/3f172b181e579b4d7d4cb8f2b55c7424d1e7a85eb649f4845625a2a58962ec46/analysis/1502130786/

Aanvulling 21:14: het "Media Lid" certificaat (de bijbehorende private key om precies te zijn) werd al eerder gebruikt om malware te signeren dan ik bovenaan schreef, namelijk sinds "20170731182559Z", dus 2017-07-31 20:25:59 lokale NL tijd. Zie https://www.hybrid-analysis.com/sample/b269b77b38e3fee6e445b04ef8ac9294a6062dc42dcbaf015d134abef308b5ef?environmentId=100. Voor de mensen die twijfelen of het hierbij om malware gaat, zie vanaf de tekst "All your files have been encrypted!" en "Decryption of your files with the help of third parties may cause increased price (they add their fee to our) or you can become a victim of a scam" in laatstgenoemde pagina.

Rode draad in het verhaal: stap af van oude traditionele AV oplossingen en ga voor echte Next-Gen /ML oplossingen zoals:
InterceptX(straks ook met Invencea), SentinelOne, Cylance, Crowdstrike, Traps, etc.

Hmm in HA (High Availability) omgevingen zijn die ML (Machine Learning) scanners nogal scary, want tenzij je een 100% op de echte situatie lijkende test setup hebt, kunt je niet meer betrouwbaar vooraf testen voordat je updates en/of signatures in productie neemt.

En als ik naar de hierboven door mij genoemde Virustotal pagina's kijk (een statistisch zinloos klein aantal, maar toch), zie ik Cylance het nu nog goed doen, maar in de VT URL in mijn laatste post (met 46/63) zien bijv. SentinelOne (Static ML), Sophos ML en CrowdStrike Falcon (ML) er geen kwaad in.

En v.w.b. CrowdStrike Falcon (ML) is dat bizar, want die stond (voor dezelfde binary eind vorige week!) wel bij de eerste 10 met "malicious_confidence_90% (D)" en ziet er nu geen kwaad meer in - kennelijk met dezelfde definities van 20170710 - zou dat "dankzij" learning zijn, of is VirusTotal ongeschikt voor het beoordelen van ML scanners (wellicht omdat de scanner zoveel malware ziet dat deze het "normaal" gaat vinden)?

Hoe dan ook, hoe groter de afzetmarkt voor antimalwareproduct, hoe beter de cybercrims hun best doen om evasion in die producten te bewerkstelligen.

In bijv. https://blog.fortinet.com/2017/08/05/analysis-of-new-globeimposter-ransomware-variant zie je dat deze GlobeImposter malware eerst een suspended child proces in het geheugen aanmaakt en vervolgens de kwaadaardige payload decrypt direct naar stuk geheugen en dat vervolgens opstart.

Omdat het qua performance onmogelijk is om voortdurend geheugen te scannen (en bovendien, op welke plaats precies wil je waar naar zoeken) is het - als je niet wilt wachten op signature based detection - noodzakelijk om de malware in een sandbox uit te voeren en te monitoren. Maar ook dat kost performance (wachttijd bij opstarten van programma's) en cybercriminelen weten dat (en bovendien weten ze binnen de kortste keren na wijzigingen door AV-boeren, hun sandboxes te herkennen en zich dan poeslief te gedragen).

Ten slotte kun je natuurlijk gewoon met ML gadeslaan wat de gebruiker doet, en alles wat exceptioneel is de nek omdraaien, maar ik moet nog zien dat dit niet tot veel false positives en/of gedeeltelijke schade leidt.

Wat Anoniem 04-08-2017 22:13 schrijft: is inderdaad een deel van de oplossing (en wellicht bijna volledig als je PDF en Office files en browser/flash/java exploits ook programma's noemt), ware het niet dat ik hier geen betrouwbare maar tevens werkbare oplossing voor ken onder Windows. Maar wellicht is dat mijn onwetendheid...

Eens, er is idd nog veel meer.

In een HA omgeving zou je de hash van je HA software nog kunnen white-listen. Is ook weer een risico maar dat is een afweging die je zelf kunt/moet maken. Ik heb overigens ook veel false-positives in systeemkritische exe, dll,etc gezien

Ik ben overigens een voorstander van white-listen, alles dicht tenzij(ook scripts).

Ik vind daarom de methode van het draaien van Voodoo Shield bij voorbeeld een goede aanpak.
Zelfs als ik met Resource Hacker 1 luttel mini icoontje binnen het programmaatje aangepast hebt, (2 bytes groot).
stopt en blokkeert het het programma dat ik eerder had vrijgegeven, tot ik besluit het gewijzigde programma toe te laten.

Zo draai ik steeds compleet door mijzelf gewhiteliste uitvoerbare bestanden.
Ik ben ik niet meer of veel minder afhankelijk van de traditionele AV en kan met bijvoorbeeld windows defender toe,
al of niet in een zandbak ( de nieuwe via github uit aan het proberen).

Bij traditionele AV daarbij ben ik afhankelijk van hun toevoegingen van singatures en eventuele FP's.
En het blijft steeds dweilen achteraf, dus vaak enkele dagen na een 0-day uitbraak.

Worden systeemafhankelijke executables valselijk 'gevlagd' ben je helemaal in de aap gelogeerd en krijg je OS problemen.
Elke AV oplossing is dit al wel eens gebeurd en in zo'n geval danken de gebruikers onze lieve heer op hun blote knietjes dat ze zo'n update hebben overgeslagen.

Het oude model voldoet dus steeds minder aan de verwachtingen en het cybercrime circus past zich aan na detectie,
is volgzaam en gedwee en pakt de tent op en verhuist naar elders om dezelfde activiteiten voor te zetten.
Dat schiet dus voor geen meter op. Goed voor cybercrime & Co. en goed voor AV. Een wederzijds perpeteum mobile.

Trouwens dan hebben we ook nog het mono-cultuur probleem, waar een AV programma heel veel gebruikers kent, kan de malcreant beter onder de detectieradar komen/blijven en een cybercrimineel schijt nooit in de eigen achtertuin, dus weinig Russische ransomeware in Rusland zelf bij voorbeeld (vanwege de verhoogde pakkans).

AV een wereldje apart...

luntrus

Lees je eerst maar eens in over het misbruik van de "magische" term Machine Learning: https://www.welivesecurity.com/2017/04/11/fighting-post-truth-reality-cybersecurity/
Dit wordt al jaren gebruikt in de "traditionele" AV industrie maar wordt vooral hard geroepen door nieuwe startups die claimen een onmogelijke oplossing te hebben.

Wellicht dat AV boeren geen certificaten intrekken, omdat ze geen certificate authority zijn, en helemaal geen certificaten kunnen intrekken.


Really ? Heb je met 64 verschillende virus scanners dit handmatig uitgeprobeerd ? Of heb je Virustotal gebruikt, en ga je volstrekt voorbij aan het feit dat dit uitgeklede versies zijn van de AV software, waarbij zaken als heuristics niet beschikbaar zijn.

Wat dat betreft is VirusTotal *niet* geschikt als tool om te testen hoe goed Antivirus pakketten zijn. Alle technieken, buiten statische signatures, worden in VT niet gebruikt.

Ik lees helemaal niets, en al helemaal geen marketing flyers.

Ik baseer dit op basis van mijn eigen testen in mijn lab met meerdere oplossingen.

Want ieder programma wat wordt gedownload (of iedere patch) is malicious ? Beetje nutteloos, om alles wat wordt gedownload per definitie te willen verbieden. Gaat een beheerder een patch of een drivers downloaden, welke nodig is op een systeem, dan zeg jij 'foei, dat mag niet' ?

Als jij een firewall installeert, bevat deze dan ook enkel een rule ''deny ip any any'' ? Wel zo veilig, want dan weet je dat *ook* kwaadaardig verkeer wordt geblokkeerd ? ;))

Ook ik ben geen certificate authority maar dat is irrelevant, want volgens de CPS van Thawte zou iedereen certificaten moeten kunnen intrekken (naast hun nog net wel/net niet meer baas Symantec, ook elke andere AV boer). Lees eerst eens een hele thread voordat je met mosterd na de maaltijd komt?

Heuristics zijn een waardeloze folderfabel omdat:
1) Cybercriminelen net zo lang aan hun untargeted malware prutsen tot ze welke feature dan ook van de meestverkochte virusscanners weten te bypassen, of "enigmalware maken
2) En voor die gevallen waarbij dat niet (helemaal) lukt, zou ik er veiligheidshalve maar vanuit gaan dat je systeem gecompromitteerd is op het moment dat je virusscanner alarm slaat. En veel succes met de false positives die heuristics kunnen genereren.

Los daarvan zijn on-demand scanners (ook die VirusTotal gebruikt) vaak krachtiger dan hun on-access varianten omdat ze veel meer tijd aan het scannen kunnen besteden.

AV boeren willen niet dat VirusTotal als maatstaf wordt gebruikt, en VT gaat mee in dat advies. Maar mijn ervaring is dat VT een prima indicatie geeft van signature-based detectie, en dat is het enige dat betrouwbaar werkt (maar meestal veel te laat).

Bovendien, als heuristics zo briljant zouden zijn, leg jij mij dan eens uit waarom, na een paar dagen, de meerderheid van de antivirusboeren hun stinkende best heeft gedaan om hun al veel te grote signature databases uit te breiden en te syncen naar eindgebruikers over de hele wereld zodat deze specifieke malware voortaan wel wordt herkend...

De file die ik gisteravond (zie [1]) heb gedownload vanaf hxxp://foolerpolwer.info/admin.php?f=3 haalde gisteravond 10/64 (zie [2]) maar nu 46/64 (zie [3]).

Maar reken je niet rijk, want de file gedownload van hxxp://foolerpolwer.info/admin.php?f=3 is ondertussen weer veranderd. Deze is weer signed met het Media Lid certificaat (dat nog steeds niet is ingetrokken). De file was 47 minuten geleden al door iemand anders geüpload, en haalde toen 8/64 (detectie door Avast, AVG, CrowdStrike Falcon (ML), DrWeb, Emisoft, EndGame, Palo Alto Networks (Known Signatures) en Tencent). Actuele score nog onveranderd 8/64, zie [4].

[1] https://www.security.nl/posting/526658/Falen+van+AV+industrie#posting526989
[2] https://www.virustotal.com/en/file/3f172b181e579b4d7d4cb8f2b55c7424d1e7a85eb649f4845625a2a58962ec46/analysis/1502130786/
[3] https://www.virustotal.com/en/file/3f172b181e579b4d7d4cb8f2b55c7424d1e7a85eb649f4845625a2a58962ec46/analysis/1502221870/
[4] https://www.virustotal.com/en/file/5e16067461b8ce060a44fb8f4d1cd3f249b224107775e9c28c1ec270804cfd06/analysis/1502222631/

PHISHERs ontspringen ook vaak de detectiedans, een Google Safebrowsing detectie vaak dan daargelaten.
Kijken we eens naar het volgende voorbeeld, waar ook weer de certificering veel verraadt.

PHISHING uri = hxtp://vendercartaobom.com.br/indicador/r -> uitgevoerde evals 3 : https://urlquery.net/report/88cd8e35-f1b8-41cf-a454-94e9eff23854 100/100% kwaadaardig, draait op nginx/1.12.1

De hostnaam komt niet overeen met het certficaat (voor prodns.com.br ),
dus niet correct geïnstalleerd, revocatiemethode OCSP, maar OCSP stapling niet ingesteld.
Hostgator wildcard, Commodo cert. staat op interne servers: https://certificate.revocationcheck.com/vendercartaobom.com.br (cache header fout en content-type fout)

Kijk eens hier voor issues: http://www.domxssscanner.com/scan?url=http%3A%2F%2Fvendercartaobom.com.br%2Findicador%2F

jQuery bibliotheken die eruit moeten: http://vendercartaobom.com.br/indicador
Detected libraries:
jquery - 1.11.0 : (active1) http://ajax.googleapis.com/ajax/libs/jquery/1.11.0/jquery.min.js
Info: Severity: medium
https://github.com/jquery/jquery/issues/2432
http://blog.jquery.com/2016/01/08/jquery-2-2-and-1-12-released/
bootstrap - 3.2.0 : http://www.vendercartaobom.com.br/js/bootstrap.min.js
Info: Severity: medium
https://github.com/twbs/bootstrap/issues/20184
jPlayer - 2.7.0 : (active1) http://www.vendercartaobom.com.br/js/jplayer/jquery.jplayer.min.js
(active) - the library was also found to be active by running code
2 vulnerable libraries detected

En bijkomende sri-hashes niet gegenereerd (same-origin) - 66 issues: https://sritest.io/#report/2a50d92e-6416-4239-883d-36f5de2e78ed

En hier, hallo A status, maar de naamserver versies worden wel bekend gegeven: 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6_8.3
(nog kwetsbaar voor DROWn! Zie: https://www.dnsinspect.com/vendercartaobom.com.br/10173262

Man, man, man, kan de AV industrie zulke domeinen niet markeren en welke goochelaars houden de bordjes bij deze website in de lucht? (zucht...) en alles zo te zien via "cold reconnaissance third party scanning" zonder de site in kwestie zelfs te hoeven bezoeken.

luntrus

Check, ik ga gelijk testen(zonder signature updates)

ik krijg een site not found

Dat is dan nog maar net. IP adres en alternatieve hostnames in https://www.virustotal.com/en/ip-address/91.214.114.215/information/

De meeste responses op dat IP voor diverse domeinen gaan nu naar 0.0.0. zoals een verzoek voor GET /3 HTTP/1.1
Host: grooveterrace.win Ze staan ook bij Fortinet's geblacklist.
Wat daar was (want malware draait soms niet al te lang, hier een paar die meer dan 92 uur! overdue zijn): https://malwr.com/analysis/ZmRlOGJmNWFlYjZjNDE5Yzk5ZGQ1YzU0ZjRmZmM2OGU/
Allemaal spamvertised en trackback detecties: http://support.clean-mx.de/clean-mx/portals.php?descr=europlanet%20network53%20Irene%20Pefki&sort=url%20ASC&response=alive

Domeinen zijn geblacklist by SURBL Multi.

Thawte heeft mij woensdagochtend om 00:42 (NL tijd) gemaild. Ik heb die mail beantwoord en met klem gevraagd om het certificaat in te trekken omdat het nog steeds in malware wordt misbruikt.

Daarna heeft Thawte het certificaat van "Media Lid" met SHA1 hash ?08159399879e46d464ed090ec1059c7c30219a3a (08:15:93:99:87:9e:46:d4:64:ed:09:0e:c1:05:9c:7c:30:21:9a:3a) en serienummer ?200b8eadff8610c8a288e874ea157f9f (of, met spaties "?20 0b 8e ad ff 86 10 c8 a2 88 e8 74 ea 15 7f 9f") ingetrokken.

Helaas met als Revocation date: "Thursday, 10 August, 2017 00:00:00" - dus niet met terugwerkende kracht tot het moment van het signeren van de eerst bekende malware. Daardoor zullen digitale handtekeningen gezet vóór vandaag niet als ongeldig worden bestempeld, en blijft het risico bestaan dat afgelopen week gesigneerde malware erdoor slipt.

Los daarvan is de update frequentie van http://tl.symcb.com/tl.crl 14 dagen. Als jouw PC gisteren die CRL heeft gedownload, zal de eerstvolgende keer niet eerder dan over 13 dagen zijn - tot die tijd vertrouwt jouw PC erop dat de CRL op jouw PC nog wel geldig zal zijn en zal geen nieuwere versie downloaden.

Echt een briljant systeem, certificate revovcation (not).

Dit kan allemaal niet gebeuren als er geen gestolen code-signeer certificaten waren,
waarmee bijvoorbeeld malware java applets konden worden gesigneerd.

Dit is destijds gebeurd bij Opera en Adobe o.a.

Certificaten die verkocht worden aan niet bestaande entiteiten. Zo kunnen kwaadaardige uitvoerbare bestanden worden gecertificeerd. Of er wordt gebruik gemaakt van andere vertrouwde certificaten, maar niet voor zulke instanties. Nokia, GMail, MiM aanvallen.

BHO's die een nep Verisign certificaat installeert als Trusted Root Certificate Authority.

Het PKI systeem werkt dus onvoldoende.
Als authenticatie servers niet voldoende worden geupdate, ga je al de bietenbrug op.
Daarnaast zijn er nog aanvallen op CA, denk aan het DigiNotar debacle.

Dit is ook een leukertje. Nog niet gesignaleerd door AV. Suricata IDS geeft een waarschuwing voor DNS Unsolicited Respons- Internal IP: https://urlquery.net/report/64f8cd13-0f1b-40e0-81b3-d4de7dee25e7
Waar gevonden, de link zat hier: https://www.dnsinspect.com/shaunafogal.com/10175279

Reverse DNS ns528515.ip-142-4-215.net ; iad23s43-in-f10.1e100.net ; iad23s59-in-f10.1e100.net ; xx-fbcdn-shv-01-iad3.fbcdn.net ....en geen geen reversed DNS voor http://api-idx.diversesolutions.com/combo-css?config=dsidxpress-pro
IP is geblokkeerd voor mij vanwege success.marketleader.com tracking uit Seattle...-> https://asafaweb.com/Scan?Url=api-idx.diversesolutions.com

We zien we bij de certificaatcheck o.a. "We can't download CRLs from internal servers".

Alles op een slecht geconfigureerde oude versie Word Press website met oude plug-in versies, kwetsbare jQuery bibliotheken 3, en SRI hahes niet gegenereerd (4 issues).

Nog meer ellende: https://observatory.mozilla.org/analyze.html?host=shaunafogal.com

Er gebeurt dus van alles achter de rug om van de client (browser) op het non-publieke Internet met name door api's als de genoemde: api-idx.diversesolutions.com/combo-css?config=dsidxpress-pro

Als de bezems er niet eens goed doorheen gaat, blijft het dweilen met de kraan open, naar mijn bescheiden mening,

luntrus

Het is nog erger gesteld met revocation dan ik dacht. In de file http://tl.symcb.com/tl.crl van gisteren en van vandaag staat het serienummer van het ingetrokken certificaat: "20 0b 8e ad ff 86 10 c8 a2 88 e8 74 ea 15 7f 9f", dus ging ik er gisteren (zonder te testen) vanuit dat dit wel goed zou zitten. Niet dus...

Als ik die CRL file in Windows inlees (klik met rechter muistoets en dan "Install CRL" doe), dan wordt een file die eerder automatisch door Windows is gedownload (met dat serienummer er nog niet in) op mijn PC overschreven (deze gegevens staan overigens in het register).

Echter, revocation werkt geheel niet - noch in Windows 7, noch in Windows 10 (Creators Update). Dat die CRL succesvol is ingelezen, blijkt overduidelijk uit dit plaatje gebaseerd op de CRL van gisteren: https://imgur.com/a/jG3sz, en, met de CRL van vandaag: https://imgur.com/a/UUxVP. Nb. de regel boven "E. Revocation status..." bevat de SHA1 hash van de binaire (ASM.1) bestandsvariant van dit certificaat (08159399879E46D464ED090EC1059C7C30219A3A).

Ik heb Microsoft en Thawte een mail gestuurd met deze informatie, ik ben benieuwd wat hier nu weer aan de hand is.

Los van revocation, detectie van de file "1.dat" genoemd bovenaan deze pagina is ondertussen 49/62 (https://www.virustotal.com/en/file/320008650befd4d89bae59eb57029064b7695e2ad56278ef583b61d9b8d0438d/analysis/1502444940/). In de tab "File detail", als je achter "Signers" de regel "Media lid" openklapt, zie je bovenstaande hash en serienummer van het certificaat ook - en daar staat nu ook bij: "Trust for this certificate or one of the certificates in the certificate chain has been revoked". Alleen jammer dat dit niet werkt onder Windows...

Edit 15:15: imgur URL's http -> https

@ Bitwiper, lees eens hier: https://news.netcraft.com/archives/2013/05/13/how-certificate-revocation-doesnt-work-in-practice.html je bent helemaal afhankelijk van hoe CryptoAPI werkt in Windhoos.

Dit is ook belangrijk

AV heeft hier zelf dik aan meegewerkt met haar https scanning, zodat wanneer een certificaat ingetrokken wordt vanwege frauduleus gebruik of gecompromitteerde private sleutels een AV product, zoals in het geval van Bitdefender destijds, Bitdefender toch het accepteerde als geldig certificaat.

Bij Bitdefender liepen ze gewoon over zulke zaken heen: "“As the attack vector is quite small and difficult for an attacker to target, we did not consider it as a high priority update,” said Alexandru Catalin Cosoi, Bitdefender’s chief security strategist and global communications director, in an emailed statement. “We will scan the [HTTPS] traffic anyway for malicious payloads, which still renders our customers safe.” Zij maken dus de dienst uit met hun eTags.

Niet erg hoopgevend natuurlijk voor degenen, die van revocation op een goede manier afhankelijk zijn voor hun "security". NSA gniffelt natuurlijk om zulke "sloppiness".

Hier kun je even checken of browsers of andere software bij je wel of niet de fout ingaan: https://revoked.grc.com
Denk aan Heartbleed, DigiNotar, Lenovo, en vele andere incidenten. etc. etc.

Het gaat hier om een code-signing certificaat en dan heb je niet in alle gevallen wat aan OCSP, bijv. als je PC aan het opstarten is; voor (UEFI) drivers ben je dus sowieso afhankelijk van CRL's. Linksom of rechtsom horen CRL's gewoon te werken, en dat is, in elk geval voor dit specifieke certificaat, niet het geval.

Aanvulling 13 aug. 11:50: maar dank voor de link! Ik heb het artikel, dat ik niet kende, gelezen. Inderdaad werkt revocation - in elk geval voor websites (en zeker in Chrome!) voor geen meter. Echter signed files vormen tegenwoordig de basis voor een "trustworthy" Windows (UEFI, signed drivers etc). Als revocation daar niet goed bij werkt, stel ik voor dat we meteen ophouden met al die toestanden die het installeren van een ander OS of een wat oudere driver vaak enorm bemoeilijken.

Overigens probeert Windows, direct na opstarten, uit zichzelf een stel CRL's te downloaden. Dat gebeurt totaal stompzinnig, zoals vanochtend op mijn W10 PC als volgt:
met als antwoord:
waar Windows kennelijk tevreden mee is. Zo'n antwoord kan een MitM natuurlijk wel HEEL eenvoudig spoofen.

"Grappig" ook is dat als je http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/disallowedcertstl.cab?443939db7907c66e downloadt, de file "disallowedcert.stl" daarin uitpakt en via de bestandseigenschappen naar de signing certificaten kijkt, het volgende ziet:
- Bij het SHA-1 certificaat: "The certificate is not valid for the requested usage."
- Bij het SHA256 certtificaat: "No signature was present in the subject".

Oh ja, en als je in W10 die "disallowedcert.stl" file opent, start 3D Builder met error code ox8000405. Briljant systeem dat Windows...

Eens.

Aan degenen, die bijdragen aan deze machtig interessante en verhelderende draad.
Een echt TOP Topic. Bedankt voor dit alles en de "heads-up", beste Bitwiper.
Onderwerp trok gelijk anderhalf duizend views. Men schijnt wakker geschud, maar is dit voldoende?

Op de achtergrond van dit alles speelt natuurlijk ook nog eens de Google versus Symantec certificeringscontroverse.

Net had ik hierboven dit check adres gegeven of bij nader inzien bleek er voor dit adres te worden gewaarschuwd door Google Safebrowsing en was het certificaat ge-revoked....

Een achtergrond verhaal hierover van Gibson: https://www.grc.com/sn/sn-453.htm

Na een Microsoft update vandaag kon ik de scanpagina echter weer normaal benaderen: https://www.grc.com/revocation.htm

Ik zou graag van Bitwiper ook wat achtergrond overwegingen horen, want het geheel verontrust mij toch wel en vooral het gemak waarmee men met deze materie wenst om te gaan. En de tijd dat we ons verhaaltjes op de mouw laten spelden is wel voorbij onderhand, niet?

luntrus

De test site heeft een certificaat dat is ingetrokken. Dan nog een fijne tool hier: https://github.com/agl/crlset-tools om uit de voeten te kunnen met Chrome's CRLSets.

Dit hielp ook niet echt: https://www.itnews.com.au/news/digital-certificate-use-by-phishing-sites-spikes-458183

Zoals we hier al hebben gemerkt, bestaan er vele problemen rond het huidige PKI model
en is het tijd voor iets anders/nieuwe wegen?

Dan blijft de vraag of deze nieuwe mechanismen de problemen werkelijk zullen oplossen
of alleen de zaak maar ingewikkelder maken?

Dit vanwege de mate waarin certificering al is gehackt, gecompromitteerd, verzwakt en pn*wed i.h.a..

Het zal eerder nieuwe wegen openen voor DoS aanvallen, het gehele PKI model ingewikkelder maken
en nog meer certificaat autoriteiten online laten verschijnen, waardoor de code-brei nog ingewikkelder wordt
en te verwachten valt dat dat dan eerder aanvallers in de kaart zal spelen.

Het is niet de AV industrie die hier faalt. Het zijn de certificatenboeren.

Niet de uitleg-pagina https://www.grc.com/revocation.htm moet een foutmelding opleveren, maar https://revoked.grc.com/. Die laatste pagina geeft een (terechte) certificaatfoutmelding in alle webbrowsers die ik heb geprobeerd. Heb je zelf daadwerkelijk laatstgenoemde pagina geprobeerd?

LET OP: Het is niet zo dat ik claim revocation in Windows helemaal niet werkt!

Het werkt, voor zover ik weet, alleen niet in het geval van een specifiek Thawte code-signing certificaat in combinatie met een Thawte revocation bestand (CRL file). En het lijkt echt een Windows probleem te zijn, want als je naar https://www.virustotal.com/en/file/320008650befd4d89bae59eb57029064b7695e2ad56278ef583b61d9b8d0438d/analysis/ gaat, het tabblad "File Detail" opent, en achter "Signers" op het plusje voor "Media Lid" klikt, zul je zien staan:

Beide falen. Dezelfde groep cybercriminelen verspreidt vooral unsigned malware. Hun kracht is variatie, dat is waar de AV industrie slechts een reactief antwoord op biedt - en dat is in de meeste gevallen te laat.

In deze thread lopen 2 zaken door elkaar, wellicht had ik moeten spiltsen in 2 maar nu is het nou eenmaal zo.

Overigens heb ik een antwoord gekregen van secure bij micosoft. com: zij zien het niet-werken-van-certificate-revovation niet als een security issue, maar als een gewone bug in Windows of een issue bij Thawte. Ik heb onder meer het volgende geschreven als antwoord:
Want zelfs als je jouw PC goed hebt dichtgetimmerd ben je, met een Windows PC, vermoedelijk kansloos als je in een situatie zoals deze: https://www.security.nl/posting/527508/Wifi-netwerken+in+Europese+hotels+doelwit+van+aanvallers. Als je in zo'n situatie (of een pwned thuisrouter met aangepaste DNS server instellingen) een gemanipuleerd Windows update bestand krijgt opgedrongen (of een update voor willekeurig welke andere software op je PC), digitaal gesigneerd met dit ingetrokken certificaat - dat Windows nog steeds geldig vindt - ben je de sjaak.

Met goed dichttimmeren bedoel ik bescherming tegen Responder (NetBIOS over TCP/IP in adaptersettings op disabled, in elk geval voor WiFi en op tig plaatsen proxy instellingen op "no proxy" zetten om te voorkomen dat de WPAD requests die jouw PC anders uitzendt, de PC kwetsbaar maken voor http redirects) en dat je de server service hebt uitgezet (om niet kwetsbaar te zijn voor allerlei ongepatchte lekken en voor brute force password guessing aanvallen). Tegen vervalse DHCP antwoorden (of, als het access point pwned is, niet vervalste maar wel kwaadaardige DHCP antwoorden) kun je je helaas lastig beschermen.

Maar nogmaals, zelfs met een perfect beveiligde Windows PC ben je waarschijnlijk kansloos als digitale handtekeningen onbetrouwbaar zijn.

Ik ben benieuwd of Microsoft secure haar mening bijstelt...

Ik denk er al ca. 2 jaar over om een stichting zonder winstoogmerk te beginnen die allerlei identiteitsdiensten levert, waarbij (voor toepassingen waarbij dat noodzakelijk is) de privacy zoveel mogelijk gewaarborgd wordt. Maar ik ben vooral techneut, en zelfs de techniek is al lastig (denk alleen al aan quantum computers die de gangbare asymmetrysche cryptografie bedreigen). En ik wil het dan wel zo hebben dat oneerlijke mensen er geen identiteitsfraude mee kunnen plegen en/of cybercriminelen ervan kunnen profiteren.

Doel is iedereen (desgewenst zo anoniem mogelijk), maar ook websites, een betrouwbare digitale identiteit te kunnen geven, niet van overheidswege opgelegd, waarbij ook revocation goed geregeld moet zijn.

Kortom, geen eenvoudige opgave...

Ja, Bitwiper, je hebt 100% gelijk. Gigantisch probleem, maar niemand die een vinger uitsteekt. Het schijnt dat ze Wreck-It Ralph hebben losgelaten op het Internet Trust Systeem.

Maar wat moet je als cybercriminelen door Overheden gedoogd worden om buiten de eigen achtertuin (buiten de CIS landen) actief te zijn met "carding" etc. en sommige instanties het wel prachtig vinden als men via aangepaste DNS en speciaal geprepareerde downloads hun gang kunnen gaan (denk hier aan de veiligheidsdiensten met de drie- of vier-letterige afkortingsnamen). Ik denk dat men het nu opvat als "collateral damage" die men op de koop toe neemt. Niet leuk, maar wat is leuk?

Op het gedegradeerde en a priori onveilige Internet is duidelijk een instantie als "The Untouchables" uit de jaren dertig in de States nodig, om eens echt orde op zaken te stellen. Daarnaast is er natuurlijk al tijden een software compatibiliteitsprobleem, zie voorbeeld: https://community.letsencrypt.org/t/is-weebly-compatible-with-letsencrypt-ca-in-any-shape-way-or-form/38374

We zijn nog een eind van huis...

luntrus

Hier de uitleg over de intrekkingsproblemen bij Windows. Dit probleem doet zich voor omdat Exchange Server 2010 maakt gebruik van Microsoft Windows HTTP Services (WinHTTP) voor het beheren van alle HTTP- en HTTPS-verkeer en WinHTTP maakt geen gebruik van de proxy-instellingen die zijn geconfigureerd voor de Internet-browser.
Als u wilt weergeven van de WinHTTP proxy-instellingen, bij een opdrachtprompt de volgende opdracht uitvoeren:
netsh winhttp show proxy
Om dit probleem op te lossen moet u de WinHTTP-proxy instellen en de FQDN-naam in de WinHTTP-server lijst overslaan.

Opmerking Als u niet is geconfigureerd zowel de proxy-instellingen als de FQDN-naam in de WinHTTP uitzonderingslijst, Exchange Management Shell en de Exchange Management Console kan geen contact opnemen met de Remote PowerShell.

Open een opdrachtprompt, typ de volgende opdracht en druk op ENTER dit probleem op te lossen:
netsh winhttp proxy proxy-server instellen = "http =myproxy" bypass lijst = "*. hostnaam.com'
De naam van de proxyserver myproxy aanduiding en hostnaam

Hiermee geeft u de hostnaam van de Exchange Server 2010. (info MS help 979694).

luntrus

Er is dus duidelijk een bug aanwezig, wel een ingebouwde drempel zeker.

Waar het vaak ook nogal vaag blijft en fout kan gaan is bij de DNS CAA check for CA's. De hostname moet hierbij in het DNS record staan.

Dit blijkt ook vaak meer een soort van administratieve controle maatregel en de check reageert over het algemeen te noemen soms vrij vaag en dus neemt men dan in vele gevallen maar aan dat het goed is gegaan en dus goed zit.

In dit geval dient er getest te worden tegenover een whitelist en deze DNS CAA procedure zou in september van dit jaar verplicht moeten zijn ingevoerd als extra veiligheidsmaatregel. Bij vele certificaten vinden we overigens nog "DNS CAA - neen", bij voorbeel bij het beruchte GoDaddy certificaat.

De hele procedure valt of staat met de zorgvuldigheid van de checks door een van de vele CA's en wordt bij sommige CA's dus niet goed uitgevoerd en is bovendien gevoelig voor "social engineering' en daarom is het veel minder betrouwbaar dan de HDKP check in het geval van browsers, waar alles verloopt aan de hand van gewhiteliste public keys.

Vaak is Certificate Transparency niet embedded in het certificaat en bij Domain Validated Certificates is de domein eigenaar niet bekend, tenminste vindt er geen site owner validatie plaats.

Loopholes te over dus, er rammelt nog genoeg aan vele kanten en de veiligheid is niet optimaal gegarandeerd.
Hier ontbreekt een vinger aan de pols, zoals de Google-Symantec controverse al wel heel duidelijk heeft aangetoond inmiddels. Benieuwd hoe dit alles zich gaat ontwikkelen. Pappen en nathouden waarschijnlijk zoals bij zo veel online op de infrastructuur.

luntrus