Ars Technica kampte met defacement

Technologiesite Ars Technica kampte maandagnacht en dinsdagochtend kortstondig met een defacement. De frontpage ging op zwart en toonde de Twitter-accounts van de vermeende daders van de bekladding.

De voorpagina van Ars Technica bestond iets voor middernacht Nederlandse tijd uit een zwart scherm met de tekst Ars Security. Daaronder stonden de Twitter-accounts @nidohax en @metapawd vermeld, met onderschrift 'cue the music'. Op de achtergrond klonk muziek van waarschijnlijk Dual Core.

De beheerders van Ars Technica wisten de bekladding snel ongedaan te maken en er zijn geen aanwijzingen dat het om een hack ging. Onduidelijk is hoe de daders achter de defacement te werk gingen. Het leek in ieder geval niet om de Syrian Electronic Army te gaan. Deze groepering hield in het verleden regelmatig huis met defacements, dns-aanvallen en hacks.

Reacties (64)

[orf]

De beheerders van Ars Technica wisten de bekladding snel ongedaan te maken en er zijn geen aanwijzingen dat het om een hack ging.

Is een defacement niet een vorm van hacking?

[Reactie gewijzigd door orf op 23 juli 2024 02:50]

[Blokker_1999]

hangt er van af hoe ze het gedaan hebben.

[Royale de Luxe]

Daar hangt toch niets vanaf. Ze hebben de lobby van het digitale gebouw beklad. Het zijn in dit geval toch op zijn minst Graffiti gasten die zich op onrechtmatige manier toegang hebben verschaft.

[dunpealhunter]

Ik vraag me af of sommige websites (ik zeg niet dat Ars Technica daar een van is) niet zeggen dat ze gehackt zijn, maar het zelf gedaan hebben om wat meer publiciteit te krijgen.... Zelf heb ik namelijk nog nooit gehoord van Ars Technica tot vandaag, en dat zal wel voor een heleboel mensen hetzelfde zijn. Maar na zo'n "hack" zal er wel een heleboel extra mensen naar die website toe gaan alleen om het feit dat ze zojuist in het nieuws zijn geweest.

[Maurits van Baerle]

Om er als spuit elf nog even achteraan te komen, Ars Technica staat bij mij op eenzame hoogte samen met AnandTech als het gaat om hoge kwaliteit origineel materiaal. Niet wat press releases copy-pasten maar lange uitgebreide reviews (de beroemde John Siracuse reviews van OS X bijvoorbeeld, de laatste besloeg 25 pagina's!), diepgaande artikelen geschreven door echte sector experts en niet de redacteur-van-de-dag etc.

En niet alleen de originele artikelen zijn de moeite waard, ook de commentaren zijn vaak van een absurd hoog niveau. Het is niet ongebruikelijk om onder een artikel over ruimtevaart echte raketwetenschappers te zien reageren, onder een artikel over een sterrenstels echte astronomen te zien reageren of onder artikel over een nieuwe processors echte chipdesigners te zien reageren. Er is vaak veel theoretische kennis aanwezig maar ook veel praktijkervaring van mensen die ooit een bedrijf in die richting hebben gerund of ooit producten in die markt hebben verkocht. Wat reacties van experts betreft heeft Ars het wat mij betreft overgenomen van Slashdot (maar dan zonder het kinderachtige deel van Slashdot).

[Reactie gewijzigd door Maurits van Baerle op 30 juli 2024 06:01]

[enomiss]

Helemaal mee eens. En mag daaraan toegevoegd worden dat ze vrijwel altijd objectief schrijven. Minstens zo belangrijk. Ze kiezen bijvoorbeeld niet het Apple/Google/Microsoft kamp. In tegenstelling tot The Verge waar Apple bijvoorbeeld aanbeden wordt, en Microsoft continue de grond in geboord wordt.

[Matushki]

Ars Technica was jarenlang een van de hoog gewaarde technologiesites met veel en goede hardware reviews. Is bij mij uit beeld geraakt afgelopen jaren (Tweakers.net ). Maar zeker geen onbekende site dus.

[Verwijderd]

Ars Technica was jarenlang een van de hoog gewaarde technologiesites met veel en goede hardware reviews. Is bij mij uit beeld geraakt afgelopen jaren (Tweakers.net ). Maar zeker geen onbekende site dus.

Tweakers gebruikt ARS met regelmaat als bron voor nieuws, moet je niet uit het oog verliezen als je IT serieus neemt.

[wankel]

[...]
Tweakers gebruikt ARS met regelmaat als bron voor nieuws, moet je niet uit het oog verliezen als je IT serieus neemt.

Is dat niet de reden dat er sinds ergens (?) in 2006 geen bronvermelding meer in de kop van het artikel opgenomen is? Beetje jammer als iedereen de hele tijd ziet dat de helft van het nieuws van dezelfde site overgenomen is...

[Bunga]

Dan raad ik je aan om daar dringend eens naar te kijken. Het is een van de betere sites met een breed interessegebied (technologie, genetica, astronomie, IT, ...) maar vooral IT. Ze brengen regelmatig wat diepere artikels ipv te copy&pasten van andere sites. Mag niet in je bookmarks mankeren als je ook op tweakers zit maar dat is mijn mening

[coolmos]

Ik denk toch echt dat de meeste tweakers Ars Technica wel kennen. Wel iets meer dan zomaar een nieuwssite.

[biteMark]

Ars Technica is een grote techsite die alweer een poosje in de lucht is en een vrij goede reputatie heeft hoor.. Het is niet echt het onopvallende nieuwkomertje van de klas. Ook hier op Tweakers komen regelmatig nieuwsberichtjes voorbij waarin Ars Technica als bron word genoemd. Zij hoeven geen aandacht te trekken met een hack.

Daarbij komt dat een hack zeker niet garant staat voor aandacht, laat staan extra bezoekers! Er worden dagelijks sites gehacked en gedefaced, maar over lang niet alle gevallen word geschreven omdat het relatief kleine of onbekende websites betreft. Als Ars Technica een kleine site was geweest, hadden ze dus alsnog niets gehad aan een (zelf opgezette) "hack".

[Verwijderd]

Een beetje tweaker kent Ars wel.

Het is ook een grote site met Alexa worldranking 1242
Ter vergelijking, tweakers heeft alexa worldranking 3399

[- peter -]

Grappig, dat is juist de enige site die ik al jaren naast Tweakers bezoek. Veel diepgaande artikelen en een beetje echte onderzoeksjournalistiek.

[gjmi]

Misschien was het wel iemand die legaal toegang had? Een ontevreden medewerker? Dan is er niet onrechtmatig toegang verschaft.

[Fleximex]

Misschien zijn ze bij een rondleiding door het kantoor van Ars Technica snel even in de server ruimte geweest en een eigen index pagina op de server gezet

[A64_Luuk]

Je zult toch echt toegang tot de server moeten hebben, dus dat zou je haast zeggen.

[gertvdijk]

Ja, dat denk ik ook. DNS was stabiel en het leek erop dat in elk geval één, maar niet alle backend servers achter de load balancer waren gecompromitteerd. Volledige verhaal van wat ik gezien heb hier op Reddit: https://www.reddit.com/r/...rstechnica_hacked/cmvx3cg

[WhatsappHack]

Dat kan ook gewoon zijn dat die server "web08" gewoon nog een oude cache ingeladen had staan die de defaced page nog niet had...
Dat zegt natuurlijk echt nog helemaal niets, het hoeft zelfs niet eens zo te zijn dat er uberhaupt ook maar 1 enkele server zelf (op OS niveau dus) gecompromiteerd was. Toegang tot de front-end is voldoende, en dat staat niet gelijk aan toegang tot de complete server!

Stel jij krijgt toegang tot de admin module van het CMS dat ze gebruiken; maar er zit een load balancer tussen. Ze gebruiken voor caches ook het geheugen van de server of lokaal per server een "file on disk". Nu klik je eenmaal op "clear cache". De cache op web01 wordt gedumpt en de defaced pagina verschijnt als je via web01 de website op je PC krijgt, maar de cache op web08 werd nog niet gedumpt en bleef dus vrolijk de normale index tonen omdat die gecached stond; en dat is wat de server web08 dus netjes bleef tonen... Immers had het dan geen instructie gehad om de cache te dumpen. (En het had ook vice versa kunnen zijn, bijvoorbeeld wel op web08 gedumpt maar niet op web01. (Of op welke willekeurige server dan ook... Punt blijft: als op slechts 1 server de cache wordt gedumpt, blijft de rest wel de cached pages versturen... Zonder defacement dus. Pas als op alle servers de cache geleegd zou zijn zou de deface vanuit alle servers achter de load-balancer getoond worden, zolang dat niet gebeurd niet.))

Als de cache normalitair enkel wordt opgeschoond als er een nieuw artikel wordt geplaatst bijvoorbeeld, dan kan het best een tijdje duren voordat beide/alle servers de defaced pagina tonen... Als de cache een TTL (Time To Live) heeft van, ik noem maar wat, een uur: dan tonen die andere servers dus een uur lang geen defaced pagina, maar nog gewoon de index zoals die gecached werd *voordat* de deface plaatsvond. Snapje? Pas als de cache vernieuwd moet worden zullen die servers ook de defaced page tonen.

Ik snap wat hij zegt in die link, maar zijn conclusie/jou conclusie kan niet worden beschouwd als "er is een server gecompromiteerd" of "er is slechts 1 server gecompromiteerd". Dat is een foute aanname, zolang er geen bewijs is, tenzij je de back-end van hun site kent en weet hoe hun caching mechanisme werkt.

[Reactie gewijzigd door WhatsappHack op 30 juli 2024 06:01]

[unglaublich]

Aannames aannames aannames,je hebt zojuist het web-server park van Ars Technica uit je duim gezogen, daarna naam je gertvdijk kwalijk aannames te doen.

En ook dan klopt je verhaal niet. Waarom zou je in je back-end een 'cache legen' optie maken die alleen op de huidige server werkt? Dat laat je toch overduidelijk door alle servers oppakken.

[WhatsappHack]

Aannames aannames aannames,je hebt zojuist het web-server park van Ars Technica uit je duim gezogen, daarna naam je gertvdijk kwalijk aannames te doen.

Nee dat heb ik niet, je moet beter lezen. Ik zeg helemaal niet "dit is wat er gebeurd is" of "ik neem aan dat dit gebeurd is", ik geef enkel wat er gebeurd KAN zijn.

Ik verwerp enkel de aanname dat er slechts 1, of uberhaupt ook maar 1, server gehacked zou zijn. Het kan ook heel goed zijn dat er helemaal geen enkele servers gehacked zijn op het OS niveau.
Die conclusie is veels te voorbarig.

Ik zuig dus helemaal niets uit mijn duim, ik geef enkel aan dat er situaties zijn waarbij er helemaal niets op server niveau gehacked was... En dat kan met een cache. Of dat ook zo is en dat dit is wat er aan de hand is geweest weet ik natuurlijk niet, maar die claim maak ik ook helemaal niet...

En ook dan klopt je verhaal niet. Waarom zou je in je back-end een 'cache legen' optie maken die alleen op de huidige server werkt? Dat laat je toch overduidelijk door alle servers oppakken.

Mijn verhaal klopt perfect, gewoon de uitleg beter lezen.
Dat zo'n knop het liefst de cache zou legen op alle servers is correct, maar dat betekend niet dat het 't geval is. Het kan zelfs zo maar zijn dat die knop er helemaal niet is, maar dat ze dit automatisch doen of enkel als er een nieuw artikel geplaatst wordt. En als op de ene server de TTL eerder verstreek dan op de ander, heb je ook al een cache die niet helemaal overeenkomt. (En dat gebeurt nog bij best veel sites, dat soms als je refreshed een bepaald deel toch even iets anders is dan op de andere server tot ze weer synchroon lopen.)

Kortom: scenarios zat waarbij wat ik hier aangeef prima mogelijk is...
Een knopje is slechts een mogelijkheid, denk even wat verder na en hou in je achterhoofd dat ik slechts 1 voorbeeld gaf van een situatie die ook mogelijk is... Er zijn nog wel meer mogelijkheden.

Misschien heeft Gert wel gelijk, maar misschien ik wel... Zonder bewijs kan je het niet zeker weten, daarom moet je ook niet zeggen dat dit werkelijk is wat er aan de hand is... Dat geld voor zowel mij als Gert.
(Al heb ik nooit geclaimed dat wat ik net typte werkelijk gebeurd is.)

[Reactie gewijzigd door WhatsappHack op 30 juli 2024 06:01]

[gertvdijk]

Ik snap wat je bedoelt, maar de defacement duurde meer dan twee uur en Ars had intussen drie nieuwe artikelen geplaatst. (Zie ook timeline van hun Twitter account terwijl mijn output nog een defacement was op 'web01')

En ja tuurlijk is het speculatie, want ik weet niets over de infrastructuur van Ars, maar feit is wel dat de defacement niet voor iedereen gold op hetzelfde moment en uren aanhield.

[WhatsappHack]

Dat is inderdaad vreemd.
Het kan natuurlijk zo zijn dat de code van de site gecached wordt, maar de dynamische content (en "posts" worden gewoon in de database opgeslagen, niet in de code) niet of apart van de statische code. (Om I/O te besparen.) Dan verandert de dynamische content wel omdat de code die gewoon blijft ophalen uit de database of aparte cache, maar is de malicious code nog niet present op de andere server(s) en tonen die dus geen deface.

Dan hou je alsnog dat de ene server wel een defaced pagina toont, maar de ander niet; terwijl er nog steeds prima nieuwe artikelen kunnen verschijnen.

Van mij uit is het natuurlijk ook pure speculatie hoor, en we zullen wat dat betreft ook moeten wachten tot Ars Technica met een uitleg op de proppen komt. (Die trouwens wel verdomd lang op zich laat wachten...)

Als ik goed heb begrepen hoe de 'hack' in z'n gang is gegaan, dan denk ik niet dat er een back-end server gehacked is, maar enkel de software die ze gebruiken (CMS). Helaas kan ik daar verder niet over uitweiden en het is nog niet bevestigd, maar ik moet zeggen dat ik heel erg benieuwd ben, mede dankzij jou bevindingen.

[Reactie gewijzigd door WhatsappHack op 30 juli 2024 06:01]

[Kafka]

Jij hebt er echt veel verstand van.

[Verwijderd]

of een dns redirect...

[Ramon]

Nee want het forum draaide gewoon nog (op hetzelfde domein)

[ACM]

Het zou natuurlijk kunnen dat de login-gegevens van een account van hun CMS achterhaald was, waardoor er verder geen daadwerkelijke doorbreking van beveiling nodig was.

[WhatsappHack]

Dat is dan wel een beetje misleidend om het zo te stellen, omdat men nu denkt dat het "geen hack" is en dan vermoed dat er dus niets buit gemaakt zal zijn.

Dan is het weliswaar geen hack, maar als het een admin account is dan heb je alsnog de toegang tot een grote hoeveelheid data; zeker als je vervolgens bijvoorbeeld het voor elkaar krijgt om rotte code te injecteren en lekker met een shell oid aan de haal gaat en op je dooie gemakje de database dumpt.

Ja technisch gezien omdat ze met een correct wachtwoord inlogde was het dan misschien niet echt een hack, maar het effect is toch even smerig. ... En geen garantie dat er inderdaad niets gevoeligs gejat is.

[ACM]

Ik weet niet wat het wel of niet was. Maar zolang het 'onbekend' is, hoeft het niet per se een 'echte' hack te zijn geweest

[pietje63]

Ik denk het wel.

Ik las de zin als "er zijn geen gegevens buit gemaakt / geprobeerd buit te maken" en "er zijn ook geen virussen gehost". Maar naar mijn mening heb je gelijk.

[WhatsappHack]

Even een lijstje van de afgelopen week, voor zover mij bekend, en gelimiteerd tot dit segment:
- myBB
- Tapatalk
- phpBB
- Ars Technica (in relatie met de bovenstaande 3 vanwege het gebruik maken van open-source software op de front-end)

Het gaat lekker.
Het zou me weinig tot niets verbazen als ze allemaal op dezelfde wijze zijn gekraakt. En we weten reeds al hoe myBB gekraakt werd...

Lullig. Ik snap niet waarom mensen zo nodig dit moeten doen; en dan zeker niet bij opensource software projecten zoals myBB en phpBB die draaien op vrijwilligers die keihard werken.

[Reactie gewijzigd door WhatsappHack op 30 juli 2024 06:01]

[Olaf van der Spek]

Wat ik eigenlijk niet begrijp is waarom dit probleem nog steeds niet structureel is opgelost...

Injecties (SQL, input, output) zouden nu toch echt tot het verleden moeten worden.

[WhatsappHack]

Over het algemeen komen die ook steeds minder voor, en ik gok ook dat daar hier geen sprake van was. (Bij geen een uit dat lijstje.)

Het probleem met dit soort zaken is voornamelijk dat je "software on top of software hebt". (Al krijgt het originele pakket vaak de schuld Mensen kraken wordpress vaak af, maar het zijn 9 van de 10 keer de rotte plugins die gehacked worden, niet WP zelf)
Neem bijvoorbeeld WooCommerce voor Wordpress. Dat is eigenlijk een heel apart pakket an sich, maar het is toch een plugin omdat het, op een hoog niveau aan "clusterfuck" mag ik er wel bij zeggen, het de database en themes van WordPress gebruikt.

En zo gaat dat altijd met plugins.
Dan heb je de kans dat:
1.) De plugin op een bepaalde manier werkt waardoor er opeens een exploit ontstaat door semi-conflicterende code in het originele software pakket en de plugin. Unexpected behavior, en dat hoeft niet perse "de schuld" te zijn van 1 van beiden
2.) De auteur van de plugin heeft er een gat in laten zitten (Door een foutje of door onkunde)

Tegenwoordig zijn bij de grote softwarepakketten SQL injecties nog maar heel erg zeldzaam, althans: in de software zelf, plugins niet meegerekend dus.

[Reactie gewijzigd door WhatsappHack op 30 juli 2024 06:01]

[Crownable]

IP.Board had laatst ook een SQL injection vulnerability

[njitter]

De site draait op Wordpress. Kan hier mee te maken hebben: https://threatpost.com/go...g-soaksoak-malware/109884

[PolarBear]

Kan mij slecht voorstellen dat Ars Technica op wordpress draait. Echt niet.

[sjoerddebruin]

Kwestie van in de broncode kijken.

[PolarBear]

[njitter]

want? Niks mis met Wordpress.

[brommer]

Ars Technica draait zeker wél op WordPress. Je zou eens moeten weten hoeveel grote nieuwssites op WordPress zitten. Ook TechCrunch en The New Yorker bijvoorbeeld en bepaalde BBC websites. Ik dacht ook dat CNN op WordPress zat maar dat blijkt toch niet zo te zijn, ofwel zijn ze veranderd van platform.

[BaRF]

Ik had het woord 'Defaced' nog nooit gehoord en nu ineens 4x in één artikel

Nouja, zolang het dergelijke 'onschuldige' hacks zijn is het eigenlijk een vorm van waarschuwing dat de security niet in orde is, best aardige wake-up call dus

[Kafka]

Veel grote sites gebruiken al jaren Wordpress. Dit noemen ze Wordpress VIP. Custom made en onderhouden door Wordpress zelf.

[Power2All]

Waarschijnlijk een PHP code die misbruikt was.
Programmeurs met slechte PHP ervaring in beveiliging, is such a no-no xD

[WhatsappHack]

Volgens mij ben je er daar 1 van.
Staaf je mening? Waarom is dat namelijk zo waarschijnlijk in jou ervaring?

Er hoeft totaal geen code misbruikt te zijn. Of nouja... Niet in de zin van een remote exploit.
En dan nog hoeft dat ook niet te betekenen dat er slechte ervaring was, een 0day of bijv een exploit in een plugin kan nou eenmaal voorkomen; zeker bij talen als PHP. Dat zegt niet perse iets over de kwaliteit van de code, de ervaring van de beheerder of de (server-)beveiliging: met grote complexe PHP scripts kan dit nou eenmaal wel eens voorkomen, en dat overkomt letterlijk ook zelfs de top-experts op het gebied van programmeren... Kan je moeilijk betichten van weinig ervaring.

[Reactie gewijzigd door WhatsappHack op 30 juli 2024 06:01]

[Power2All]

Tja, ik draai al sites sinds 2003, waaronder wordpress, en host ze die veel publiek trekken.
Tot nu toe niks gehacked gehad, maar ik beveilig mijn PHP/NGINX configuratie tot op de bone.
Chrooting en jailed draaien die hap, en dagelijkse backups maken

Daarnaast, er is altijd 1 gouden regel in de coding scene: Vertrouw nooit wat een gebruiker aan data stuurt.
Helaas zie ik nog al te vaak SQL injections en scripts die bestanden openen in de base folder, en ik vermoedt dat laatste is gebeurd bij arse technica.
Daarnaast kun je dit soort irritante zooi al tegenhouden bij NGINX door te filteren op parameters.
Maar goed, PHP is super easy (ik code namelijk native mutli-threaded apps in PHP), als je weet waar je mee bezig bent

[WhatsappHack]

Dat zegt niets. Wel leuke trackrecord natuurlijk!

Maar voor zover bekend zitten er geen injection vulnerabilities in WordPress op dit moment. Thans, niet in de nieuwste versie.
Dat is dan ook niet van toepassing.

Het zou uit een plugin kunnen komen, maar dan zou er wel meer aan de hand zijn en zou er wel degelijk sprake zijn van "een hack". Nu wordt er gezegd van niet, dus gok ik meer op een compleet andere vector. Bijv. wachtwoord recycling of social engineering.

[Reactie gewijzigd door WhatsappHack op 30 juli 2024 06:01]

[Power2All]

Dat merken we vanzelf met informatie dat naar buiten komt.
Tja, plugins, gemaakt soms door programmeurs die geen rekening houden met hacks.
Wordpress core is dan misschien veilig, maar de plugins zijn altijd de zwakste schakel bij Wordpress.

[Crownable]

Als een PHP bug werd misbruikt dan hebben de PHP programmeurs het wel heel bond gemaakt.

[Power2All]

Zou me niks verbazen.
Dat is niet hacken, maar exploiten.

[koelpasta]

Is exploiten niet een specifieke vorm van hacken? Of, wat is hacken dan volgens jou?

[Power2All]

Exploiten is het gebruik maken van code waarvoor het niet voor bedoeld is.
Basically, een SQL injection is een SQL exploit, en je hacked in principe niet, gezien het blijkbaar gewoon in de code zit.
Hacken is meer gaten vinden in services waarvoor het niet bedoeld is (bijvoorbeeld het SSL debakel, waar je gegevens uitleest over andere gebruikers).
Met exploits kun je in principe "hacks" toepassen, maar de meeste exploits hebben niks met hacken te maken, maar wel toegang krijgen tot content waar je geen toegang op hoort te hebben.

Alhoewel exploits en hacken hand in hand gaan, zit er toch een splitsing in.
Hacken is het op grote schaal toepassen van exploits.
Een exploit is niet voldoende alleen om datgene te noemen wat je hacken noemt, het is een onderdeel van hacken:
http://en.wikipedia.org/wiki/Exploit_%28computer_security%29

[koelpasta]

Exploiten is het gebruik maken van code waarvoor het niet voor bedoeld is.

Dus als je een buffer overflow misbruikt om je eigen code te runnen dan ben je aan het exploiten maar niet aan het hacken?

Hacken is meer gaten vinden in services waarvoor het niet bedoeld is

Dus hacken is volgens jou van toepassing op 'services' maar niet op 'code'?

Hacken is het op grote schaal toepassen van exploits.

Dus iemand die met een disassembler uitzoekt hoe een enkele functie werkt is niet aan het 'hacken' maar aan het 'exploiten'?
En een persoon moet dus een hele batterij aan exploits gebruiken om onder de noemer 'hacker' te vallen?

Met exploits kun je in principe "hacks" toepassen,

Volgens mij dus andersom. Bij hacken kun je exploits misbruiken. Wat jij 'hacks' noemt heet gewoon 'exploits'. Exploits zijn specifieke zwaktes die je kan gebruiken bij het hacken. Hacken is de overkoepelende bezigheid, exploit is een specifiek gereedschap.

het is een onderdeel van hacken:

Oh, want ik dacht dat ik in mn vorige bericht al zei als reactie op deze uitspraak van jou:

Dat is niet hacken, maar exploiten.

Nu zeg je dus weer dat exploiten een onderdeel is van hacken....

Je bent aardig de zaken aan het ronddraaien om te proberen jouw interpretatie te staven.
Volgens mij probeer jij dingen gewoon veel te veel te los van elkaar te zien.
Van oorsprong is het woord hacken erg ruim gedefinieert. Dat is niet voor niets, het is een erg omvattend woord.
Hacken is gewoon klooien, proberen de materie machtig te worden, de uitdaging aangaan, state of mind.
Daarbij is het zoeken en (ge/mis)bruiken van exploits gewoon een gereedschap.
Een PHP bug misbruiken is dus zowel het toepassen van een exploit als ook hacken.
Sterker nog, de wiki pagina die je linkt suggereert hetzelfde. Exploits zijn gereedschappen van/voor hackers.

[koelpasta]

Lol, ik antwoordde nog steeds op jouw uitspraak:

Dat is niet hacken, maar exploiten.

Ga lekker stofzuigen of zo dan eerst alles weer om te draaien, en dan weer terug te draaien, door zogenaamd hetgene wat ik al zei, ineens als waar te maken, maar dat jij daarmee komt.
Ga toch fietsen gozer, je lult teveel.

Wordt je nu boos?

[WhatsappHack]

"en er zijn geen aanwijzingen dat het om een hack ging"

Hm, ik heb iets heel anders gehoord.
Ik ben benieuwd waar dat statement op gebaseerd is...?
Ik durf het bijna niet te vragen maar, wat is de bron van die conclusie?

[Reactie gewijzigd door WhatsappHack op 30 juli 2024 06:01]

[Kain_niaK]

https://www.youtube.com/watch?v=FoUWHfh733Y

Goed nummer

"'drink all the booze, hack all the things''

misschien wel meer iets voor vrijdagavond ...

[teacup]

Het leek in ieder geval niet om de Syrian Electronic Army te gaan. Deze groepering hield in het verleden regelmatig huis met defacements, dns-aanvallen en hacks.

Deze opmerking fascineert me bijna evenveel dan dat het SEA er wel mee te maken zou hebben. In het verleden heeft het SEA met onnavolgbare logica diverse hacks gepleegd.

De logica van SEA achtigen is zo onnavolgbaar dat ze misschien nog het beste is samen te vatten als "wie niet voor ons is, is tegen ons". Als SEA kan je dan wel aan de gang blijven, net als nieuwssites die in hun commentaar moeten blijven vermelden dat het niet het SEA was.

[Reactie gewijzigd door teacup op 30 juli 2024 06:01]

[WhatsappHack]

Als je elke site die een keer het slachtoffer wordt van een hack nooit meer zal bezoeken, dan kan je sowieso al vrijwel alle websites die Drupal gebruiken afschrijven, een heel groot aantal sites die wordpress gebruiken en nog wel een groot aantal websites die ooit wel een keer de l*l zijn geweest.
Je kan een aardig deel van 't web helemaal links laten liggen.

Dit soort dingen gebeuren nou eenmaal, deal with it.
Gewoon niet overal hetzelfde wachtwoord gebruiken en een mail adres speciaal om spam te verzamelen en je hebt helemaal nergens last van...

[Reactie gewijzigd door WhatsappHack op 30 juli 2024 06:01]

[Sharky]

Dan zou ik maar niet op tweakers.net komen als ik jou was. Jaar of wat geleden ook gehackt.