Beveiligingsonderzoeker zet spelfouten in om willekeurige code uit te voeren

Een Duitse student van de Berlijnse Humboldt-universiteit heeft een aanval ontwikkeld op basis van spelfouten die gebruikers maken bij het installeren van software packages. Door packages met soortgelijke namen te ontwikkelen wist hij op 17.289 hosts willekeurige code uit te voeren.

De student, Nikolai Tschacher, schrijft dat hij op het idee voor deze aanval is gekomen door te kijken naar een praktijk die vaak bij domeinnamen wordt ingezet en bekendstaat als 'typosquatting'. Daarbij registreert een kwaadwillende partij bijvoorbeeld een domeinnaam die lijkt op een bestaand merk, maar dan met een lichte afwijking. Bijvoorbeeld gooogle.com in plaats van google.com. Omdat gebruikers soms spelfouten maken bij het typen van een domeinnaam, bestaat de kans dat zij op de nepsite terechtkomen, die bijvoorbeeld malware kan serveren.

Tschacher realiseerde zich dat deze methode ook op een andere manier ingezet kan worden, namelijk bij de installatie van software packages op computersystemen. Daarbij typt een gebruiker vaak een bepaald commando om software te installeren, bijvoorbeeld sudo pip install requests. Daarmee wordt de 'requests'-package geïnstalleerd uit de Python-repository, genaamd PyPi. De onderzoeker beschrijft dat hij naast PyPi ook de Ruby- en Node.js-repositories als doelwit heeft gekozen.

Hij voerde zijn onderzoek uit door 214 verschillende packages aan te maken, waarvan de namen veelvoorkomende spelfouten bevatten. Bijvoorbeeld 'reqeusts' in plaats van 'requests' en 'coffe-script' in plaats van 'coffee-script'. In alle gevallen was het mogelijk om de code in zijn packages meteen uit te laten voeren bij de installatie. Ook voegde hij een functie toe die het 'slachtoffer' op de hoogte stelde van het feit dat er een spelfout is gemaakt en dat de verkeerde package is geïnstalleerd. Zijn programma's stuurden ook geanonimiseerde gegevens naar een server van de universiteit, aan de hand waarvan hij zijn analyse uitvoerde.

Uit zijn statistieken blijkt dat er 45.334 http-verzoeken door 17.289 hosts werden uitgevoerd tussen november 2015 en februari 2016. 43,6 procent van de verzoeken werd uitgevoerd met beheerdersrechten op Linux, Windows en OS X. Daardoor had hij volledige toegang tot die systemen kunnen verkrijgen. Tschacher was ook in staat om een worm op basis van zijn methode te ontwikkelen die op een geïnfecteerd systeem automatisch op zoek gaat naar packages die vaak verkeerd gespeld worden. Door de verkeerd gespelde packages vervolgens in de verschillende repositories te registreren, kon hij de effectiviteit van de worm vergroten.

De student schrijft dat de beste verdediging tegen een dergelijke aanval het uitschakelen van het direct uitvoeren van code bij de installatie van software is. Daarnaast is het verstandig om zelf een lijst van vaak verkeerd gespelde packages op te stellen en beheerders te waarschuwen als zij een spelfout maken. Ook het bijhouden van 404-meldingen van gefaalde installaties is een oplossing, zo stelt hij.

Reacties (60)

[CyBeRSPiN]

Vind het doodeng dat bij veel nieuwe frameworks de standaardwijze van installeren iets dergelijks is als:
'curl http://amazing-framework.com/install.sh && ./install.sh'

Dus geen enkele vorm van validatie dat het om een vertrouwde bron gaat..
En dan soms ook nog als root user uitvoeren..

Dan is dit inderdaad het gevaar dat nu mooi wordt gedemonstreerd.

[svane]

Ik snap eigenlijk niet zo goed wat hier het probleem mee is (afgezien van het gebrek aan https). Als 'amazing-framework.com' niet te vertrouwen is, is het sowieso gevaarlijk iets te downloaden.
Als 'amazing-framework.com' wel te vertrouwen is, is er niet zo veel aan de hand.

Ik hoor vaker dat die geen goede installatie-methode is, dus ik zal wel iets missen, maar geen idee wat het probleem is.

[mg794613]

Dit exact!

Gewoon dezelfde security flaw/issue maar via ander mechanisme. Dus wat de toegevoegde waarde is van zijn onderzoek (behalve zijn scriptie dit hij indient voor punten) weet ik niet.

[Diamondo25]

Dit is ook een intressante post over remote code execution via bash door middel van piping:
https://www.idontplaydart...rl-pipe-bash-server-side/

[Verwijderd]

je kan natuurlijk het "&& ..." aan het eind weglaten, dan word het niet uitgevoerd, kun je vervolgens eerst (met vi(m) ofzo) in dat .sh bestand kijken wat ie allemaal gaat doen.

Veel frameworks hebben zo'n sh (of ander soort) installatie script gewoon om het makkelijker te maken, niets mis mee toch, en als je een klein beetje weet wat je doet dan kun je dus ook zon script eerst downloaden, dan rustig bekijken, en dan pas draaien.

[CAPSLOCK2000]

Dit laat zien wat de nadelen zijn van repositories/appstores. Wat er in zo'n repo staat wordt vaak blind vertrouwt door de gebruikers. Soms is dat terecht maar meestal niet. Jan en alleman heeft tegenwoordig een appstore en iedereen wil zo veel mogelijk software in z'n repo. Het kan haast niet anders dan dat de kwaliteit daar onder leidt.

In de wereld van de Linux-distributies zijn appstore/repositories meestal niet direct toegankelijk voor programmeurs. Het niet de auteur van de software die de applicatie opneemt in de appstore, dat wordt typsich door medewerkers van de distributie gedaan. Die zorgen als het goed is voor kwaliteitscontrole en voorkomen dat er misbruik wordt gemaakt van het systeem.
Als een pakket wordt toegevoegd dan komt het typisch niet direct beschikbaar voor eindgebruikers. Meestal zit er nog een extra stap tussen waarbij het pakket eerst beschikbaar komt voor beta-testers en andere ontwikkelaars en pas als het zich in praktijk bewezen heeft komt het in het repository voor normale gebruikers.
Het nadeel daarvan is dat het tijd kost, je loopt altijd achter de feiten aan. Het voordeel is dat je niet stiekem wat software in zo'n repo kan stoppen. Meestal duurt het een paar weken en hebben verschillende mensen er naar gekeken voor het algemeen beschikbaar wordt.

[Verwijderd]

Dit laat zien wat de nadelen zijn van repositories/appstores. Wat er in zo'n repo staat wordt vaak blind vertrouwt door de gebruikers. Soms is dat terecht maar meestal niet.
...
Als een pakket wordt toegevoegd dan komt het typisch niet direct beschikbaar voor eindgebruikers. Meestal zit er nog een extra stap tussen waarbij het pakket eerst beschikbaar komt voor beta-testers en andere ontwikkelaars en pas als het zich in praktijk bewezen heeft komt het in het repository voor normale gebruikers.
Het nadeel daarvan is dat het tijd kost, je loopt altijd achter de feiten aan. Het voordeel is dat je niet stiekem wat software in zo'n repo kan stoppen. Meestal duurt het een paar weken en hebben verschillende mensen er naar gekeken voor het algemeen beschikbaar wordt.

Ik snap het even niet. Jij zegt dat dit de nadelen van repo/appstores zijn. Van jou voorbeeld kan ik alleen de voordelen van zien.

[CAPSLOCK2000]

De Linux-repositories zijn de positieve uitzondering, die hebben een aantal zaken wel goed geregeld die elders vaak ontbreken. Excuses als dat niet duidelijk was.

[WouterH]

Goed gevonden van die student.
Bewijst meteen hoe vaak er commands worden uitgevoerd met een beheerders account wat overbodig is.

[xoniq]

apt-get install <insert pakket naam hier>

E: Kon het vergrendelingsbestand '/var/lib/dpkg/lock' niet openen - open (13: Toegang geweigerd)
E: Kan de beheersmap (/var/lib/dpkg/) niet vergrendelen. Heeft u beheerdersrechten?

[kidde]

Dat is niet zo'n probleem, want in de apt-get "standaard repo's" zitten doorgaans alleen door "pakket beheerders" goedgekeurde pakketjes.

Volgens mij doet apt-get ook aan md5 controle berekening. Zolang je niet zomaar repositories toevoegt niet super gevaarlijk.

Node.js pakketjes daarentegen, kunnen ook als user worden geïnstalleerd ; geen reden dat als root te doen.

[xoniq]

Ik snap je punt, maar vaak ontkom ik er niet aan om voor een bepaald pakket toch repos te moeten toevoegen. En daar kan het gewoon voorkomen. Of iemand anders die de repo weet te hijacken oid. Feit is dat je voor zulke commando's wel root of sudo nodig hebt wat het nou juist zo gevaarlijk maakt als je een Linux beginner bent die los gaat met toevoegen van repos om allerhande software uit te proberen.

[CAPSLOCK2000]

Feit is dat je voor zulke commando's wel root of sudo nodig hebt wat het nou juist zo gevaarlijk maakt als je een Linux beginner bent die los gaat met toevoegen van repos om allerhande software uit te proberen.

Echte beginners doen dat niet vanaf de commandline, die gebruiken die GUI. Op een modern systeem gaat dat via package-kit en hoef je geen root-accoount te hebben als jouw user-account maar de juiste rechten heeft.

Voor een beginner is het typisch ook niet nodig om allerlei repositories toe te voegen, de meeste distributies hebben zat software in hun standaard-repository zitten.

Wel is het zo dat het in praktijk vaak fout gaat omdat beginners niet weten hoe het werkt en hun gewoontes van andere besturingssystemen meenemen. Ik bedoel dan oa het idee dat je software verkrijgt door naar de website van de auteur te gaan of de gewoonte om altijd de nieuwste versie te installeren terwijl in 90% van de gevallen de versie die je distributie levert ook wel voldoet en vaak beter integreert met de rest van je systeem.
Dat bedoel ik allemaal niet als verwijt, Linux heeft een heel ander aanpak dan andere systemen, met voor- en nadelen, en daar zal je mee moeten leren werken.

In mijn ervaring zijn de echte noobs geen probleem. Die doen het met wat het systeem levert. De tweakers, die zijn gevaarlijk , die gaan met hun vingers overal aan zitten, drukken op alle knopjes en verbouwen alles wat los en vast zit, of ze nu snappen wat ze doen of niet Ze zijn gewend dat ze alles van Windows/MacOS weten en proberen direct op hetzelfde niveau te functioneren onder Linux. Als een F1-coureur die in een straaljager stapt...

[xoniq]

Echter; toen ik nog een Linux noob was en Linux nog niet draaide omdat het praktisch is, maar omdat ik het 'cool' vond toen was het kwestie van copy-paste commando's van websites die dat als handleiding vermelden bij hun applicatie. Ram die 4 regels in een terminal en de applicatie is geïnstalleerd.

"Fak! Dat is handig en snel!"

En zo begon m'n CLI liefde.

[kidde]

Begrijpelijke reactie, maar ik zie het probleem toch net iets anders:

Gentoo, OpenBSD of zelfs Android gebruikers zijn gewend dat packages uit standaard repositories veilig zijn en niet tijdens installatie het systeem al kunnen hacken.

De Node en pip package manager kunnen dat blijkbaar wel!

Als ik op Windows iets op internet zoek om te installeren ben ik veel meer op mijn hoede, want gewend aan malware virustroep downloads. Dus een Windows gebruiker die NodeJS gebruikt zal achterdochtiger zijn dan de gemiddelde niet-paranoide Linux-gebruiker ben ik bang, en die Linux gebruiker moet dus bewust worden van het verschil tussen pkg_add / emerge /apt-get en pip/node.

[DeerDitch]

In mijn ervaring zijn de echte noobs geen probleem. Die doen het met wat het systeem levert. De tweakers, die zijn gevaarlijk , die gaan met hun vingers overal aan zitten, drukken op alle knopjes en verbouwen alles wat los en vast zit, of ze nu snappen wat ze doen of niet Ze zijn gewend dat ze alles van Windows/MacOS weten en proberen direct op hetzelfde niveau te functioneren onder Linux. Als een F1-coureur die in een straaljager stapt...

Je houdt een grote spiegel voor... en ik zie mezelf staan
Later toch maar eens een boek aangeschaft om te leren hoe het nu echt in elkaar steekt. Ook al zijn er zo veel verschillende websites waar allerlei dingen over Linux worden uitgelegd, een boek over hoe het nu allemaal een beetje werkt is toch 10x beter.

[Bor]

Dat is natuurlijk volkomen kul. Op Windows kun je prima werken zonder Administrator rechten. In dat oogpunt is het helemaal niets anders dan een ander OS zoals bijvoorbeeld Linux. Het issue zit hem veel meer in gewenning doordat elke gebruiker in het verleden standaard lokaal administrator was.

[Patriot]

De commands die hier het doelwit zijn worden op Linux ook praktisch "standaard" als beheerder uitgevoerd. Ik denk dat het voor menig Linux gebruiker haast vreemd is om apt-get install niet voor te gaan met sudo.

[WouterH]

en ook meteen de UAC uitzetten want dat is allemaal overbodig en moet je zo vaak klikken

[Soldaatje]

De beste verdediging is geen malware pakketten toe te laten tot de repositories.

[DukeBox]

Oftewel je volledige vertrouwen bij een externe partij neer te leggen ? Lijkt mij niet zo verstandig.

[84hannes]

Dat doe je nu ook al. Je installeert een package van een externe partij via een externe repository. Als je een van beide partijen niet vertrouwd moet je dit niet doen.
Natuurlijk is fouten maken een ander verhaal, maar als ik vanaf de Mozilla website het programma firefox.exe download, dan verwacht ik ook niet dat er een lijst met opties komt waar firefoks.exe (een malafide versie die malware installeert, maar verder hetzelfde lijkt te doen) tussen staat.

[Verwijderd]

Wat als de website van Mozilla wordt gehackt en de downloads vervangen worden door firefoks.exe? Als eindgebruiker ben je zelf verantwoordelijk voor je eigen beveiliging, dus in theorie ik ben met DukeBox eens maar om eerlijk te zijn, in de praktijk doe ik meestal op jou manier, de leveranciers vertrouwen dat hun spul goed werkt/ geen malware bevatten. OK klikken, volgende, volgende, klaar.

[84hannes]

Als de website van Mozilla wordt gehackt dan zetten ze een nieuwe Firefox.exe neer. Ze gebruiken het certificaat van Mozilla, ze updaten de md5 checksums: er is niets dat ik kan doen om te voorkomen dat ik malafide software download. Een stap verder gaat het als de Windows Update server of een Linux-repository wordt gehackt. Je kunt bijna niets voorkomen. Je vertrouwd de aanbieder.

[Reactie gewijzigd door 84hannes op 23 juli 2024 14:38]

[Toff]

Als de website van Moziall wordt gehackt dan zetten ze een nieuwe Firefox.exe neer.

Als je op die website zit, dan is het kwaad al zo goed als geschied.
Dit soort spelfouten is precies waar het artikel over gaat.

[Reactie gewijzigd door Toff op 23 juli 2024 14:38]

[84hannes]

Ja, daar kan je wel zelf op letten. Aangepast.

[Cerberus_tm]

Het is het verstandigst om elke exe die je downloadt even door Virus Total te halen. Dat heeft een programma'tje waarbij je rechts kunt klikken op een exe-bestand en dan "check on VT" kunt doen. Eerst wordt de hash opgestuurd naar VT, en, als VT die kent, krijg je ogenblikkelijk resultaat. Anders wordt het bestand geüpload en moet je wat langer wachten maar krijg je daarna ook automatisch een pagina met de resultaten van VT.

[lololig]

Worst case scenario: hash is hetzelfde maar andere functie (kan toch? Hangt wel af van je manier van hashen) heb je alsnog een virus oid te pakken. Of nog mooier: VT is zelf gehackt en geeft gewoon terug dat t ok is

[Cerberus_tm]

Als je een beetje een lange hash gebruikt – en ik neem aan dat VT niet gek is en dat wel doet – kan dat inderdaad in de praktijk niet (kans van 1 op de oneindig triljoen). VT kan inderdaad zelf gehackt worden, ja. Maar wat dan nog? Het is veel beter dan niet checken. Het is overigens in handen van Google en lijkt goed geregeld te zijn.

[Verwijderd]

Tenzij je zelf de broncode nagaat leg je per definitie vertrouwen bij een externe partij... dat moet ook denk ik wel om het leven een beetje praktisch te houden.
Zelfs als je broncode kan lezen en interpreteren en er praktisch dus geen bezwaar is is het niet te doen alles van a tot z door te lichten in je uppie gezien de hoeveelheid code waar een moderne applicatie uit bestaat. Laat staan een OS.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 14:38]

[DukeBox]

Oh zeker, ik werk ook zelf niet anders maar het was ook meer bedoeld als reactie op 'beste verdediging', dat is gewoon niet zo.

[PoweRoy]

En wie gaat dat controleren? Als een package (maker) compromised is, en hier een wijziging in wordt gemaakt?

Leuk idee, maar een lijst van verkeerde gespelde packages bijhouden is onbegonnen werk. De andere oplossing zijn een beter idee (als ze genoeg bescherming bieden)

[FreezeXJ]

Je hoeft ook geen lijst te maken, gewoon een levenshtein-algo op alle nieuwe packages om te kijken of ze lijken op de huidige. Zo ja: refuse. Dan heb je er al best wat uit.

[jerkitout]

Gewoon een Evil bit gebruiken

[wauwwie]

Je bedoelt dat de beste verdediging door de repository gedaan moet worden, en dat deze niet bij jezelf hoort te liggen? En wie gaat de repositories dan controleren? Want dat is nou juist het mooie ervan, iedereen kan zijn werk daarin publiceren en iedereen kan het controleren.

[Stoelpoot]

Moet dat repository dan altijd gesloten zijn, en eerst elke package-update geanalyseerd worden? Moet er dan één repository zijn voor een bepaald package-management systeem? Dan kan dat systeem dus packages uisluiten op basis van voorkeur of overtuiging. Daarnaast, hoe controleer je of een pakket malware is? Moet je dan de code doorzoeken? Of moet een onderzoeker het pakket gaan gebruiken? Hoe weet je of die onderzoeker alles heeft gevonden? En als er dus controle op het repository komt, hoe wordt de controle betaald? Moet je gaan betalen voor packages? Of voor publicatie?

[Ayporos]

En wie gaat bepalen of jou browser toolbar of computercleaning utility malware is of niet?..
Klinkt als enorm tijdrovend en onnodige gebruikersbescherming.
Iemand die via de commandline vanaf een administrator account installaties uitvoert vanuit repositories moet maar leren eerst te kijken wat hij getypt heeft alvorens op enter te drukken.

Dat mensen beschermd moeten worden van kwaadwilligen snap ik, en ik snap ook dat je virussen ed. wilt weren uit softwareverspreidings-services maar je moet mensen ook wel de kans geven om van hun fouten te kunnen leren. Ik heb lang geleden (jammer genoeg) ook met harde hand moeten leren om back-ups te maken van mijn bestanden en dat ik niet zomaar kon doen en laten wat ik wou; als kind meer hdd ruimte nodig dus ik dacht "die windows map neemt wel veel ruimte in beslag..."

[Annihlator]

"Klinkt als enorm tijdrovend en onnodige gebruikersbescherming." < Dit.
Het wordt tijd om gebruikers op te lijden in plaats van te zorgen dat we 90% meer werk krijgen zodat "zij" 10% "minder moeite kunnen doen". (Waarbij het "kunnen" de ware misconceptie is...)

[Verwijderd]

Ja, precies. Walled garden is zo veilig blijkt maar weer.

[rolandlub]

Bestaat er iets als een community based repository white-list?
zodat als je iets verkeerds typt de command niet word uitgevoerd.
Dat zou voor de meeste mensen ideaal zijn.

[kimborntobewild]

Liever een trusted party die een whitelist bijhoudt; een community based white-list is vaak eenvoudig(er) te 'hacken' door met een groepje andere criminelen iets te whitelisten wat niet gewhitelist hoort te worden.
Natuurlijk moet je nog wel zelf kunnen beslissen of je van de whitelist gebruik wilt maken of niet.
Verder moet je rekening houden aan versie-beheer: zonodig whitelisting (automatisch) wissen worden zodra er een nieuwe versie van hetzelfde programma arriveert (evt. optionele uitzonderingen inbouwen als dat kan, zoals filteren op diegene die de nieuwe versie geplaatst heeft).
Kan best complex worden.

[Reactie gewijzigd door kimborntobewild op 23 juli 2024 14:38]

[Bor]

Community based zegt helemaal niets over veiligheid of security. Sterker nog, wanneer iedereen invloed heeft op een dergelijke repository of lijst zou het zelfs onveiliger kunnen zijn dan een lijst of repository die door een beperkte hoeveelheid mensen wordt bijgehouden (inclusief controle en handhaving).

[himlims_]

pip ... ranzig package management systeem; geeft veeel te weinig feedback aan user, controlleerd niet op afhankelijkheden, een halve installatie krijg je niet eenvoudig ongedaan gemaakt, en 'god mag weten' wat er gebeurd (bron/uitvoer/toepassing etc.)
wat via pip gaat ... komt er hier niet op. bijna net zon gedrocht als npm - BAH

daarom altijd controleren wat je lukraak kopieert / plakt in een terminal - beetje pech kopieer je hidden-karakters/opdrachten mee zonder dat je door hebt. http://thejh.net/misc/website-terminal-copy-paste

- knip -

Admin-edit:

Opmerkingen over moderaties horen thuis in Frontpagemoderatie.

[Reactie gewijzigd door Bor op 23 juli 2024 14:38]

[geekeep]

maar dat men handig misbruik maakt van laksheid users

Ik zou niet durven stellen dat typefouten iets te maken heeft met (bewuste) laksheid. Het is eerder een kwestie van niet weten/dyslexie, stress/druk, dikke vingers of gewoon een irritant toetsenbord.

Daarnaast kun je deze voorgaande factoren uiteraard minimaliseren door het te (dubbel)checken, maar het is niet voor niets dat je geschreven/getypte stukken door een ander moet laten controleren omdat je gewoon blind bent voor je eigen fouten. Ik durf te wedden dat jij hier ook wel eens slachtoffer van bent, ongeacht de mate van laksheid.

Technologie moet gewoon in het teken staan van de mens, in plaats van andersom. Als men blijkbaar typefouten maakt bij het installeren van packages, is het wellicht verstandig vóór het installeren een logo, uitgever en website/bron (MD5!) weer te geven als een extra check voor de gebruiker.
Om precies dezelfde reden download ik geen software van bijvoorbeeld Sourceforge/Cnet/Softonic/etc., maar ga ik gewoon naar de site van de uitgever. Als de uitgever geen eigen website in beheer heeft, ga ik op zoek naar een alternatief.

[mg794613]

Of niet intikken van commando maar scripten en die dubbel controleren. Sorry dat ik het zeg, maar als jij als user sudo/admin rechten heb, dan moet je HEEL goed kijken wat je doet. OF accepteren dat je COMPLEET verantwoordelijk bent.

Een "sudo rm -rf /" kan ook een typo zijn. Is rm nu inherent slecht? Nee, het is zoals bijna altijd gewoon de verantwoordelijkheid van de user.

[Jerie]

Een goede reden om virtualenv te gebruiken. Makkelijke howto.

daarom altijd controleren wat je lukraak kopieert / plakt in een terminal

Mwah. Dan moet je mensen ook zeggen dat ze evil.sh en blaat.c en moo.rb en beh.py moeten checken. Daar moet men Sh en C en Ruby en Python voor kennen. Dat is onbegonnen werk.

Sommige howtos geven de suggestie om met programmas als cURL en Wget bepaalde scripts te downloaden (niet alleen in Sh!), en executen ze dan meteen. Terwijl er niet eens gebruik wordt gemaakt van HTTPS! En zelfs HTTPS biedt geen zekerheid. Dan wordt het ook nog als root uitgevoerd (alhoewel voor een goede backdoor toegang tot de user account ook genoeg zal zijn).

[Reactie gewijzigd door Jerie op 23 juli 2024 14:38]

[RoestVrijStaal]

Tegenwoordig worden ook letters die soortgelijke klanken in een taal hebben verwisseld (met name c, q voor de k-klank of z voor s klank) waardoor dit soort aanvallen gemakkelijker worden.

[GateKeaper]

Bewust worden verwisseld wel te verstaan. Domeinnamen worden regelmatig gespeld op de radio, omdat ze afwijkende letters hebben. Zoals "Current", met een Q. Of "Girav" in plaats van "Giraffe". Hier gaat het dan niet om software, maar het principe blijft.

[maxplanck]

Kan er ook onwillekeurige code worden uitgevoerd of doet het systeem zo maar wat?

[init6]

Pipe it to bash!
https://github.com/barn/curlbrash

[Reactie gewijzigd door init6 op 23 juli 2024 14:38]

[xoniq]

* xoniq opent zoiets in browser vooraf *

#!/bin/sh

set -e

gitrawurl='https://raw.githubusercontent.com/barn/curlbrash/master/curlbrash'

if [ $(id -u) -ne 0 ]
then
echo "Need to be root"
exit 10
fi

echo "Really, this is what you're doing?"


curlloc="$(/usr/bin/which curl)"

if [ $? -ne 0 ]
then
echo "Failed to find curl"
exit 20
fi


tempfoo=`basename $0`
TMPFILE=`mktemp /tmp/${tempfoo}.XXXXXX` || exit 1

curl -s -L -o "${TMPFILE}" "${gitrawurl}"

mv "${curlloc}" "${curlloc}.orig"

sed -e "s^XXCURLLOCATIONXX^${curlloc}.orig^" <"${TMPFILE}" >"${curlloc}"
chmod 0555 "${curlloc}"
rm "${TMPFILE}"

echo "Irony complete. No more 'curl | sudo sh' for you!"

Geniaal script
(Maar hij maakt wel netjes een backup file )

[init6]

Meer hier: https://youtu.be/B4ra9_KnMdk?t=12m9s

[Bor]

Deze methode is an sich helemaal niet nieuw. Eerder zagen we al soortgelijke dingen bij mobiele apps en ook websites met een url op basis van typosquatting worden al langer voor het verpreiden van malware gebruikt, bv in samenwerking met een exploitkit.