Betalingsverkeer PayPal onveilig door brak SSL-gebruik

Programmeerfouten in apps die onder meer libraries van PayPal en Amazon gebruiken, zorgen ervoor dat een vervalst SSL-certificaat gewoon wordt goedgekeurd en een 'beveiligde' verbinding wordt opgezet.

Betalingsgegevens die klanten versturen naar Amazon of PayPal zijn bij veel apps niet goed beveiligd met een SSL-certificaat, terwijl dat wel zou moeten. Door ontwerpfouten worden SSL-verbindingen tussen betaalservers en klanten opgezet, ook als het juiste certificaat ontbreekt.

Een man-in-the-middle-aanval kan daardoor gewoon worden uitgevoerd op de verbinding, terwijl dat onmogelijk zou moeten zijn. Het probleem ligt volgens de onderzoekers bij fouten in het ontwerp van verschillende apps, maar de onderliggende oorzaak moet gezocht worden bij de onduidelijke API's van SSL-libraries.

Programmeerfouten in apps
Onderzoekers van Stanford en de University of Texas bekeken hoe applicaties op Linux, Windows, Android en iOS omgaan met SSL (PDF). "Onze belangrijkste conclusie is dat SSL-certificaat-verificatie helemaal kapot is in veel kritische applicaties en libraries." De oorzaak zit in het slechte ontwerp van de API's die de onderliggende SSL-libraries gebruiken, stellen de onderzoekers.

Via de 'beveiligde' verbinding van een slecht ontworpen API kunnen belangrijke gegevens worden onderschept door een hacker, zonder dat dit voor de zender of ontvanger duidelijk is. "Dit is precies het soort aanval waar SSL tegen hoort te beschermen", stellen de onderzoekers. Het gebrek aan een juist certificaat moet ervoor zorgen dat de verbinding niet kan worden misbruikt.

De wetenschappers ontdekten programmeerfouten waardoor verificatie werd uitgeschakeld en gevallen waarin libraries verkeerd werden gebruikt. In één wrang voorbeeld probeerde PayPal een verificatieprobleem op te lossen door een verify van "false" naar "true" te veranderen. "Helaas is de correcte waarde van deze parameter '2'; het wijzigen van de waarde in 'true' verandert deze stilletjes naar '1' en zo wordt certificaatverificatie uitgeschakeld."

Standaard onveilige libraries
De onveilige apps implementeren zelf geen SSL maar gebruiken een library, bijvoorbeeld OpenSSL, GnuTLS of JSSE. De API's die deze libraries dan weer gebruiken zijn volgens de onderzoekers onduidelijk en leiden tot misverstanden bij programmeurs. De belangrijkste oorzaak van de brakke SSL-implementatie ligt dan ook niet bij de ontwikkelaars van de apps die SSL zouden moeten implementeren, maar in het ontwerp van de SSL-libraries zelf.

Eerder deze week schoven Duitse onderzoekers dit probleem nog in de schoenen van app-ontwerpers. Maar volgens hun Amerikaanse collega's is de ingewikkelde SSL-library het overkoepelende probleem. "Veel SSL-libraries zijn default onveilig en met software moeten de opties correct worden ingesteld." Uit diverse voorbeelden blijkt dat programma's die met deze libraries zijn ontworpen SSL verkeerd gebruiken.

De onderzoekers vinden het verontrustend dat ontwikkelaars bij problemen met SSL-libraries in hun apps er vaak voor kiezen om certificaatverificatie simpelweg uit te schakelen, zo blijkt uit een inventarisatie van reacties op programmeursforum Stack Overflow. "Helaas verschijnen dit soort slechte ontwikkelaarspraktijken ook in kritieke software die financiële informatie en gevoelige data verstuurt. Hier is beveiliging tegen een man-in-the-middle-aanval essentieel en hierin zou SSL-certificaatverificatie verplicht moeten zijn."

Beter testen, libraries herontwerpen
De oplossing ligt in het beter testen van de software om te zien wat er gebeurt bij een onverwachte waarde. "In veel van onze case studies is het duidelijk dat de software nooit getest is met andere certificaten dan die de server gebruikt."

"Als de server met een AllYourSSLAreBelongTo.us-certificaat in plaats van met het verwachte Amazon of PayPal-certificaat wordt geconfronteerd, leggen deze gretig een SSL-verbinding en worden geheimen uitgespuugd. Deze kwetsbaarheden zouden bij tests moeten zijn opgedoken."

Verder raden de onderzoekers ontwikkelaars aan om niet te vertrouwen op standaardinstellingen van SSL-libraries. De defaultwaarden kunnen per versie verschillen, dus programmeurs kunnen beter de opties expliciet instellen. Daarom adviseren de wetenschappers de makers van SSL-libraries om de semantiek van hun API's duidelijker te maken.

Uiteindelijk moeten de verwarrende API's opnieuw worden ontworpen, stelt het onderzoek. "Deze aanbevelingen zijn oplossingen voor de korte termijn. Voor een belangrijke oplossing van dit probleem is een volledig nieuw ontwerp van de API's van SSL-libraries nodig."