American Express liet adminpanel voor site-debugging openstaan

American Express heeft een adminpanel voor het debuggen van zijn site enige tijd open laten staan, waardoor onder andere misbruik via xss-aanvallen mogelijk was. Volgens de ontdekker reageerde de betalingsaanbieder laks op meldingen.

American Express gaf tot gisteren iedereen een blik op zijn adminpanel via de site https://www.americanexpress.com/us/admin/. De beheerders van de site van de Amerikaanse betalingsprovider gebruikten de site voor het debuggen van onder andere 'cardmember cookies'. Ook de Adobe DigitalPulse v3-debugger was publiekelijk toegankelijk, ontdekte ontwikkelaar Niklas Femerstrand.

Volgens hem was de debugger vatbaar voor cross site scripting-aanvallen. "Een aanvaller kon een cookiestealer in combinatie met jQuery's hide-functie en cookie-harvesting injecteren die, ironisch genoeg, misbruikt kon worden via het adminpanel dat slordige American Express-ontwikkelaars open lieten staan." Onder andere phishers zouden hiervan hebben kunnen profiteren. Het lijkt erop dat de websitebeheerders wisten dat het panel openstond, aangezien de desbetreffende pagina werd uitgesloten voor indexering via het robots.txt-bestand.

Femerstrand claimt dat American Express laks reageerde op zijn beveiligingsmeldingen, maar de ontwikkelaar lijkt het concern alleen via Twitter benaderd te hebben. American Express erkent het bestaan van het beveiligingsprobleem inmiddels en heeft de pagina onbereikbaar gemaakt. "De pagina bevatte geen gegevens van klanten, zoals kaartnummers, namen of adressen. We hebben geen informatie dat de kwetsbaarheid gebruikt is voor kwaadaardige bedoelingen, maar we blijven het onderzoeken."

Reacties (22)

Het blijft me verbazen dat banken zo laks zijn met hun beveiliging maar wat me eigenlijk nog meer verbaast is dat ze altijd zo nonchalant reageren op dit soort meldingen/berichten.

Nu is er in dit geval misschien niet zoveel aan de hand maar toch blijf ik me keer op keer verbazen hoe banken met security omgaan.

American Express is geen bank, het is een financiële dienstverlener.

Ik ben actief in de banksector en op hoger en lager niveau is toch echt wel iedereen met beveiliging bezig. Zowel fysiek als virtueel.
Dat er af en toe fouten zijn (bv hackers die een UCR-code vragen), dat zal nooit uit te sluiten zijn. De software en hardware wordt niet door God, maar door mensen gemaakt. Het eerste foutloze programma voor complexe taken (niet "Hello World" dus) moet ik nog zien...
De reactie hier is nogal plat (zeker omdat het gekend is), maar dat is zeker geen gemiddelde voor de sector. Als je nagaat hoe NL en BE banken reageren op lekken of fouten, dan is dat meestal razendsnel en de gedupeerden worden vergoed. Ik ken een pak mensen die standby zijn in het WE en 's nachts om onvoorziene problemen zo snel mogelijk te fixen.

Een financiële dienstverlener is een bank. En aangezien American Express creditcards verstrekt, is het een bank.

Het blijft me verbazen dat banken zo laks zijn met hun beveiliging maar wat me eigenlijk nog meer verbaast is dat ze altijd zo nonchalant reageren op dit soort meldingen/berichten.

Nu is er in dit geval misschien niet zoveel aan de hand maar toch blijf ik me keer op keer verbazen hoe banken met security omgaan.

Verbaast dat je nog ? De afgelopen tijd hebben we nochtans een duidelijk signaal gegeven aan de banken dat als er ooit iets misloopt de overheid (met dank aan de belastingsbetaler) er maar al te graag voor opdraait.

hmm je website debuggen via een webpagina. Niet de meeste veilige optie blijkt, waarom niet een stand-alone programma die sowieso ook de user-experience kan testen?

Debuggen in een productie omgeving op die schaal lijkt me sowieso uit den boze!

Hier hebben we toch een mooie acceptatie of pre-productie omgeving voor?

Klinkt als een IT start up van studenten, en dat voor een groot creditcard bedrijf.. droevig!

Hier hebben we toch een mooie acceptatie of pre-productie omgeving voor?

Dat leert men eigenlijk alleen op school
In de werkelijkheid zie je bijna nooit testomgevingen. Droevig inderdaad.

In de werkelijkheid zie je bijna nooit testomgevingen.

Mag ik vragen hoe breed je ervaring hierin gaat? Op elk project dat ik al gewerkt heb, bij om het even welke klant, waren er minstens 3 omgevingen. Een ontwikkelomgeving (waar elke developer op kan doen wat hij wil), een testomgeving (eerste toegang voor klanten), een acceptie- (uitvoerige testen tussen projectpartners en finale goedkeuring) en een productieomgeving.

Testomgeving en acceptatieomgeving durven al eens samenvallen en ontwikkelomgeving kan zowel lokaal als remote zijn. Nog geen uitzondering gezien daarop. En ik zie net hetzelfde bij de vele collega's.

[Reactie gewijzigd door MatthiasDS op 7 oktober 2011 13:08]

Pardon? Bijna nooit test environments?
Als jouw werkgevers hier niet serieus mee omgaan kan ik je alleen maar adviseren om snel iets anders te zoeken.
Ik heb als ontwikkelaar nog nooit gewerkt voor een bedrijf zonder aparte test/acceptatie environments.

Een organisatie als American Express heeft echte wel een OTAP straatje liggen. Bovenstaande issue komt enkel doordat iemand even niet goed heeft nagedacht/opgelet. En dat is natuurlijk zeer kwalijk in deze sector.

Als er in de site van American Express een lek is moet dat zo snel mogelijk dicht. Ik kan me voorstellen dat het daarvoor dient.

User experience testen als je wilt debuggen? Twee verschillende dingen. Daarnaast kan je userexperience natuurlijk niet testen met een tool. Of bedoel je testen van de performance... Duidelijkheid gewenst..

debuggen hoort ook bij de userexperience. Inderdaad performance, maar ook hoe de HTML output is etc.

Nier alleen maar letten op foutmeldingen zeg maar.

Een eindgebruiker test de gebruikersvriendelijkheid. Dat kan je niet door een tool laten doen. Een programma dat perfect is geprogrammeerd en keurige foutmeldingen geeft kan misschien door een tool worden gechecked op correcte werking, het is de eindgebruiker die bepaalt of het een prettig programma is om mee te werken of dat het juist een draak is van een programma.

Waarom niet een offline test omgeving?

Hoe moeilijk is het nu toch om dit soort dingen standaard altijd te blokkeren. Als je het in de robots.txt hebt staan dan houd het alleen in dat bijvoorbeeld Google er niet naar kijkt maar mensen kunnen de URL alsnog gewoon vinden.

Als je zo iets vind dat meld je dat niet via twitter maar goed dat zal aan mij liggen.

Hoe dan ook het is wel heel erg slordig van zo'n grote speler in de financiële wereld om op deze manier fouten te maken. Je kunt een URL simpel onbereikbaar maken maar schijnbaar was er een beheerder die het wel handig vond om van af thuis af en toe even wat werk te doen of zo...

Als je zo iets vind dat meld je dat niet via twitter maar goed dat zal aan mij liggen.

Als je de bron leest, zie je dat de ontdekker vraagt om een legitiem e-mailadres waar hij het lek uitgebreid kan melden.

Daarnaast biedt AmEx een mogelijkheid om in contact te komen via Twitter, maar is de gebruiker aldaar dusdanig stom dat ie niet meteen deze opmerkzaamheid doorsluist naar upper management. Zoals het hoort in klantenservice. Deze medewerker zou bij mij vrezen voor zijn/haar baan.

Zie ook Twitter conversatie

[Reactie gewijzigd door PcDealer op 8 oktober 2011 09:57]

Was het een site met alleen reclame of werden transacties en klant gegevens via deze site verwerkt, dat maakt natuurlijk nogal een verschil.

Het zou me niet verbazen dat dit per ongeluk doorgezet is naar een productie omgeving, debug panel word op acceptatie gezet, ontwikkelaar is in zijn stappenplan vergeten te vermelden dat dit op productie afgeschermt dient te worden. Ontwikkelaar gaat vrolijk op vakantie, applicatiebeheerder doet vrolijk een release, en vervolgens heeft niemand door dat de boel wagenwijd open staat. Geloof me dit soort dingen gebeuren vaker als je denkt.

Misschien wel expres gedaan, om te kijken welke f.... hackers er dan komen kijken ???

Of sla ik de plank nu geheel mis \?

En dan een beveiligingsschandaal risceren zoals onlangs bij ING? Lijkt me niet bij een bedrijf (financiële dienstverlener) die bestaat vanwege vertrouwen.

Zie nieuws: Beveiligingstest ING liet bezoekers denken dat site was geïnfecteerd

[Reactie gewijzigd door PcDealer op 8 oktober 2011 10:04]

Hebben ze vast Express gedaan.