'Defacement' UPC blijkt door eigen ontwikkelaar te komen

Een Oostenrijkse ontwikkelaar van UPC blijkt verantwoordelijk te zijn geweest voor het vervangen van de indexpagina van de webmail. Aanvankelijk werd gedacht dat hackers erin waren geslaagd de website te bekladden met de tekst 'geh scheissn'.

Donderdagavond heeft provider UPC in allerijl zijn webmailfunctionaliteit even uit de lucht gehaald nadat de inlogpagina was vervangen. Na een uur werkte alles weer naar behoren. Naar nu blijkt was er geen sprake van een aanval, maar heeft een ontwikkelaar van het bedrijf vanuit Oostenrijk voor alle commotie gezorgd.

"Donderdagavond konden door een intern probleem korte tijd enkele pagina’s van de UPC-website niet worden bezocht, hieronder viel ook de webmailpagina van UPC", zegt woordvoerder Ronald Sutmuller van UPC tegen Tweakers.net. "Er is geen sprake geweest van een hack of aanval van buitenaf. Persoonlijke gegevens van onze klanten zijn niet in gevaar geweest."

Aanvankelijk werd gedacht dat het om een aanval van buitenaf ging, mede omdat er op Pastebin ook een bestand was verschenen met daarin de vermeende RSA-fingerprint van de server van UPC. UPC Nederland stelt echter dat onderzoek heeft uitgewezen dat dit onzin is.

"We hebben na iets meer dan een uur de hele website volledig kunnen herstellen, waardoor rond 20.00 uur de website weer volledig operationeel was. We werken op dit moment aan een gedetailleerde analyse van de situatie om herhaling te voorkomen en houden ons netwerk zeer nauwkeurig in de gaten."

Reacties (77)

[ktf]

Dus, de ontwikkelaar wilde zijn collega's even duidelijk maken dat hij nu even niet beschikbaar (lees: naar het toilet) was, maar hij deed dat op de verkeerde pagina? Normaal gesproken zet je dan even je telefoontoestel op afwezig of gebruik je daar andere middelen voor dan een vrij drukbezochte internetpagina, toch?

[pauluss86]

Lijkt me waarschijnlijker dat de ontwikkelaar tegen een probleem aanliep en deze tekst had ingesteld om weergegeven te worden op het moment dat er iets misging.
Ik gebruik ook wel eens puts("<random_scheldwoord>"); tijdens debuggen..

[Michaelr1]

Er sta toch echt ga schijten, niet gaan schijten..

[Verwijderd]

Toch klinkt dit wel aannemelijk. Als ik zie wat voor afgekort Duits er soms op IRC / games getikt wordt, kan ik me voorstellen dat hij even gauw wat wilde melden.

Kan natuurlijk ook gewoon dat hij boos was op z'n baas of zo

[DukeN]

Hehe best sterk

Je bent er in ieder geval wel zeker van dat je collega's het gezien hebben...

[Pep7777]

Niet het meest handig om als ontwikkelaar te doen.

Maar tegelijkertijd zijn dit dingen waar je je als bedrijf ook niet tegen kan beschermen, wat dat betreft ben je afhankelijk van je personeel en/of bedrijven die je inhuurt.

Ik heb eigenlijk geen idee hoe vaak dit gebeurt, en vind het redelijk speciaal dat dit naar buiten is gebracht. Meeste bedrijven houden dit soort dingen toch behoorlijk stil.

[cdoens]

Misschien brengen ze dit nu naar buiten om te laten zien dat het dus duidelijk geen externe hack is geweest.

[Martijn19]

Dit denk ik ook, al is beide gevallen niet echte optimale reclame:

"Onze ontwikkelaars hebben nogal een apart gevoel van humor"

of

"Onze ontwikkelaars hebben de website niet voldoende beveiligd waardoor de webmail index page vervangen kon worden"

Het eerste geval zal beter zijn, ook al zouden klantenbestanden niet toegankelijk geweest zijn dan zou door het grote publiek "webmail" + "hack" gelijk verkeerd opgevat worden.

[Roy Jones]

Maar hoe weten wij nou of dit wel of geen hacker is geweest?? you tell me.

misschien wil UPC geen gezeur van dat er informatie van klanten over het hele web te vinden is. dus zeggen ze dat het geen hacker is (Ofcourse) maar een eigen fout.

Maar we zullen wel zien,

( al zou dit een uit de hand gelopen grap zijn is dit niet heel erg slim)

[Verwijderd]

Ik denk wel een reden voor exit of officiële waarschuwing.

[Sinned123]

Voor 1 fout iemand ontslaan lijkt me niet handig.
Hij zal zijn hele carriere scherper zijn en je wilt dat de rest van jemedewerkers met 1 fout al bang zijn voor ontslag.
Bovendien lijkt het me juridisch nogal dun....

[418O2]

Dit is wel vrij episch...

"Geh scheissen"

teh fuck? Dit klinkt als een devvers-grap die uit de hand liep

[Orion84]

Oh, zat ik op productie...

...oeps

Maar even serieus. Als een devver zoiets op een productieomgeving kan doen, dan vraag ik me wel af hoe je change management proces in elkaar zit...

[Tarkin]

Soms is het gewoon nodig dat devvers snel iets op productie kunnen bekijken of testen. Als je dan niet oplet wat je doet, dan kan je fouten voorhebben ja

[Het.Draakje]

Als het nodig is om op productie te testen:

- dan heb je geen goede test omgeving (want dan had je de software fout daar al geconstateerd),
- geen goed test case bestand hebt,
- geen version control hebt,
- geen procedures om je productie(data) naar je test omgeving te kopieren,
- De bevoegdheden niet gescheiden zijn (regel desnoods leesrechten voor devvers, maar never, nooit, nimmer niet, schrijfrechten in produktie).

[Martin Sturm]

Lijkt me handig als je storingsdienst hebt en er gaat midden in de nacht iets stuk op je site met een paar miljoen pageviews per uur "ja, ik weet wel wat het probleem is, maar ja, kan het niet oplossen want ik heb geen schrijfrechten, sorry. Morgenochtend is het het eerste wat ik doe!".
Daarnaast is het ook gewoon zorgen dat je capabele developers in dienst hebt.

[Het.Draakje]

Ik loop ' s nachts storingsdienst. Waaronder voor websites, databases en mainframe batches. Ik heb het de afgelopen 10 jaar niet meegemaakt dat er een noodzaak was tot wijziging van een code buiten kantoortijd.

Capabele ontwikkelaars in dienst? Iedereen maakt fouten, ook een developer. En meestal is dat als het even snel moet. Of als je slaapdronken uit je bed gebeld wordt. Als je slaapdronken snel even iets moet fixen loop je dus het grootste risico. En dus is het dan juist verstandig om nog even een tweede collega in te schakelen die dan ook nog even kan kijken.

[CyBeR]

Capabele ontwikkelaars in dienst? Iedereen maakt fouten, ook een developer.

En ook systeembeheerders.

[Het.Draakje]

Uiteraard maken systeembeheerders ook fouten.Een systeembeheerder mag daarom nooit de de data en code kunnen wijzigen.

[borft]

gelukkig kan dat zo ongeveer altijd, hoe kan je anders een systeem beheren, als je er geen schrijfrechten op hebt?

[Yalopa]

Het is niet omdat je systeembeheerder bent dat je direct root / domein admin moet zijn...

[Liberteh]

Haha, laten we maar direct een beperkt Windows of Linux accountje opvoeren voor DE systeembeheerder, of niet dan?
Vergeet niet dat de systeembeheerder er juist voor zorgt dat een developer wel of geen schrijfrechten heeft. Een systeembeheerder heeft altijd ongelimiteerde toegang. Dan wel via een speciaal account waar hij/zij alleen op inlogt wanneer het nodig is.

Mocht ik dat niet hebben bij een toekomstige baan, dan zal ik daar niet in dienst komen. Ik moet mijn werk kunnen doen.

[David Mulder]

Ok... of je werkt met perfect software (kan niet) of je werkt voor relatief kleine lokale systemen of je kletst de grootste onzin. Als je een groot internationaal product hebt of bijvoorbeeld software voor magazijnen die gewoon echt 24/6-7 moet draaien (2 dingen waar ik direct of indirect ervaring mee heb) , dan maakt het niet uit wanneer een bug wordt gevonden, maar *moet* die gewoon direct gefixed worden. Het klopt dat het dan slim is om nog even met een collega dubbel te checken, maar om code alleen tijdens kantoortijden te wijzigen . Oh en, de code gaat er sowieso op vooruit als iets wordt gehotfixed, want erger dan een zware bug kan het sowieso niet worden (naja, op een security lek na, maar daarbij maakt het niet uit hoe moe je bent, maar vooral hoe goed inzicht je hebt).

Maja, wat ik vermoed is dat jij wrs bij zo'n softwarehuis zit wat 100-voudige rekeningen stuurt voor zelfs de meest simpele systemen (denk aan de SAP wereld) en waar alles tot het onnodige procedureel word gedaan en dus het ook uit den boze zou zijn om iets 's nachts te fixen want oh weeh, dat betekend dat het buiten de standaard procedures om moet gaan.

[Reactie gewijzigd door David Mulder op 2 augustus 2024 20:10]

[theemstra]

Niet mee eens!

- dan heb je geen goede test omgeving (want dan had je de software fout daar al geconstateerd)
Als er een belangrijke fout wordt geconstateert op een website als Tweakers oid die je niet was tegengekomen, of een fout bij het overzetten oid.
- geen version control hebt,
niet waar, het kan zijn dat je snel iets moet kunnen testen, of bij een gekraakte website alles wegmieteren

[Het.Draakje]

Als je een fout ontdekt bij het overzetten, dan vraag ik me af waarom je geen geautomatiseerde version control tool gebruikt. De meeste fouten worden gemaakt tijdens routine klussen. Als het voor iedereen nieuw is, dan is iedereen scherm. Been there, done that is het recept voor onachtzaamheid. En dus het recept om iets te vergeten.

Ik vraag met tevens af waarom je een nieuwe versie van zo'n grote website niet eerst op leg nummer 2 van de website uitgebreid getest hebt voordat je die live zet. (En dan pas leg nummer 1 update).

Een gekraakte website. Als je website gekraakt is dan wil je zeker niet midden in de nacht even een hotfix erop loslaten. Dan flikker je inderdaad alles weg en (als developer) laat je de back-up terugzetten.

Als je snel iets moet kunnen testen.. Of het nu snel of langzaam moet gebeuren: testen doe je op een test systeem. Die je regelmatig ververst met (anonieme) productie data. Als je niet kan testen op het testsysteem omdat de data niet goed is dan heb je een te lage interval voor je data verversing.

Het is trouwens een misvatting dat een gestructureerde produktiegang vertragend werkt. Tijdens het testen kan je al de software updaten (op een fatsoenlijk systeem) en als het akkoord bevonden is kan je gewoon de url omzetten naar de nieuwe versie. Een database koppeling omzetten is ook een fluitje van een cent. Dus zelfs als de data het probleem is, dan is dat nog geen reden om aan de productie code te gaan sleutelen.

[T-men]

Testen doe je op een test-omgeving. Eens, maar soms heb je een probleem dat zich alleen in de productie-omgeving voor lijkt te doen. Op een gegeven moment ben je dan wel genoodzaakt om juist daar te gaan kijken wat er mis is.

Oh, en alle commentaar van HetDraakje hierboven, over dat een test in een test-omgeving er alle fouten uit hoort te halen, dat is onzin. Je kunt niet alle mogelijkheden testen. Een test kan alleen garanderen dat bepaalde fouten niét voor komen. Niet dat er geen enkele fout voor komt.

Maar hoe dan ook; "Geh scheissen" op je pagina is ten alle tijden onvergefelijk. Ook in een test- of een dev-omgeving horen dat soort teksten niet thuis. Juist omdat je altijd het risico loopt dat het per ongeluk in productie terecht komt.

[Reactie gewijzigd door T-men op 2 augustus 2024 20:10]

[BoringDay]

Is de test-omgeving dan wel goed opgesteld? Je mag toch hopen deze identiek is en het geen verschil zou mogen uitmaken.

[T-men]

Een test-omgeving wijkt per definitie af van een produktie-omgeving. Niet alleen qua IP adressen en zo, maar ook de autorisaties van een tester zullen in een test-omgeving vaak nèt even anders zijn dan die van een gewone gebruiker op produktie.

Maar het grootste verschil is nog wel de aanwezige data. Een gebruiker, of zelfs een hic-up van het systeem maar vooral een onvoorziene bug kan de meest rare data in je tabellen pompen. Soms moet ie dan écht op productie kijken wat er loos is.
Je probeert dat natuurlijk te voorkomen, maar soms is er gewoon geen andere weg.

Wel ben ik het eens dat het vrijwel nooit nodig is om daarbij naast lees- ook schrijfrechten uit te delen.

Ik vraag me af of dat hier ook gebeurt is. Het kan maar zo zijn dat simpelweg de verkeerde build gedeployd is. Een experimenteel kladje van een junior, bijvoorbeeld. Niet goed, maar soms heb je gewoon pech.

[David Mulder]

Naja, klopt niet helemaal, het *kan* wel alles op development en staging achtige omgevingen testen (e.g. de gehele productie omgeving overzetten naar staging of backups automatisch naar staging omgevingen wegschrijven e.d.) maar het kost het driefout in overhead wat het anders zou kosten. Sommige klanten vinden dit het waard, maar vaak is agility toch belangrijker dan absolute procedurele security (die meestal toch niet perfect werkt in de praktijk).

[latka]

In een grotere organisatie zijn dit zaken die niet door devvers gedaan worden maar door infra (of devops) mensen. Dit is een andere rol en, in mijn ervaring, zijn deze mensen vaak secuurder dan menig developer (vaak wegens het ontbreken van parate kennis om ' snel' even iets te doen grijpt men terug op volledig uitgeschreven procedures die tot op de letter uitgevoerd worden).

[geerttttt]

Bah procedures procedures. En uiteindelijk duurt een websiteverandering dagen of weken. Binnen mijn werk hebben we gewoon een testserver waar we het op maken. zodra het werkt gooien we het over naar de live server. Sommige kleine dingen gebeuren gewoon direct live. Geen gezeur. Alles in de ICT begint zo'n enorme papierbundel te worden tegenwoordig.

[BoringDay]

En zo hoort het toch ook om te ontwikkelen? Eerst in een test omgeving en dan pas publiekelijk.

Documentatie kan geen kwaad maar het moet niet de overhand nemen van de doelstelling. Je kan prima opmerkingen bij de code plaatsen, zolang er maar overzicht is en blijft.

Het hoeft allemaal niet zo ingewikkeld en men hoeft geen ingenieur te zijn om te kunnen programmeren ... ik hekel mij er al jaren aan en het zorgt vaak voor torenhoge kosten wat klaarblijkelijk helemaal niet nodig is.

[Liberteh]

Je werkt zeker met 2 mensen in dat bedrijf? Procedures zijn cruciaal. Als jij NU dood neervalt, wie weet dan hoe hij jou werk moet doen?
Daarnaast werk je in een procedure de stappen uit om een change of wat dan ook door te voeren. In principe maak je het jezelf dus makkelijk door een procedure te schrijven als je iets voor het eerst doet en deze aan te houden: Kan er geen verschil in komen te onstaan wat zeker versnellend werkt tijdens het troubleshooten van incidenten.

Je hebt een slavenpositie, dat merk ik. En dat zal ook altijd blijven met zulke gedachtegang

[BoringDay]

Je begint toch ook met ontwerpplan/stappenplan/feedbacks/deadlines noem maar op ... anders heet het AdHoc?

Maar soms merk ik op dat bepaalde software peperdure ontwikkelingskosten heeft terwijl ik iemand van nog geen 17 jaar oud dit zo ff in 3 maand tijd maakt.

Als ik soms hoor dat een maat software pakket wel enkele miljoenen kost dan denk ik iets van ... je wordt flink voor de gek gehouden.

[koelpasta]

"Als het nodig is om op productie te testen:
- dan heb je geen goede test omgeving (want dan had je de software fout daar al geconstateerd), "

Je moet natuurlijk wel de kosten vergelijken van het onderhouden van een testomgeving met de kosten van de schade als er een keer iets mis gaat.

Voor sommige gevallen blijkt dan dat een volledige testomgeving veel duurder uitpakt, zelfs als je schade oploopt door het verprutsen van je productieomgeving.

Pragmatiek is niet altijd het antwoord.

[gepebril]

Je kan nog zulke mooie change management hebben als iemand die een paswoord heeft zich er niet aan houdt....... Zat zelf een tijd bij KPN en ik ben er zeker van dat dit bij bijna elk bedrijf kan.

[SuperDre]

Och jong, als je weet hoe het bij 9 van de 10 bedrijven gaat..... Als het allemaal heel strak gaat dan is dat zeer uitzonderlijk..

[Het.Draakje]

Uiteraard gaat het bij 9.999 van de 10.000 bedrijven fout. Is dat een reden om het niet goed te (willen) doen?

UPC is een groot bedrijf. Ze behoren het (procedureel) in orde te hebben. Ik vind het erger dat het bij hun mogelijk is dat een developer toegang heeft tot productie dan dat een hacker hun website defaced zou hebben.

Zero day exploits zijn mogelijk en dus acceptabel; niet nadenken over procedure(handhaving) is onaanvaardbaar.

[koelpasta]

"Ik vind het erger dat het bij hun mogelijk is dat een developer toegang heeft tot productie dan dat een hacker hun website defaced zou hebben. "

Ik heb een tijd geleden bij een groot netwerkbedrijf gewerkt.
Wij legden internet aan.
Ik had toen binnen een paar maanden het root wachtwoord van het netwerk gekregen.
Ik kon bij alle machienes op het wereldwijde netwerk en ik was daar god.
Ik kon doen en laten wat ik wilde.
Gelukkig werdt alles gemonitorred en gelogd en was het peanuts om te achterhalen wie vanaf welke machine waar ingelogd zat.
Moraal? Vrijheid sluit beheersing niet uit.
Tenzij er echt iets fout is gegaan kan die gast z'n baantje wel op z'n buik schrijfen.

Je kan eventueel nog stellen dat iemand met kwade bedoelingen zich in de organisatie kan werken om dan vanuit die plek schade aan te richten.
Maar die plek is er altijd wel.
Is het niet de dev-afdeling dan is het wel support die wat backdoors kent. Is het niet support dan is het wel management dat van gevoelige zaken af weet.

Als je het echt 'veilig' wilt maken dan moet iedereen compleet paranoia zijn (immers, het gevaar kan van overal komen) en echt niemand vertrouwen.
Lijkt me geen leuke plek om te werken.

Jij wilt dat de mensen op procedures vertrouwen.
Maar wie controlleert of de procedures correct zijn? En hoe zit het eigenlijk met die gast die ze opgesteld heeft?
etc, etc, etc...
Je moet de kosten tegen de baten uitzetten.
Er is geen absolute veiligheid, er is alleen maar relatieve veiligheid.

[Reactie gewijzigd door koelpasta op 2 augustus 2024 20:10]

[MuddyMagical]

Gebeurt bij de beste websites wel eens...
plan: Server- & netwerkstatusmeldingen XII

d/t foutje. Thanks @akii

[Reactie gewijzigd door MuddyMagical op 2 augustus 2024 20:10]

[Liberteh]

Change management is een proces voor een bedrijf om bepaalde wijzigingen door te voeren. Als jij in dienst komt bij een bedrijf die op deze manier werkt dan heb je je daar aan te houden.
Als je toch op eigen houtje wijzigingen direct door gaat voeren zonder hierbij te denken of gebruik te maken van het systeem dat er voor bedoelt is dan heb je in ieder geval recht op een officiële waarschuwing dan niet op staande voet ontslag.

[J.J.J. Bokma]

Hmmm, meer als een klant die niet betaald, of te laat...

Tenminste, ik zie de humor niet in van dat soort dingen. Ik weet dat het gebeurd, ik heb ooit meegeholpen aan een groot stukje serieuze zakelijke software waar in de comments ergens stond dat "<naam> is een vuile hond". Ik vind dat dus triest, maar goed, en zeker niet getuigen van professionalisme. Zo ook met ergens een dergelijke "test string" neer te zetten. En dan niet controleren...

Dus, nee, ruikt voor mij naar een vervelende klant.

[HoppyF]

Beetje raar verhaal.
Waarom zou je een ontwikkelaar uit Oostenrijk halen?
Er zijn toch hier ontwikkelaars genoeg in Nederland.
Zo'n speciale website heeft UPC ook weer niet.
En wat moet een ontwikkelaar op een productie website?

[Reactie gewijzigd door HoppyF op 2 augustus 2024 20:10]

[tERRiON]

Het is inderdaad wel een koddig verhaal. Maar om terug te komen op je eerste vraag: Zoiets heet outsourcing. Kort gezegd komt het er op neer dat je mensen inhuurt voor een bepaalde tijd of voor een bepaald project. En soms is het voordeliger om "elders" mensen in te huren, bijvoorbeeld omdat het goedkoper is of omdat het kennisniveau op een specifiek gebied hoger is. Maar aangezien UPC ook in Oostenrijk actief is, zou het ook zomaar kunnen zijn dat "UPC Oostenrijk" bepaalde diensten aanbiedt/beheert die ook door "UPC Nederland" wordt gebruikt.

[Plofkotje]

Omdat de hele mail infra van UPC voor de klanten gehost wordt door UPC Oostenrijk. In Zwitserland werd mijn UPC Cablecom mailadres ook op dezelfde omgeving in Oostenrijk gehost.

[kamerplant]

Waarom, als internationaal bedrijf, een team van ontwikkelaars inhuren per land waarin je actief bent?

[J.J.J. Bokma]

Freelance Perl programmeur hier. Ik werk voor bedrijven in Europa (inclusief Nederland), USA, en een tijdje zelfs Azie (Japan) en woon verder "gewoon" in Mexico (waar ik niet werk, verder).

Verder kan ik vaak ook bij productie-website(s) komen. Verder kan het natuurlijk prima voorkomen dat er iets doorheen glipt, hoewel dit wel triest is maar dat heeft wat mij betreft meer te maken met de tekst, want een beetje fatsoenlijke ontwikkelaar gebruikt verder natuurlijk geen "test tekst" zoals hier aangegeven. Maar goed, ik heb wellicht en een ander gevoel van humor en werk een stuk professioneler.

[SuperDre]

UPC Nederland is maar een klein onderdeel van het hele UPC bedrijf..
Wat moet een ontwikkelaar NIET op een productie website?

[djfadeout]

maar waarom de post op pastebin? lijkt mij dan geen grap.... misschien een dom/excuus van UPC?
zodat het niet op een hack/defacement lijkt.
blijft een raar verhaal.

[Plofkotje]

Dat is gewoon een standaard SSH sessie, niks spannends, prolly gewoon iemand die "ssh $ip_van_een_bak_van_upc" op z'n command-line gedaan heeft..

[KillGhost]

Of iemand wil extra publiciteit krijgen door maar snel iets te verzinnen omdat UPC nu in het nieuws is.

[yrobot]

Ik gebruik UPC en heb het gezien

[kimborntobewild]

Ik gebruik UPC maar zie geen goede reden de email van UPC te gaan gebruiken .
Neem je een keer een andere ISP... Hoppa, is je oude mailadres waardeloos geworden.

[opa uche]

Tja, je 06 kun je overnemen... Maar je email...

[Aham brahmasmi]

Shit, geen screenshot?

[henk-jan]

In vorige berichtgeving hierover wel.

nieuws: Webmail UPC weer beschikbaar nadat site beklad werd

[yrobot]

Ik heb geen screenshot gemaakt

[kimborntobewild]

Ach, er is altijd nog Tux Paint...
En google cache:
http://www.google.nl/#scl...51eeb5fe&biw=1600&bih=623

[Reactie gewijzigd door kimborntobewild op 2 augustus 2024 20:10]

[Shamalamadindon]

Misschien een developer die een originele ontslagbrief heeft ingestuurd

[GWTommy]

Dit is ook een mooie manier om een hack goed te praten! Veel minder gezichtsverlies zo, en geloof maar dat mensen dit makkelijk als waarheid aannemen!