'Providers in twee landen spelen rol bij verspreiden FinFisher-staatsmalware'

Beveiligingsbedrijf ESET zegt dat in twee niet nader genoemde landen aanwijzingen zijn gevonden dat kwaadwillenden de FinFisher-malware verspreiden met behulp van internetproviders. Zo worden downloads van legitieme programma's omgeleid naar kwaadaardige versies.

ESET meldt dat het de nieuwe FinFisher-campagne heeft opgemerkt in zeven landen. Het zegt alleen niet welke dat zijn, naar eigen zeggen om 'niemand in gevaar te brengen'. Deze campagne maakt in twee van de zeven landen gebruik van een man-in-the-middleaanval, in tegenstelling tot eerdere technieken die werden gebruikt om FinFisher te verspreiden, zoals zero-days of handmatige installatie bij fysieke toegang. In de twee landen heeft ESET aanwijzingen gevonden dat isp's betrokken zijn bij de verspreiding van de malware.

Dat baseert het bedrijf op de bevinding dat in het verleden al eens de zogenaamde FinFly ISP-malware door de maker werd aangeboden die was bedoeld voor gebruik door isp's. Dat bleek uit een publicatie van WikiLeaks. Daarnaast wordt in beide landen van dezelfde redirecttechniek gebruikgemaakt om doelwitten om te leiden naar kwaadaardige downloads. Dat wijst erop dat de methode door dezelfde partij is ontwikkeld. Tot slot gebruikten alle doelwitten in de landen dezelfde provider en werd de redirecttechniek in een van de landen eerder toegepast voor filterdoeleinden. Ook de geografische verdeling van de doelwitten zou erop duiden dat op isp-niveau gewerkt wordt.

De redirect werkt doordat het doelwit eerst naar een site gaat om bepaalde software te downloaden. ESET noemt een aantal voorbeelden, waaronder WhatsApp, Skype, Avast, WinRar, VLC, Threema en TrueCrypt. Als de gebruiker eenmaal op de legitieme site is en op de downloadlink klikt, wordt hij ongezien doorverwezen via een 307 temporary redirect die hem een kwaadaardige versie van de software laat downloaden. De nieuwe versie van FinFisher zou van eerdere varianten verschillen doordat er meer nadruk wordt gelegd op het voorkomen van analyse. Zo is de malware voorzien van maatregelen die disassembly van de code moeten bemoeilijken, waaronder een laag virtualisatie zit verborgen.

De FinFisher-malware, ook bekend als FinSpy, wordt volgens ESET gebruikt door opsporingsdiensten. De kwaadaardige software wordt ontwikkeld door Gamma International, dat vestigingen in Duitsland en het VK heeft en onder het bedrijf Lench IT Solutions valt. In 2014 claimde ProPublica dat de malware werd gebruikt in zes landen om personen in de gaten te houden. Ook regeringen die zich veelvuldig schuldig maken aan mensenrechtenschendingen, zouden de malware inzetten, evenals wellicht de Nederlandse politie. De malware is onder meer in staat om webcambeelden en toetsaanslagen vast te leggen, en bestanden van geïnfecteerde systemen te stelen.

Werking van de redirect, volgens ESET

Reacties (77)

[CAPSLOCK2000]

Dit nieuwsbericht onderstreept hoe belangrijk het is om HTTPS (liefst met HSTS) en DNSSEC te gebruiken.
Als dat was gedaan dan was dit niet gebeurd.

Ik vind het sowieso onbegrijpelijk dat er nog software wordt aangeboden via onveilige HTTP-verbindingen. We hebben het hier ook niet over kleine onbekende pakketten maar industrietoppers. Die zouden er alles aan moeten doen om dit soort aanvallen moeilijk te maken.

Voor de duidelijkheid, je moet dus niet alleen de download zelf aanbieden via HTTPS, maar de hele site, anders veranderen ze gewoon de download link.


Nog beter is om je software niet met het handje te downloaden maar dat zo veel mogelijk te automatiseren via gecontroleerde repositories/appstores.

[vinno97]

Veel landen hebben de macht om zelf certificaten uit te geven die door de grote browsers herkend worden. Als ze kunnen zorgen dat een ISP redirects uitdeelt, kunnen ze zeer waarschijnlijk ook een certificaat spoofen.

[CAPSLOCK2000]

Door Certificate Transparency is dat een stuk moeilijker geworden. Ze kunnen die certificaten wel uitgeven, maar niet zonder dat de hele wereld ziet wat ze doen.
Met DNSSEC en DANE is het ook mogelijk om te publiceren welk SSL-certificaat je verwacht. Een aanvaller moet dan ook DNS veranderen. Onderscheppen en manipuleren is met DNSSEC niet genoeg, je moet dan echt bij de bron zijn, anders ziet het systeem gewoon dat er iemand iets heeft veranderd/verwijderd. De meeste landen hebben wel invloed op hun eigen .tld, maar we hebben het hier over internationale projecten met domeinen in .com en andere belangrijke TLDs waar vreemde landen niet zomaar in kunnen roeren.
Als je de VS tegenover je hebt wordt het misschien een andere zaak, maar dan nog zal het lastig worden om dat in het geheim te doen.

[dasiro]

er zijn maar weinig mensen die de certificaten van hun providers en overheden niet vertrouwen.

[totaalgeenhard]

Dit nieuwsbericht onderstreept hoe belangrijk het is om HTTPS (liefst met HSTS) en DNSSEC te gebruiken

Want?
Iedereen gebruikt een OS die hele keten zal (kan) controleren?

Elke zone file is 100% correct.

Zodra je in verkeer van iemand kunt komen maakt dnssec niet uit.

Sterker nog vertrouwen in dnssec vormt een groter risico.

[CAPSLOCK2000]

Want?
Iedereen gebruikt een OS die hele keten zal (kan) controleren?

Nee, dan was dit niet gebeurd. Het is een goede reden om er naar toe te werken.

Zodra je in verkeer van iemand kunt komen maakt dnssec niet uit.

Dan werkt DNSSEC nog steeds, daar is het voor gemaakt. Je kan controleren dat je DNS-verkeer onderweg niet gemanipuleerd wordt. Je kan het niet voorkomen, maar je kan de gemanipuleerde informatie in ieder geval negeren.
Dat is inderdaad geen totaaloplossing voor alle beveilingsproblemen op internet, maar het is een noodzakelijk stukje.

[totaalgeenhard]

Nee man.

Er is geen eind gebruikers OS (GUI) die uit de doos DNS keten checked. Zonder plugin voor.je browser weet je het niet.

En zelfs met plugin weet je niet of resultaat klopt aangezien je hosts file, nameserver van je kabel/dsl modem, je provider t/m nameserver van domein (en daarmee zonefile) aangepast kan worden.

Ik zou vragen om eens te spelen met dnssec en kom tot zelfde conclusie vroeg of laat.

[CAPSLOCK2000]

Ik heb wel iets meer gedaan dan gespeeld met DNSSEC. Google maar.
Perfect bestaat niet, maar het is een stuk beter dan niks. Dat het nu nog niet in je OS zit is geen reden om het niet te willen.

[totaalgeenhard]

Ik denk dat je het of niet snapt of denkt dat dnssec feilloos is.

1) als je zonefiles, resolvers kunt aanpassen maakt dnssec niet uit.

2) root servers worden gewoon ook weleena gehacked, maar dat hoeft niet en zou juist opvallen.

3) Als je bij/in iemand zijn IP stream kunt pakken kan en zal dnssec op geen enkele manier bescherming bieden

4) xss t/m "fysieke" pagina aanpassing op/via server kunt je nooit afschermen met dnssec.

Dus nogmaals hoe kan dnssec heden ten dage dit voorkomen?

En hoe kan dnssec dat in toekomst doen?

[CAPSLOCK2000]

Ik denk dat je het of niet snapt of denkt dat dnssec feilloos is.

Je blijft maar om een perfecte oplossing vragen. Perfecte oplossingen bestaan niet. HTTPS is ook niet feilloos.
DNSSEC is ook geen oplossing voor het fileprobleem op de A2. Big deal. Het hoeft niet alles op te lossen om nuttig te zijn.

[totaalgeenhard]

Lees eens wat ik schreef en vertel dan eens hoe dnssec dit kan voorkomen.

[CAPSLOCK2000]

Leg jij dan eerst uit waarom DNSSEC dat moet voorkomen. Dat is niet het doel. Vertel me waarom DNSSEC niet geschikt is voor het doel dat het wel heeft. Je valt een stroman aan.'

Voor de gehackte root-server is DNSSEC trouwens wel een oplossing. Je kan zo'n server wel hacken maar zonder de private key van de DNSSEC root kun je niks veranderen. De root-servers hebben die key niet.

[Reactie gewijzigd door CAPSLOCK2000 op 24 juli 2024 16:29]

[totaalgeenhard]

Dit nieuwsbericht onderstreept hoe belangrijk het is om HTTPS (liefst met HSTS) en DNSSEC te gebruiken.
Als dat was gedaan dan was dit niet gebeurd.

Schreef je..

En ik bestrijd dat.

Nogmaals doe wat ervaring er mee op en zie hoe het werkt.


Bekijk eens een zonefile...

Verder heeft het voor mij geen zin om iemand te overtuigen die het technisch nooit gebruikt heeft of met implementaties te maken heeft gehad en daarmee niet weet hoe keten eenvoudig op meerdere manieren te omzeilen is.

Zelfs ICANN guru's die ik vorig jaar bij root server lezing bij ICANN55 bevroeg erkende dit gewoon zonder enige discussie.


Ps: ssl voorkomt dit dus ook niet....

[Reactie gewijzigd door totaalgeenhard op 24 juli 2024 16:29]

[CAPSLOCK2000]

Verder heeft het voor mij geen zin om iemand te overtuigen die het technisch nooit gebruikt heeft of met implementaties te maken heeft gehad en daarmee niet weet hoe keten eenvoudig op meerdere manieren te omzeilen is.

Leg dan maar eens uit hoe je de keten omzeilt zonder de private root-key te hebben.


[quote[
Ps: ssl voorkomt dit dus ook niet....
[/quote]
Dat gebruik jij dus ook niet?

[Reactie gewijzigd door CAPSLOCK2000 op 24 juli 2024 16:29]

[totaalgeenhard]

Had een deja vu...


nieuws: Xs4all neemt dnssec in gebruik

Je leest niets. Zolang je dat niet doet zul je niet leren en sinds vorig jaar heb je kennelijk niets bijgeleerd.

Mbt https alleen met preshared keys (na signing sessie) heb je iets wat voor en door derden niet aan te passen/vervalsen is....

Maar ik vermoed dat ik wederom een deja vu verhaal tegen kom.

[CAPSLOCK2000]

En hoe ga je die keys pre-sharen met heel internet?
Ik gebruik daar DANE voor.

Kom nu eens met concrete technische argumenten waarom het niet werkt in plaats van ad hominems. Je blijft me maar aanvallen op mijn gebrek aan kennis, maar jouw kennis lijkt stil te zijn blijven staan in 1999. Ga je eens inlezen in wat er de afgelopen 15 jaar is gebeurt en kom dan met technische antwoorden, in plaats van vage opmerkingen over "ip streams" en "guru's van icann".

[totaalgeenhard]

Voor zoveelste keer.

Vrijwel niemand op aarde controleert native DNSSEC keten.

1) omdat er geen OS is die dat standaard doet

2) Omdat er vrijwel geen kabel/adsl modem dnsresover is die het standaard doet

3) Omdat vrijwel geen ISP's dit standaard doet

4) Omdat het niets uitmaakt als je tussen presentatie layer van content en content opslag kunt komen.

Als je bovenstaande niet begrijpt dan ben ik niet degene die het (gratis) aan je zal leren.

[Reactie gewijzigd door totaalgeenhard op 24 juli 2024 16:29]

[CAPSLOCK2000]

Dat het er nu nog niet is betekent nog niet dat het nooit kan veranderen. Ik werk er aan om DNSSEC verder te verspreiden. De meeste OS'en en resolvers ondersteunen het, ook al wordt het nog niet afgedwongen. Applicatie support loopt ook steeds beter.

Maar goed, je hebt gelijk, we hebben dit dansje al vaak genoeg gedaan. Laten we van het weekend gaan genieten.

[beerse]

Dit bericht maakt ook duidelijk dat je de site moet controleren als je er naar toe gaat en ook als je binnen de site klikt!

Zelf kijk ik altijd even naar de kleur en stand van de slotjes als ik naar de site van de bank ga. Het is dus ook nodig om tijdens het klikken binnen de sites of de slotjes niet veranderen!

En uiteindelijk, als je op een download klikt moet je die dus ook controleren!

[Proxx]

zodra je binnen een site verwezen word naar een pagina die niet vertrouwd word krijg je een waarschuwing
die je overigens bij verschillende brouwers met een vinkje blijvend kunt verbergen

[Marty007]

Juist die geautomatiseerde installers vertrouw ik het minst van allemaal haha
Dan zie je al helemaal niet meer wat er allemaal gebeurd achter de schermen..

[TWyk]

Het is naïef om te denken dat certificaten veiligheid bieden.
Zeker niet tegen overheden.

[CAPSLOCK2000]

Het is naïef om te denken dat certificaten veiligheid bieden.
Zeker niet tegen overheden.

Zolang je de beperkingen maar kent is het een prima middel. Alleen een certificaat is niet genoeg, maar het is belangrijk deel van veel oplossingen. Ik noem DNSSEC omdat dat een ander belangrijk middel is. In combinatie met DANE kan het certificaten veel sterker maken omdat het moeilijker wordt om HTTPS te ontwijken of certificaten te vervalsen.
Perfectie bestaat niet en tegen je eigen overheid verdedigen blijft lastig, maar we kunnen het een stuk moeilijker maken om sites te kapen dan het nu is.

[Breezers]

Beveiligingsbedrijf ESET zegt dat in twee niet nader genoemde landen aanwijzingen zijn gevonden dat kwaadwillenden de FinFisher-malware verspreiden met behulp van internetproviders.

ESET meldt dat het de nieuwe FinFisher-campagne heeft opgemerkt in zeven landen. Het zegt alleen niet welke dat zijn, naar eigen zeggen om 'niemand in gevaar te brengen'.

Dat is best een kromme logica of niet ?

[Reactie gewijzigd door Breezers op 24 juli 2024 16:29]

[Gijs007]

Wat is daar krom aan?
In zeven landen is de campagne opgemerkt. In twee van die landen wordt met behulp van de internetproviders de campagne verspreid. (Ik vermoed d.m.v. gehackte servers.)

[sumac]

Ik denk niet dat die servers gehackt zijn, maar dat het een bewuste installatie is in opdracht van de staat.

[Verwijderd]

Ik vraag mij af of dit westerse landen zijn. Dat kunnen ze toch wel vertellen?

[Wim-Bart]

Nederland is genoemd als mogelijk land. Wat dus zou kunnen.

De gebruikte methode is best wel interessant trouwens. Je kan dus een specifiek "target" infecteren, door een response redirect te doen naar een eigen server zonder dat de Downloader daar dus erg in heeft.

Interessante materie, dus bij een bedrijf zou je via een proxy server het zelfde kunnen doen met bijvoorbeeld BYOS devices (Bring Your Own Shit).

[Verwijderd]

Dit is de zogenaamde 'internet read / write' modus waar men al jaren over praat en gesuggereerd wordt dat de NSA deze mogelijkheid heeft om targets te infecteren. Het kan natuurlijk ook via ISP's die meewerken met inlichtingendiensten.

Bizar dat men mensen die Truecrypt downloaden infecteert. Het geeft wel aan dat de software werkt, anders deed men dit niet.

[Wim-Bart]

Is is niet eens nodig als het internationale sites betreft. In theorie is bijvoorbeeld al ongelimiteerde toegang tot bijvoorbeeld AMX al voldoende.

If src.ip == 123.45.67.89 then route through AIVD device.

[MumenRider]

Mij lijkt het niet melden over welke landen het gaat krom?

[Breezers]

En wie komt er dan feitelijk allemaal in gevaar ? en waarom is iets "ontdekken", dit publiceren en daarna niet aangeven wie de betrokken partijen zijn dan een rechtvaardiging om dit te doen ? Dat is toch krom ? Je publiceert (openbaart) iets met een doelstelling, maar dan noem je geen namen om 'niemand in gevaar te brengen'..... zeg dan niets of noem het naampje bij het beestje....

[aadje93]

je brengt de gemeenschap op de hoogte dat deze malware aanwezig is/rond gaat. Waar het direct vandaan komt is niet interessant lijkt mij, wilde je specifiek dat IP gaan blokkeren?

[Breezers]

IP adres ? Wie heeft het hier over een IP adres ? Volgens mij heb jij geen idee waar dit artikel over gaat

[curkey]

Zonder de situatie te kennen is dat niet zonder meer te stellen. Wellicht brengen ze dan belangrijke informanten in gevaar omdat dan duidelijk wordt waar het lek gezeten heeft. Enfin, het doel is al wel bereikt, want de mensen die ermee te maken hebben, zijn nu geinformeerd en dus op hun hoede.

[Kheos]

hoezo dat?
Stel dat die twee landen Iran en Noord Kora zijn (ik noem nu maar wat). Als dit rapport naar buiten komt, is het voor die overheden een koud kunstje om een lijst op te stellen van mogelijke verdachten die dit naar buiten zouden kunnen gebracht hebben en die tegen de muur te zetten.
Nu ze het vaag houden, weet 'het publiek' er tenminste van.

[sumac]

Als je zo'n land bent, dan weet je toch al bijna zeker dat je ontdekt bent? ESET verzamelt vast data van zoveel mogelijk landen en providers, dus als schuldig land kun je hiervanuit gaan.

[X_pl0visi0n]

ik zou eerder geld zetten op Egypte en Turkije.

[bbob]

Als ik mag gokken dan gewoon een eu land. Het is een bedrijf uit DE / VK die het maakt, ze willen het niet zeggen dus ligt het heel gevoelig. Egypte en Turkije ligt te veel voor de hand en niet echt gevoelig.

Maar goed het betekend dus eigenlijk dat je met een vpn verbinding moet gaan werken en dan hopen dat je vpn provider niet in het complot zit.

[HenkEisDS]

VPN verhelpt dit niet.

Edit: Ja inderdaad je hebt gelijk. Je isp ziet het niet.

[Reactie gewijzigd door HenkEisDS op 24 juli 2024 16:29]

[R4gnax]

VPN verhelpt dit niet.

Het verhelpt niet de malware zelf, maar dwarsboomt wel de verspreidingsmethode.

De malware wordt vanuit ISPs verspreid doordat zij legitieme downloads voor software beinvloeden. Ze injecteren een HTTP 307 response voor bepaalde download URLs -- Dit is een transparante redirect die by design niet door een browser in de adresbalk gerapporteerd wordt! -- zodat de browser doorgestuurd wordt naar een geinfecteerde download.

Door van een VPN gebruik te maken krijgt een ISP niet de kans om die HTTP 307 response te injecteren, want de communicatie is op dat moment versleuteld.

Evenzogoed kan een ISP dit niet toepassen wanneer de download over een versleutelde verbinding plaatsvindt. Tenzij er sprake is van een vertrouwd root-certificaat wat gecompromiteerd is. Dat zou hen toestaan om de data te ontsleutelen, modificeren en herversleutelen op zo'n manier dat de browser het herversleutelde resultaat blijft accepteren als geldig. De Lenovo Superfish affaire betrof bijv. één zo'n certificaat.

[Reactie gewijzigd door R4gnax op 24 juli 2024 16:29]

[MacD]

Uhm ... deels wel, toch?

Met een VPN weet je ISP niet welke data je wilt (encryptie) en ziet het enkel dat al je data van en naar 1 connectie gaat (de VPN provider).

Natuurlijk, als het de ISP van die software-download-link-website betreft, dan fungeert het als een MitM attack en ben je de pineut.

ESET zou dus echt moeten vertellen waar het probleem zich voordoet, zodat we kunnen zien of het ISP zijn van sites waar we dingen downloaden.

[Wim-Bart]

En dan ga je met Tor bijvoorbeeld via een exit node die toevallig onder surveillance staat en krijg je het onbedoeld binnen. Of de VPN provider heeft niks in de gaten en je haalt alles gewoon binnen via de VPN provider. VPN providers zijn de ideale kandidaten om grote groepen in 1 keer van deze software te voorzien.

Wanneer je je er in verdiept is het eigenlijk hartstikke gevaarlijk om via een VPN legitieme sites te bezoeken en daar van te downloaden net zoals Tor dat dus is. Eigenlijk is VPN en Tor dus alleen veilig zolang je aan het eind van de tunnel niet het reguliere internet op gaat.

[Kheos]

vandaar mijn "ik noem nu maar wat".
Egypte en Turkije zijn inderdaad goeie kandidaten.
Maar kan evengoed Rusland en Pakistan zijn.
Of China en Syrie.
Bahrein en Vietnam...

[bigbadbull]

of de VS, ik zeg maar iets

[Verwijderd]

Of Nederland, die hebben ook zaken gedaan met dat bedrijf.

[curkey]

Er zijn ook landen dichterbij huis die sleepnetten opzetten, dus het is nog maar de vraag of je ver met de auto moet...

[Diablo_GT]

Je noemt maar wat? Jij denkt dat het toeval is dat je deze twee landen opnoemt?

[Reactie gewijzigd door Diablo_GT op 24 juli 2024 16:29]

[Deralte]

Hangt er vanaf. Misschien is er een grote operatie van de veiligheidsdiensten bezig en wordt eset gedwongen om geen derails vrij te geven.

[jpsch]

Vraag je je toch af of ze dat ook met CCleaner gedaan hebben.

[RGAT]

CCleaner was vziw in de ontwikkelomgeving gebeurt aangezien het bestand gesigneerd was en er dan dus niet achteraf een ander bestand gesmokkeld kan worden.

[Tweekzor]

Dat is onwaarschijnlijk aangezien ze (de hackers die malware in CCleaner hebben gestopt) dan alsnog de infrastructuur van Piriform gehackt moeten hebben. De build van CCleaner had namelijk een geldige digitale handtekening. Het is in deze situatie dan ook veel logischer dat de download bij Piriform zelf is aangepast en de malware is toegevoegd tijdens het build proces. Daarnaast wordt in meerdere bronnen hierover gemeld dat de malware ongeveer evenredig (naar inwoners) is aangetroffen in landen wereldwijd en niet slechts in 2 landen waarvan de ISP's mogelijk corrupt zijn.

[CEx]

Dat wordt de CRC weer iets serieuzer nemen. Niet alleen als gebruiker maar ook als aanbieder.

Nu hopen dat de CRC tools niet omgeleid worden.

[tweaknico]

Niet alleen de CRC, ik hoop dat je toch echt naar een SHA256 checksum kijkt, liefst meerdere verschillende Hashes. Daarnaast controle op certificaten van websites en verder voor ALLES HTTPS gebruiken.

[MacD]

Weet je toevallig ook een makkelijke UI tool daarvoor?

Een waar je het bestand in sleept en de checksums copy/paste (liefst meedere soorten tegelijk die dan correct geparst worden)?

[tweaknico]

geen gui tool....
maar sparamma's als sha256 rmd384 etc. zijn simpele commandline tools die eigenlijk een argument hebben de filenaam en een uitvoer, de hash.

Daar kunnen makkelijk scripts mee gebouw worden. (Zeker met een shell als BASH).

[MacD]

Sorry dat ik het zo breng, maar ... duh.

Ik kan ook powershell gebruiken of een bat aanmaken. Of zelf een java/c# programma maken met een installer die zorgt dat ik in de file explorer een rightclick optie krijg om te checksummen.

Het is gewoonweg niet efficient om telkens handmatig de command te typen en te checken. Automatisering, weetje.

Excuses voor het volgende want ik weet dat het gemeen overkomt ... maar je antwoord komt neer op 'nee, weet ik niet ... go google'. Had je tijd gescheeld

[tweaknico]

Niet echt... de meeste serieuze distributie systemen gebruiken dit al intern.
Kijk eens naar Gentoo's Portage, of YUM of APT....
Daar hoef je niet veel in te voeren, de checks zijn er ALTIJD. met als basis een bepaalde bekende entiteit.

[MacD]

Ja, maar mijn vraag was of je een UI tool kende die dat deed voor programma's die je al had gedownload.

Dat apt-get 't doet is dus niet relevant ...

[tweaknico]

synaptic... (voor debian).

[MacD]

Nee.

Dit is wat ik vroeg:

Een waar je het bestand in sleept en de checksums copy/paste (liefst meedere soorten tegelijk die dan correct geparst worden)?

Geen GUI voor apt. Een gui voor het controleren vd checksum ve programma dat je van any source krijgt.

Heb er zelf nog een kwartier ingestoken en tot mijn verbazing bestaat het niet. Misschien dat ik volgende maand de tijd heb om het dan maar zelf te schrijven.

[tweaknico]

Kijk eens naar Gentoo, portage doet verschillende checksums over alle bronnen.
Portage zelf heeft alleen een verzameling build scripts & manifesten (=checksum lijsten).
De bronnen komen of van een cahce server of direct van de originele bron.

Dat systeem bestaat al ruim 15 jaar.
(gui die ik ken = porthole), anders sabayon een afgeleide distro die vrijwel geheel graphisch is.

Aanvulling:
Portage kent 2 build tools emerge (& co) en paludis de laatste ken ik minder goed, maar heeft gpaludis als het goed is.

Zie ook:
https://en.wikipedia.org/wiki/Portage_(software)
(arch distro gebruikt een vergelijkbaar build systeem).

[Reactie gewijzigd door tweaknico op 24 juli 2024 16:29]

[MacD]

Uhm ....

Lees je niet wat ik schrijf? Of omschrijf ik het echt zo slecht?

Probleem: je download dingen van het internet en wilt checken of er niet mee gekloot is.

Mogelijke oplossing: een tooltje welk je opstart en de file in sleept/een rightclick op de file waarna de tool opstart en je vervolgens wat text in kan copy/pasten (die text bestaat uit 1 of meerdere hashes die je wilt controleren, maw de sha/md hash die je gekopieert hebt vd webpagina); de tool vraagt 'wil je deze md5 checken op het bestand?' en geeft aan of het klopt of niet.

Ik heb wel drie keer duidelijk verteld wat ik zocht en jij hebt elke keer naar iets verwezen wat compleet de plank misslaat. Sterker nog: je valt in herhaling en verwijst naar dingen die ik ten eerste al kende en ten tweede als ik ze niet kende heb opgezocht.

Ik ben niet op zoek naar een build manager of command line tools (echt, Portage?! En dat twee keer linken? WTF?). Ik zocht een GUI frontend om hashes to checken!

Zoals ik tig comments geleden al zei: zeg dan gewoon: 'weet ik niet'. En ga zeker niet WEER verwijzen naar dingen die compleet irrelevant zijn voor de probleem-oplossing, zeker niet als ik al aangeef dat ik zelf sphlib/MessageDigest weet te gebruiken om zelf de oplossing te maken.

Ik vroeg enkel of je wist of dat al bestond.

[Kabouterplop01]

Dat maakt niet uit, https of niet, als de hele chain 100% in orde is dan is het niet van echt te onderscheiden.
het is een temporary redirect (307). Als je zoiets kunt flikken dan de redirect naar de hashes ook.

[tweaknico]

Hoe kan een buitenstaander een HTTP respons 307 in een stream injecteren?
als die stream encrypted is..., als de stream niet encrypted is a la.

Maar de originele site zal niet de 307 respons sturen. Goede Https is overigens veel meer dan alleen een certificaat, ook HSTS, disable van oude methode, disable van export cipers, key pinning, mogelijk DANE/DNSSEC etc. etc. is nodig.

Aanvulling:
Injectie in HTTPS stream kan uitsluitend als bij aanvang al een verkeerd certificaat gebruikt is.
maar dat zou moeten opvallen als iemand verkerder kijkt dan alleen naar het groene slotje.

[Reactie gewijzigd door tweaknico op 24 juli 2024 16:29]

[Mel33]

Is dit dan ook in de store van alle os’en mogelijk?

[tweaknico]

Hangt van beveiligingsmaatregelen van de distributie af en in hoeverre een store gerepliceerd is.
door betreffende ISP's.

[Reactie gewijzigd door tweaknico op 24 juli 2024 16:29]

[Whoisbacknow]

Met genoeg inzet van tijd en middelen is alles mogelijk! Zeker als er overheden in het spel zijn..

[DaBeast.net]

Van de white-paper op Wikileaks :

Target Computer – Example Features:

• Bypassing of 40 regularly tested Antivirus Systems
• Covert Communication with Headquarters
• Full Skype Monitoring (Calls, Chats, File Transfers,
  Video, Contact List)
• Recording of common communication like Email, Chats
  and Voice-over-IP
• Live Surveillance through Webcam and Microphone
• Country Tracing of Target
• Silent extracting of Files from Hard-Disk
• Process-based Key-logger for faster analysis
• Live Remote Forensics on Target System
• Advanced Filters to record only important information
• Supports most common Operating Systems (Windows,
  Mac OSX and Linux)

Volgens Vice zijn er 32 landen geïmpacteerd en op een oude worldmap kan je zien dat er in Nederland ook servers actief zijn (bron).

[gjmi]

Op deze oude map en bron kun je zien waar het in 2013 actief was. Dat zegt toch niets over nu?

[RxTweak]

Het blijft speculeren maar twee dagen geleden verscheen er een nieuwsbericht op liveuamap.com dat mogelijk gekoppeld kan worden aan dit nieuwsbericht op tweakers.net.

"SBU exposed ISPs on illegal rerouting traffic to area under DNR/LNR groups control".

Als er inderdaad een verband is tussen beide nieuwsartikelen, dan is het zeer aannemelijk dat Rusland één van de twee actoren is. Het zou dan gaan om meerdere ISPs in Oekraïne.

[Reactie gewijzigd door RxTweak op 24 juli 2024 16:29]

[Finger]

Lijkt me dat de tor browser ook een populaire doelwit zou zijn voor deze methode.

[Duckman51]

Maakt het nog wat uit op welk OS je draait?
Ik bedoel in de zin van dat je dan een kwaadaardige versie voor bijv Windows of Linux krijgt?
Uit het verhaal maak ik op dat dit voornamelijk om Windows programma's gaat

Ik vind dit nogal gevaarlijk spel, je kunt in feite niet weten waar je download precies vandaan komt, terwil je denkt ik zit op de website van de maker dus de download is legit

[Montoya200x]

Maar als je de producten van ESET gebruikt, wordt een kwaadaardige download met Finfisher malware dus blijkbaar onderschept en tegengehouden, volgens hun artikel... Proefondervindelijk kan je er dus erachter komen of je je in een land bevind, waar een ISP zich dus met deze kolder bezighoudt, door de software van ESET te gebruiken ....

Dus aan de ene kant een leuke advertorial voor ESET, maar aan de andere kant ook een goede waarschuwing voor iedereen, die andere security software gebruikt, die deze malware nog niet detecteert....