Softwareontwikkelaar steelt creditcarddata van 20 miljoen Koreanen

Een Zuid-Koreaanse softwareontwikkelaar heeft kans gezien om onversleutelde creditcardgegevens buit te maken bij een bedrijf dat betalingsverkeer verwerkt. De data van zeker 20 miljoen Zuid-Koreanen zou zijn doorverkocht.

Een ingehuurde softwareontwikkelaar sloeg begin 2012 zijn slag bij het bedrijf Korea Credit Bureau, zo heeft de Zuid-Koreaanse overheid bekendgemaakt. Daar had hij toegang tot klantgegevens van drie grote creditcardbedrijven. De man moest software ontwikkelen om eventuele creditcardfraude op te sporen. De data, waaronder namen, creditcarddata en burgerservicenummers, waren onversleuteld en werden door de softwareontwikkelaar op een usb-stick geplaatst en doorverkocht aan een aantal marketingbedrijven. Het zou gaan om meer dan 80 miljoen creditcardnummers van meer dan 20 miljoen Zuid-Koreanen.

Volgens de autoriteiten is de softwareontwikkelaar gearresteerd en zijn er geen bewijzen voorhanden dat de buitgemaakte gegevens actief zijn misbruikt. Ook enkele personen die de creditcarddata zouden hebben aangekocht zouden zijn opgepakt.

Naast het feit dat de data onversleuteld was opgeslagen, zouden de drie getroffen creditcardbedrijven pas achter de diefstal zijn gekomen toen de autoriteiten hen hadden ingelicht. De bedrijven, KB Kookmin Card, Lotte Card en NH Nonghyup Card, hebben hun excuses aangeboden en een onderzoek toegezegd naar de zaak. De Zuid-Koreaanse financieel toezichthouder meldt verder dat de financiële instellingen eventuele verliezen van klanten zullen compenseren.

Reacties (41)

[bonus]

Wauw, 20 miljoen Zuid-Koreanen, dat is nog eens een aantal. En dat allemaal onversleuteld, dat is toch wel heel erg slordig. Als die rekeningen daadwerkelijk allemaal zouden zijn gebruikt daar is bijna niet tegen op te compenseren. Gelukkig lijkt er (nog) niks met de data gedaan te zijn maar anders...

[Kontsnorretje]

Wat mij dan ook opvalt is dat het om 80 miljoen credit card nummers gaat. Dus gemiddeld heeft elke Zuid-Koreaan 4 credit cards? (grove schatting n.a.v. het artikel).

En als software ontwikkelaar vind ik het ook niet heel gek dat hij bij de onversleutelde data kan. Het moet op een bepaald moment ergens verwerkt worden, om ze te versleutelen. Of te ontsleutelen, ergens in de code zal dat toch moeten gebeuren. Een export is dan ook niet al te moeilijk te realiseren.

[Jeoh]

Ja, in Zuid-Korea hebben veel mensen torenhoge schulden door o.a. een berg creditcards en maffiosi die leningen aanbieden.

[Verwijderd]

bron: http://www.businessweek.c...ding-on-housing-education

Wel zielig voor ze... kunnen ze nu nog wel wat uitgeven met hun creditcards?

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

[Armin]

Zie het creditcards wat breder. In veel landen worden voor het normale betaalverkeer charge cards of debitcards (in 'credit' mode) gebruikt. Dat noemt men in de volksmond ook vaak creditcard ook al is dat technisch niet zo.

Ook in Nederland zijn heel veel creditcards in feite ook charge cards, en kun je er niet of enkel beperkt rood op staan.

Moraal, kijk eens in je eigen portemonnaie hoeveel betaalpasjes jij hebt. Voor velen zullen er dat ook meer dan 1 zijn per persoon.

[Anonyymm]

Zuid-Korea heeft bijna 49 miljoen inwoners.

Daarnaast zijn creditcardnummers beperkt geldig. In het artikel staat niet genoemd of alle 80 miljoen nog geldig waren.

[Niemand_Anders]

Voor de duidelijkheid: De developer HEEFT de data onversleutelt verkocht, er staat nergens dat de informatie in de database zelf niet was versleuteld.

Dit bedrijf was een soort van PayPal. Een bedrijf dat creditcard betalingen voor andere bedrijven afhandelt. En ja, dan heb je dus het nummer, verloopdatum en CCV code onversleuteld nodig.

Zelfs als je een per-user (row) encryption key aanhoud moet je op een bepaald moment de data ook weer decrypten. Maar dit is niet anders dan een systeembeheerder bij je internet provider welke ook onbeperkt mailboxen kan uitlezen als hij/zij dat wil.

Echter per-user encryption zorgt voor extra resources en ergens wordt alsnog de key opgeslagen. Als je een export maakt van zowel de CC data als de keys, dan hoef je alleen nog maar een scriptje te schrijven welke de data alsnog ontsleutelt. Om die reden wordt per-user encryption vrijwel niet toegepast. Tegen een medewerker met database toegang kun je je bijna niet beveiligen..

[Jeoh]

Iedereen die in Zuid-Korea wel eens heeft geprobeerd te internetbankieren weet dat de beveiliging daar een grap is. IE6 met brakke ActiveX meuk, soms nog wel eens een Java appje die alleen werkt op één Java versie uit her jaar 0... Van beveiliging hebben ze daar weinig kaas gegeten. Dat deze gegevens ook plaintext worden opgeslagen verbaast mij eigenlijk niet, ondanks dat er bijvoorbeeld in Amerika erg strenge eisen zijn (PCI). Nam aan dat dit ook in andere landen van toepassing was, maar helaas...

[Ynst2003]

klopt, komt door een wet die de regering in de jaren '90 heeft aangenomen.

At the end of the 1990s, Korea developed its own encryption technology, SEED, with the aim of securing e-commerce. Users must supply a digital certificate, protected by a personal password, for any online transaction in order to prove their identity. For Web sites to be able to verify the certificates, the technology requires users to install a Microsoft ActiveX plug-in.

The trouble is ActiveX is only supported on one platform: Microsoft Windows. As a result, when the South Korean government made the technology mandatory for online e-commerce, the entire South Korean Internet sector become enslaved to Internet Explorer:

It forced consumers to use Internet Explorer because it was the only browser ActiveX plug-ins were compatible with. By default, Web developers optimized not only banking and shopping Web sites for Internet Explorer, but all Web sites. For developers, this just seemed logical. The result has been a decade-long monopoly in the Korean market, where virtually all Korean Web sites are optimized for Internet Explorer.


Bron: TechDirt

[GamingZeUs]

Ook de activeX component is NOG ALTIJD heel erg populair in Korea.

Voor de uitwisselingsuniversiteit waar ik heen ging moest ik een IE plugin installeren voordat ik m'n vakkeuzes kon zien! Dat was eerst een component en toen nog een losse exe!

Qua veiligheid zit op windows dan op zwart zaad. En denk maar niet dat die exe digitaal ondertekent was. Gewoon 100% onveilig. (Condooms zijn ook zeldzaam daar trouwens..)

En wat echt grappig is? Het gaat allemaal prima. Gewoon zo'n dief oppakken, jaren lang in't gevang gooien. Associates ook oppakken. Niet alsof ieders creditcards al gelekt waren. Probleem is het geld "uit het systeem halen". Slachtoffers worden ASAP gecompenseert.

[Antenne Bayern]

) Hier uit blijkt weer eens dat veiligheid en vertrouwen een "wasseneus" is.
Daarnaast doen bedrijven (ook zeggen ze van wel), praktisch niets met de
adviezen van security bedrijven om data (fatsoenlijk) te beveiligen.

Waar is bijvoorbeeld de integriteit gebleven?

[Verwijderd]

Maar dat is toch nog nooit anders geweest zolang de mensheid rondloopt? Het is nu alleen wat grootschaliger en zichtbaarder dan in het verleden. Al sinds er sloten en kluizen zijn, zijn er mensen die dat proberen te kraken.

[invic]

Het is opvallend dat deze persoon, per definitie, dezelfde onrechtmatige handelingen heeft gedaan als Snowden. Snowden was ook ingehuurd en "verkocht" ook de gestolen gegevens voor persoonlijk gewin analoog als deze persoon. Ja ja er zullen reacties komen dat het anders is maar dan meet je echt met 2 maten. Stelen is stelen!

[TT17]

Hoe kan dit toch, hashing, salting nooit van gehoord zeker ?

[Blokker_1999]

Aangezien hij net moest werken aan beveiliging van die gegevens moet hij waarschijnlijk ook toegang gehad hebben tot de onversleutelde gegevens. Dan is het maar een koud kunstje om deze gegevens te stelen. Bij elke verwerker van creditcardgegevens moeten ze ergens in plain text passeren om verwerkt te kunnen worden.

[TT17]

Klopt ! Toch hadden ze, als hij zoveel rechten heeft, de logs dan maar actiever moeten monitoren, nu moesten de autoriteiten hen inlichten van de "hack"

[Blokker_1999]

Je kan zoveel monitoren als je wil, als hij voldoende rechten weet te krijgen (of al heeft) dan kan hij zijn sporen ook uitwissen. Als je iemand aan beveiliging laat werken moet je altijd een vertrouwensband opbouwen.

[Verwijderd]

Wat mij betreft ligt de grootste beveiligings-blunder nog altijd bij de creditcard maatschappijen.

Want transacties zijn gemakkelijk een stuk veiliger te maken dan ze nu zijn. (Bijvoorbeeld door het verstrekken van tijdelijke/eenmalige/gelimiteerde credit-card nummers, iDeal-achtige betalingen, of werkelijk ieder ander systeem dat je zowat maar kunt bedenken).

[Armin]

tijdelijke/eenmalige/gelimiteerde credit-card

Zo goed als alle credit/charge/debitcard nummers zijn reeds gelimiteerd. Anders dan bij bankrekeningnummers. Trek kaart in, en het probleem is opgelost.

Natuurlijk kun jij de termijn nog korter maken, maar dat is weer lastig voor de klant.

[Verwijderd]

Ik bedoelde gelimiteerd in de zin dat je bijvoorbeeld kunt instellen hoeveel er maximaal mag worden afgeschreven en/of door wie.

[Armin]

OK, maar ook dat is al praktijk bij de meeste kaarten.

Enkele voorbeelden.

- Vrijwel alle creditcards hebben een harde limiet, welke ook user-instelbaar is (in neerwaardse zin ). En zelfs de charge cards van de befaamde American Express die op papier onbeperkt zijn qua limiet, zullen in de praktijk snel een geweigerde transactie geven als je grotere bedragen gaat proberen.

- Regionale restricties. Bij transacties buiten de gangbare regio kan en vaak ook zal er ook een weigering optreden. Ofwel, iemand die altijd in de regio Amsterdam een charge card gebruikt en opeens in Pakistan een transactie heeft zal die laatste vaak geblokeerd zien. Vandaar ook dat je vaak moet melden als je gaat reizen.

- Verschillen in hoeveel wie mag afschrijven, exact zoals jij wilt. Bepaalde bedrijven hebben meer privileges dan andere. Ook omdat sommige grotere ketens zich zelf garant stellen bij fraude.

Jij refereert wellicht naar user-instelbaar, maar dat kennen de meeste andere betaalsystemen ook niet. Plus het zou jezelf hinderen als je opeens wilt betalen op een plaats waar je zelf een limiet ingesteld had.

- Verschillen in soorten transacties. Cash pinnen met je creditcard vaak een lagere limiet dan andere betalingen. Maar zo zijn er ook verborgen limieten voor ander transacties. Vaak gaat dat ook met patroonherkenning op basis van jouw betalingsprofiel.


In Nederland is de creditcard een bijna onbekend fenomeen (en wat mensen denken dat hun credit card is, is meestal een charge card), maar uiteindelijk is er weinig mis met deze vorm van betalen in de vorm van beveiliging. Je kunt het zo veilig en onveilig maken als je wilt.
Het 'probleem' is echter dat het vaak een afweging is tussen makkelijk vs veilig. Als ik bij de Starbucks of Albert Hein moest inloggen en een iDeal betaling zou uitvoeren zouden de rijen ook wat langer zijn Vandaar dat men daar een 'pin'-code gebruikt.

Ik gebruik creditcards juist in minder veilige/onveilige omgevingen omdat het een extra buffer is tov andere betaalvormen én het tevens mijn rekeningnummer niet bekend maakt bij de ander.

[Verwijderd]

Het 'probleem' is echter dat het vaak een afweging is tussen makkelijk vs veilig.

Maar nu maken de creditcard-bedrijven die afweging voor mij...

Bovendien, om terug te komen op het artikel, zo veilig is het dus helemaal niet.

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

[Armin]

Als die hacker bankrekeningnummers had gestolen was het resultaat veel erger dan creditcard nummers ...

Een nieuw bankrekeningnummer uitgeven is lastiger dan een nieuwe kaart.

[TT17]

Agree => confidentiality, trust & trustworthy

[lauwsa]

Wat wil je dan loggen, je hebt toch de gegevens nodig als je ze wilt versleutelen? Dan is het toch erg makkelijk om de gegevens in handen te krijgen. Wil je de ontwikkelaar op gaan sluiten in een hokje waar je geen internet hebt, geen pen en papier, en geen mogelijkheid hebt om een apparaat op de pc aan te sluiten?

[TT17]

Nee, dat bedoel ik niet... Wanneer een persoon met zoveel toegang zijn computer opstart zou een onafhankelijk programma er bijvoorbeeld voor kunnen zorgen dat wanneer hij iets "unusual, suspicious" ziet dat te melden aan ik zeg maar de CIO of CEO van dat bedrijf, of beter nog aan een extern bedrijf dat hiervoor is ingeschakeld. Zo heeft niemand binnen de organisatie zelf de mogelijkheid iets te veranderen aan log files, en kunnen ongehoorde activiteiten sneller gespot en gerapporteerd worden.

[pelt]

Is dit echt zo? Ik heb er geen verstand van, maar als dit bij alle cc bedrijven zo is, dat er dus ergens plain gegevens beschikbaar zijn, dan valt het me nog mee dat dit de eerste keer is dat aan cc kant info gestolen is op grote schaal.

[woutertje]

Het creditcard bedrijf moet toch weten wie zijn klanten zijn en welke creditcards zij hebben. Op het moment dat er een transactie verwerkt moet worden moeten deze gegevens toch beschikbaar zijn.

[Verwijderd]

Hoe slecht het ook is dat deze man dit gedaan heeft, is het nog slechter dat het uberhaupt mogelijk was. Kon dit niet voorkomen worden?

[Verwijderd]

eigenlijk niet.
Jij stuurt je cc gegevens, en de verkoper moet daar iets mee kunnen doen. Als er een ontwikkelaar bij de verkoper werkt die alle data 'onderschept' is er idd niets aan te doen.

Er zal dan toch een extra beveiliging moeten komen, bijv. toch doorsturen naar de bank voor een code als een pin of via een reader/

[Armin]

Nou, het probleem is niet zozeer dat die hij dat soort data kon benaderen, maar meer dat hij al deze data kon benaderen.

Een ontwikkelaar zou bijvoorbeeld bij zijn dagelijkse werkzaamheden verder helemaal geen echte data nodig hebben, maar interne test/development databases.

Maar wellicht dat het het geen ontwikkelaar was, maar meer een system admin. Maar dan nog zou er juist in zo'n geval een systeem moeten zijn waar toegang tot alles niet zomaar gegeven wordem.

Zeker omdat het hier eeen inhuurder betreft. Normaal zou je verwachten dat hiervoor vaste medewerkers gebrtuikt worden, of dat zo'n persoon onder toezicht staat.

Ik ken bedrijven waar hele kritieke gegevens enkel benaderd mogen worden na toestemming van twee onafhankelijke teams, en dan enkel nog onder begeleiding.

Ik geef toe, hoe dichter bij de bron, hoe moeilijker te beveiligingen, maar gelukkig neem het aantal mensen dat toegang moet hebben tot alle gegevens ook exponentieel af.

[MTVGN]

Vergis je niet, dat gebeurt ook in Nederland. Ik heb als externe (en als onderdeel van een team louter bestaand uit externen) nog niet zo lang geleden bij een kleinere bank gewerkt als programmeur en ook wij hadden verschillende mogelijkheden:
1. er was een keer een groot probleem in het IT-systeem dat niet zo makkelijk nagespeeld kon worden met testgegevens, dus toen werd gewoon eventjes de productiedata in test geladen. Aangezien een meer ervaren ontwikkelaar het probleem moest oplossen en ik het niet heel druk had besloot ik eens wat namen in te voeren van interne collega's om te zien of ze zelf ook een spaarrekening bij hun baas hadden en dat hadden de meesten inderdaad, ik kon dus ook gewoon zien hoeveel geld iedereen daar op had staan. Ik had ook uit kunnen zoeken op welke spaarrekeningen het meeste geld stond, maar dat ging me net te ver, als daar bekende mensen tussen hadden gezeten had ik dat namelijk tot in de lengte van dagen onthouden en dat leek me niet handig.
2. alle XMLs die tussen verschillende systemen heen en weer werden gestuurd werden gelogd. Bij sommige rekeningtypes werden de wachtwoorden bij het inloggen netjes als ***** weergegeven, maar bij minimaal 1 rekeningtype niet en aangezien veel mensen meerdere rekeningtypes bij dezelfde bank hebben was daar best veel mee te herleiden. Toen er een keer een productiestoring opgelost moest worden die betrekking had op zo'n rekeningtype vond diezelfde meer ervaren collega het erg leuk om het ene na het andere, in zijn ogen grappige, wachtwoord dat hij in de logging tegenkwam met het hele team te delen. N.a.v. dit geval besloot ik, toen ik een keer alleen met de teamleider op de kamer was, te vragen waarom die wachtwoorden gewoon leesbaar in de logs stonden en of we dat niet op moesten lossen, toen kreeg ik als antwoord "dat ie dat niet zo'n probleem vond, want dat deden we hier al jaren zo" o.i.d. Dat antwoord vond ik niet goed genoeg en dus besloot ik bij twee interne functioneel beheerders die ik vertrouwde het probleem aan te kaarten. Zij namen daarop contact op met de "security officer" en die kwam erachter dat wel erg veel mensen toegang hadden tot die logs en die besloot het aantal mensen dat bij die logs konden drastisch te verminderen; de enige mensen die er nog bij mochten waren degenen in het team waar ik in zat, maar dus niet meer de functioneel beheerders e.d. (oftewel: alleen nog externen; niet meer internen). Toen besloot ik het op te geven, als een bedrijf z'n gegevens echt niet wil beveiligen dan niet ...

[Armin]

oftewel: alleen nog externen; niet meer internen



Tja, eigenlijk verbaasd het me niks, maar het blijft toch triest ...

Overigens op zich wel goed dat er nog enige beperking werd uitgevoerd na jouw melding. Dat het dan juist de externen zijn is dan wel erg triest ...

[robvanwijk]

De bedrijven, KB Kookmin Card, Lotte Card en NH Nonghyup Card, hebben hun excuses aangeboden en een onderzoek toegezegd naar de zaak.

Misschien lees ik het artikel verkeerd... maar die creditcardbedrijven valt verder toch niks te verwijten? Het klinkt of het lek bij de Koreaanse versie van het BKR zat; daar moeten ze hun gegevens wel heen sturen (over een versleutelde lijn, zou je hopen, maar het "BKR" moet het kunnen decrypten om zijn werk te doen). Hoe hadden de creditcardbedrijven deze hack dan kunnen voorkomen?

[Jeoh]

Deze drie bedrijven zijn de eigenaar van Korea Credit Bureau.

[Verwijderd]

't Komt waarschijnlijk omdat dit een IT-forum is, dat men hier gelijk naar techniek kijkt i.p.v. de mensen die de IT bedienen. In dit geval kijk ikzelf toch echt naar de mens. Je kan lopen zwetsen over aanwezige beveiliging (waarvan je hier geen idee hebt welke überhaupt gebruikt is), maar het feit dat die beveiliging überhaupt nodig is, is eigenlijk schandalig. Ik zie deze man liever eerder als vandaag hangen.

[Verwijderd]

Hangen is een beetje overdreven, maar een paar jaar opsluiten lijkt me prima.

[Verwijderd]

Ehm, de beste man heeft 20 MILJOEN mensen bestolen. Hoeveel jaar had je in gedachte? 1 per persoon? Ach, als ie wegrot in een koreaanse gevangenis vind ik inderdaad ook goed.
M'n reactie klinkt wellicht fel, maar ik kan erg slecht tegen diefstal. Van andere mensen hun bezit heb je af te blijven, punt.

[Vexxon]

En doorverkocht aan marketingbedrijven? Ik neem aan dat de betreffende bedrijven ook keihard worden aangepakt.

[Verwijderd]

Hij moest zelf software ontwikkelen om creditcard fraude op te sporen, maar zag zijn kans om ze zelf to kopiëren?