Landelijk meldpunt beveiliging/lekken melden?

[DJMaze]

Ergens achter in mijn brein zit een dingetje over een landelijk meldpunt voor online beveiliging.
Ik weet alleen niet meer waar ik mij moet melden.
Zelfs Google en een search op Tweakers geeft mij geen resultaat.

De afgelopen jaren heb ik namelijk beveiligingsproblemen opgespoord in online betaalsystemen waaronder:
- pay.nl
- multisafepay.nl
- ideal

En deze systemen bevatten nog steeds de problemen, zelfs na melding.

Het wordt nu wel eens tijd dat die bedrijven hun scripts/implementaties en andere issues gaan oplossen en het landelijke meldpunt lijkt mij het meest logische.

Maar ja, wie kan mij vertellen waar die is?

[Megamind]

Melden aan de pers zonder implementatie vrij te geven? Tweakers lijkt me een geschikte kandidaat daarvoor.

[ongekend41]

Je zou het, indien het over persoonsgegevens gaat, aan het CBP kunnen melden. Die hebben sinds enige tijd (dacht ik) een plek om dit soort misstanden te melden. Anoniem naar de pers lekken, sinds kort ook naar Tweakers ( http://tweakers.net/plan/...leaks-is-nu-mogelijk.html ) kan ook via publeaks. Na het inschakelen van de media worden lekken over het algemeen vrij snel gedicht.

[Puch-Maxi]

Waarom niet via Publeaks?
plan: Lekken naar Tweakers via Publeaks is nu mogelijk

edit:
Excuus, in mijn enthousiasme vergat ik dat Ongekend41 al met hetzelfde idee kwam

[ Voor 21% gewijzigd door Puch-Maxi op 07-11-2013 01:17 . Reden: Spuit11 ]

[DJMaze]

Publeaks is inderdaad een goed idee.
Maar ik ben natuurlijk verplicht om het eerst allemaal netjes te melden bij de juiste instanties voordat ze mij een rechtzaak aan de broek hangen.
En naar mijn geweten is er zo'n officieel kanaal. Kom alleen op internet er niet achter waar!

Ik vindt het daarom een slechte zaak dat zelfs FoxIT dat niet op de website heeft staan.
Ga ze wel ff contacteren en anders word het Publeaks

[RobIII]

DJMaze schreef op donderdag 07 november 2013 @ 15:41:
Publeaks is inderdaad een goed idee.
Maar ik ben natuurlijk verplicht om het eerst allemaal netjes te melden bij de juiste instanties voordat ze mij een rechtzaak aan de broek hangen.

Publeaks is anoniem; hoe moeten ze jou dan een rechtzaak aan de broek hangen?

DJMaze schreef op donderdag 07 november 2013 @ 15:41:
En naar mijn geweten is er zo'n officieel kanaal. Kom alleen op internet er niet achter waar!

Ik denk dat jij in de war bent met Meldplicht inbreuk bescherming persoonsgegevens
en/of Wetsvoorstel meldplicht datalekken naar Tweede Kamer o.i.d.

[Thralas]

DJMaze schreef op woensdag 06 november 2013 @ 18:09:
En deze systemen bevatten nog steeds de problemen, zelfs na melding.

En wat was de reactie van de bedrijven achter de betaalsystemen dan, als de problemen er nu nog steeds zijn?

Je zou het bij het NCSC kunnen proberen aan te kaarten als je werkelijk geen respons krijgt van de betrokken bedrijven zelf.

[DJMaze]

Het antwoord was:

Dit is geen probleem omdat onze systemen heel veilig zijn en elke dag worden gecontroleerd.
Wij zullen uw bevindingen in een volgend intern overleg wel meenemen om de code eventueel aan te passen.
Kunt u ons nog even een link sturen naar de website waar het beveiligingsprobleem word uitgelegd?

Nou dat dus

Het probleem bij 2 bedrijven sowieso al: https://www.owasp.org/index.php/PHP_Object_Injection
En bij een ander: http://www.rapid7.com/db/...ttp/php_cgi_arg_injection

[ Voor 21% gewijzigd door DJMaze op 08-11-2013 20:50 ]

[Thralas]

DJMaze schreef op vrijdag 08 november 2013 @ 20:47:
Het antwoord was:

Ouch. Meestal ligt het probleem bij het bereiken van de juiste persoon, en wordt 't vervolgens serieus opgepikt, maar hier lijk je tussen wal en schip te belanden.

Het probleem bij 2 bedrijven sowieso al: https://www.owasp.org/index.php/PHP_Object_Injection
En bij een ander: http://www.rapid7.com/db/...ttp/php_cgi_arg_injection

Leg het bij het NCSC neer ([e-mail]). M'n ervaring is wat wisselend, maar ze hebben me een keer eerder aan een fatsoenlijk contactadres geholpen. Die snappen in ieder geval wel wat de impact is van RCE vulns.

Het feit dat je nu nog CVE-2012-1823 tegenkomt is wel erg schandalig, zeker als het een payment provider betreft (of zij indirect verantwoordelijk zijn voor een brakke, archaische PHP-setup, maar dat lijkt me vreemd).

Succes.

[Djelli]

het meldpunt voor de ACM is voor bedrijven en instanties om 'lekken' van privacy gevoelige informatie te melden. Dat zijn zij verplicht volgens wetgeving.

ACM heeft (even snel op de site gekeken) wel een loket om, eventueel anoniem, misstanden te melden. Het lijkt echter vooral te gaan over illegale prijsafspraken.
https://www.acm.nl/nl/con...elding-doorgeven-aan-acm/

Als je vermoed dat bedrijven nalatig zijn dan is dat denk ik het melden waard. Nu nog hopen dat de toezichthouder correct omgaat met meldingen, en er wat mee doet.

[SeaFish]

Ik denk dat het nationaal cyber security centrum (ncsc) van de overheid het juiste adres is voor je meldingen:
https://www.ncsc.nl/organisatie/contact.html

[Boudewijn]

Je kunt dit inderdaad beter via responsible disclosure doen bij het NCSC.
Zie hier de manier waarop responsible disclosure eruit kan zien:
https://www.ncsc.nl/diens...rs/responsible-disclosure
En hier hoe ze het bij NCSC doen:
https://www.ncsc.nl/security
Als je echt wat meldt houd je er ook nog een tof t-shirt (of geld) aan over. Doen ze best netjes .

[ Voor 18% gewijzigd door Boudewijn op 20-11-2013 18:51 ]

[DJMaze]

Top, dat was het antwoord wat ik zocht: NCSC
Eindelijk!

[Rikkiz0r]

Ben erg benieuwd hoe ze het zullen behandelen, keep us updated.

[The Eagle]

Of je belt een paar van hunklanten. Bij voorkeur de grote banken. Is het ook zo opgelost, die banken zijn veel te bang voor hun goede naam en hun beursnotering

[sjosz]

En? Hoe is het afgelopen?

[EnnaN]

Ja, ook wel benieuwd, vooral die in "ideal". (wat overigens nogal een breed begrip is, er is niet echt een "ideal" code natuurlijk, wel verschillende implementaties van banken)

Los van bovenstaande voorbeelden, kun je natuurlijk altijd via hackerone gaan werken, als er een programma is daar: https://hackerone.com/programs

[DJMaze]

De problemen zijn opgelost en de API aangepast.

De enige die ik nog niet weet is die van iDEAL.
Bij iDEAL is het namelijk mogelijk om in v3 een sha1 certificaat te gebruiken terwijl dit niet mogelijk zou moeten zijn.
Ik kwam hier achter bij een webshop die niet kon upgraden naar PHP5.
Heb dit ook niet verder uitgezocht maar er bleek meer te kunnen met sha1.
http://mhxsolutions.nl/ideal/certificate.php

[Thralas]

DJMaze schreef op woensdag 31 december 2014 @ 18:07:
Bij iDEAL is het namelijk mogelijk om in v3 een sha1 certificaat te gebruiken terwijl dit niet mogelijk zou moeten zijn.

Zou dat niet mogen volgens de documentatie van iDEAL, of is dat jouw mening?

In dat laatste geval kan ik me voorstellen dat het een bewuste keuze is, al dan niet ivm. legacy support. Zou me er verder niet te druk om maken, ja SHA-2 heeft de voorkeur, maar er staat voorlopig nog niets in brand

edit:
Bij nader inzien, die certificates worden enkel gebruikt voor XML signing lijkt het. Hoe men de certificates trust is me ook onduidelijk (self-signed mag blijkbaar ook), dus wat de exacte theorietische(!) impact is, is imo uberhaupt lastig vast te stellen zonder verdere kennis van hoe iDEAL merchants authenticeert.

Desalniettemin zou het een organisatie als iDEAL sieren om SHA56-based signatures af te dwingen voor nieuwe certificaten, als daar clientside support voor is.

[ Voor 19% gewijzigd door Thralas op 02-01-2015 13:24 ]

[DJMaze]

Thralas schreef op donderdag 01 januari 2015 @ 12:49:
[...]


Zou dat niet mogen volgens de documentatie van iDEAL, of is dat jouw mening?

In dat laatste geval kan ik me voorstellen dat het een bewuste keuze is, al dan niet ivm. legacy support. Zou me er verder niet te druk om maken, ja SHA-2 heeft de voorkeur, maar er staat voorlopig nog niets in brand

Desalniettemin zou het een organisatie als iDEAL sieren om SHA56-based signatures af te dwingen voor nieuwe certificaten, als daar clientside support voor is.

De documentatie zegt:

iDEAL Merchant Integration Guide - Summary of Changes
Version 3.3.1

For hashing purposes the SHA256 algorithm must be used. For signature purposes RSA keys
must be 2,048 bits long.

Blijkbaar zou het dus niet mogen

[Thralas]

Nou, er is iets vreemds aan de hand. In het stukje boven je quote suggereert men dat het enkel XMLSIG (voor het signen van iDEAL messages) omvat.

Maar, in 8.4.1 stelt men dat een certificate van een third party CA signed moet zijn met een CA die tenminste RSA2048/SHA-256 gebruikt, omdat de merchant certifcates niet 'minder secure' mogen zijn. Dat laatste impliceert dat eerdergenoemde constraints toch ook gelden voor voor certificates, maar ik zie het dus niet expliciet vermeld..

tl;dr wat een vage standaard (als 3.3.1 het meest recent is). Lijkt me inderdaad iets dat je inderdaad even wil aankaarten, zij het meer om de standaard dan de implementatie.

[DJMaze]

De implementaties van iDEAL zijn in sommige gevallen inderdaad erg ruk.
Ik kon bij 1 bank geen betaling doen omdat de http referer header gecontroleerd werd (die heb ik leeg).
Vervolgens had ik in het betaal formulier op de betreffende website een hidden veld aangemaakt met:

code:

<input type="hidden" name="HTTP_REFERER" value="example.com">

Guess what, de betaling werkt nu gewoon.

Tja, welke programmeur bij de bank heeft het in zijn hoofd gehaald om beveiliging in te bouwen op basis van manipulatieve data?

[ Voor 26% gewijzigd door DJMaze op 02-01-2015 16:14 ]

[DJMaze]

ING blijkt nu ook met mijn iDEAL hack bezig te zijn.
Een klant van mij kreeg vandaag het volgende bericht.

Het iDEAL berichtenverkeer tussen uw webwinkel en het iDEAL systeem dient veilig te zijn. Daarom wordt elk iDEAL-bericht dat u verstuurt en ontvangt beveiligd met een digitale ‘handtekening’. Bij deze digitale handtekening wordt gebruik gemaakt van een zogenaamde sleutel of signing-certificaat.

Deze sleutel of signing certificaat moet volgens de iDEAL standaard aan bepaalde eisen voldoen:
· Het algoritme voor de versleuteling moet het RSA SHA256 algoritme zijn
· RSA sleutel van minimaal 2048 bits
· Maximaal 5 jaar geldig

ING heeft geconstateerd dat u een signing certificaat gebruikt dat niet voldoet aan deze eisen.

Het heeft even geduurd