SSL Validation Checking Vs. Go(ing) To Fail

2y ago
95 Views
2 Downloads
2.13 MB
25 Pages
Last View : 10d ago
Last Download : 3m ago
Upload by : Abby Duckworth
Transcription

SSL Validation Checking vs.Go(ing) to FailThomas Brandstetter

Presentation Outline Bio Background for research Architecture & Testing Concept Results

BIO Founder and GM of Limes Security Independent security consultingcompany, part of SoftwareparkHagenberg, Austria 2 major focus areas Secure Software Development Industrial Security Strong industrial background: Formerhead of Siemens ProductCERT &manager of Hack-Proof ProductsProgram Associate Professor at University ofApplied Sciences St. Poelten,Austria Classes: Web- & Application SecurityPenetration TestingIndustrial SecurityBotnets & HoneypotsCERTs & Incident Response Research Interests: IndustrialSecurity & Application Robustness

BACKGROUND FOR RESEARCH

Starting Point: Apple’s securityrelated update iOS 7.0.6Source: http://support.apple.com/kb/HT6147

What was wrong in Apple’s SSL code? According to public analysis, the problem resided in a file called sslKeyExchange.c(version 55741) of the source code for SecureTransport, Apple's offical SSL/TLS libraryBuggy code comes as a sequence of C function calls, starting off in SecureTransport'ssslHandshake.c:– SSLProcessHandshakeRecord() - SSLProcessHandshakeMessage() dealing with different aspects of SSL handshake:- SSLProcessClientHello()- SSLProcessServerHello()- SSLProcessCertificate()- SSLProcessServerKeyExchange()Last function is called for various TLS connections, notably where forward secrecy isinvolvedSource: ty-55471/libsecurity ssl/lib/sslKeyExchange.c

What was wrong in Apple’s SSL code? Here, the server uses its regular public/private keypair to authenticate thetransaction, but generates an ephemeral keypair for the encryption (forwardsecrecy)Benefit of forward secrecy is that if the server throws away the ephemeral keys aftereach session, then you can't decrypt traffic from those sessions in the future, even ifyou acquire the server's regular private key by different methods (e.g. demand fromlaw enforcement, bribery or break-in theft)To continue: SSLProcessServerKeyExchange() lead to function call- SSLDecodeSignedServerKeyExchange()- SSLDecodeXXKeyParams()IF TLS 1.2 - SSLVerifySignedServerKeyExchangeTls12()OTHERWISE - SSLVerifySignedServerKeyExchange()Source: ty-55471/libsecurity ssl/lib/sslKeyExchange.c

Tracing the bug further to its root cause insslKeyExchange.cstatic t *ctx, bool isRsa, SSLBuffer signedParams,uint8 t *signature, UInt16 signatureLen){OSStatuserr;.if ((err SSLHashSHA1.update(&hashCtx, &serverRandom)) ! 0)First fail is correctly bound togoto fail;if statement, but the second isn'tif ((err SSLHashSHA1.update(&hashCtx, &signedParams)) ! 0)conditional:Code always jumps to the end fromgoto fail;that second goto, err will contain agoto fail;successful value because SHA1 updateif ((err SSLHashSHA1.final(&hashCtx, &hashOut)) ! 0)operation was successful and so thegoto fail;signature verification will never fer(&hashCtx);Source: ty-55471/libsecurity ssl/lib/sslKeyExchange.creturn err;}

Analyzing what the code probably shouldhave doneCode should calculatecryptographic checksum of threeelements - the three calls toSSLHashSHA1.update(), then callthe critical function sslRawVerify().If sslRawVerify() succeeds, then errends up with the value zero "noerror“That's what the SSLVerifySignedServerKeyExchange functionreturns to say, "All good."The first goto fail happens whenthe if statement succeeds, e.g. ifthere has been a problem andtherefore err is non-zero, causingan immediate "bail with error,"and the entire TLS connection fails.In C, the second goto fail, whichshouldn't be there, alwayshappens if the first one doesn'tThe result is that the code jumpsover the call to sslRawVerify(), andexits the function.This causes an immediate "exitand report success", and the TLSconnection succeeds, even thoughthe verification process hasn'tactually/fully taken place.Source: unofficial-patch/

What did it mean? SSL Validation not working properly: Link between ephemeral key and certificatechain is broken Possible to send a correct certificate chain toclient, but sign handshake with wrongprivate key, or not sign it at all No proof that the server possesses theprivate key matching the public key in itscertificate Forged certificates should lead to errormessage/warning are omitted Thereby making man-in-the-middle (MITM)attacks easierSource: .html

Our thoughts at this pointHow is it possible that this critical bug in asecurity function went unnoticed for a longtime?Could it have been detected?If source code was available: Yes! By Appleconducting source code scans/reviews, indicatingthat code fragment is never reachedIf source code was not available (Most of thetime): Maybe, only if SSL validation checks can besomehow assessed from the outsidesystematically

This lead to our main research questionsWhen having the source code, detecting a bug likegoto fail seems possible, but: To which degree can SSL validation checks of 3rd party apps besystematically assessed if source code is not available? What is the overall state of SSL validation checks conducted byapp(lication) developers currently, are developers doing the rightthings?

SSL VALIDATION FUZZERCONCEPT & ARCHITECTURE

Our designated approachDerive a testing methodology whichallows us to assess whether SSLvalidation checks in different(mobile) applications have beenimplemented properly by the app’sdevelopers – without having accessto the source codeCreate a tool which helps us in thisassessmentCheck the same app on the 3 mainmobile platforms iOS, Android andWindows Phone to look forinteresting patternsRun this tool against a number ofapps which are likely to have SSLvalidation implemented: Candidategroup one: CriticalEBANKING/payment apps!

Main Assessment ComponentsModifiedversion ofMITMproxysoftware,interfacing toSSL ValidationFuzzer Samsung Galaxy S2, Modell GTI9100, running Android 4.1.2,Kernel-Version 3.0.31-1156082State-of-the- Apple iPhone 5, ModellMD297DN/A, running iOS 7.1.1art mobileequipment Nokia Lumia 820,Hardwarerevision 2.4.3.5,running Windows Phone 8.0(8.0.10517.150)Self-developed SSLvalidation fuzzer

Architecture & Setup of AssessmentEnvironment

Testing Approach: Target-oriented SSLvalidation fuzzing/checking

Test cases! But which ones do make sense?How twisted can a developer’s mind be?Case 1: arbitrarycertificateCase 5: invalidHostname, originalserial noCase 9: issuer field ofcertificate does notmatch subject of CACase 2: valid certificateCase 6: invalidsignature, modifiedserial noCase 10: hostname insubject field modifiedCase 13: certificatechain is extended withintermediatecertificateCase 3: invalidnotAfterCase 4: invalidnotBeforeCase 7: invalidsignature, originalserial noCase 8: not signedwith key of CACase 11: no hostnamein subject field,subjectAltNameExtension changedCase 12: version 2certificate with wronghostnme in subjectfield, correct one insubjectAltNameExtensionCase 14: incorrectintermediate-certificate(basicConstraints CA:FALSE)Case 15: tbdList Initial testcases based onx509 standardcertificate fields,In addition:- SSL stripping- Certificatepinning

RESULTS

90 mobile applications tested as ofAugust 8th, 2014)3KundenzoneAirbnbAlinma Bank - مصرف AmazonAmerican Bank –Mobile BankingAnson Bank & Truste-zMobile BankingApothekerbankÄrztebankBank AustriaMobileBankingBAWAG PSKBDSwiss - Die TradingAppBKS Bank ÖsterreichBNY Mellon BusinessBankingBNY Mellon PrivateBankingBörse FrankfurtBörse, Aktien,Aktienkurse finanzen.netBrokerjetBTV Bankingbwin Sportsbwin.com Pokercfd Banking ServicesCommerzbankDenizBank AG –ÖsterreicheasybankE-Central mobileBankingE-POST KontoPilot Banking AppErste Bank /Sparkasse Österreich- netbankingFidor BankFirst Bancorp MobileBankingFX on J.P. MorganMarketsGärtnerbankGerman AmericanMobile BankingGLSHampden BankMobile BankingHDFC BankMobileBankingHYPO LandesbankHypo MobileHYPO NOE MobileBankingHypo VorarlbergImmobiliensuche Wohnnet.atING-DiBa AustriaBanking AppInterwetten –SportwettenJ.P. Morgan adr.comKotak BankLLB Mobile BankingLOTTERIEN SHAKERLufthansamein bobMeine BankMy T-MobileÖAMTCÖBB ScottyOberbankOpenbankPaypalpaysafecardPersonal BankingPizza Mann AustriaPlus500PostPostbankFinanzassistentPrime on J.P. MorganMarketsQuick MacRaiffeisen MeineBank.SantanderAccionistasSantander BankSantander RíoSkrillSouthern MichiganBank & TrustSparda-BankSPARDA-BANK LinzSuncorp BankTeleTradertimrTipico SportsTrader's BoxTyndall e-BankingUBS Mobile BankingVeroPayVolksbank MobileBankingVP Bank e-bankingmobile AppWells Fargo CEOMobileWells Fargo MobileWKO Mobile Servicesyesss!Mein A1

Results 1 / 2: The bad news Even in the world of mobile banking apps: In 2014 there are still severalapps of European / international banks (regardless of company size) that donot apply ANY validation checking and are susceptible to MITM attacks Total fail Several lower degrees of failed validations found Some apps are susceptible to SSL stripping, allowing for undetectedmalicious redirects e.g. “good” way of supporting phishing purposes Some payment apps transmit quite a bunch of (device) data possibly forfraud detection, maybe raising privacy concerns Some use out-of-band tcp connections for whatever reasons

Interesting to see what data is being sent by an app,e.g. Paypal, probably for risk/fraud estimation:device info:2 {"device ,"device os":"Android","dev3 ice name":"GT-I9100","device model":"GT-I9100","pp app id":"APP-3P637985EF709422H","de4 vice os version":"4.1.2","device type":"Android","device key type":"ANDROIDGSM PHONE",5 "is device simulator":"false"}67 app info:8 {"device app id":"APP-3P637985EF709422H","client platform":"AndroidGSM","app version":9 "5.4.3","app category":"3"}1011 risk data:12 {"sms enabled":true,"conf risk\/dyso13 n config v2.json","is rooted":false,"network operator":"23210","payload type":"full","14 ip addrs":"192.168.45.100","app version":"5.4.3","is emulator":false,"conn type":"WIFI15 ","comp version":"2.1.3","os type":"Android","timestamp":1401226027532,"risk comp sess16 ion id":"396c4bd0-5a1e-4395-b3ad-eb67cecdb88b","device model":"GT-I9100","device name"17 :"GT-I9100","sim serial y","roaming":fal18 se,"device uptime":284285979,"cell id":7441899,"phone type":"gsm","mac addrs":"04:46:619 5:4A:CA:59","subscriber id":“XXXXX922600356","ip addresses":["fe80::646:65ff:fe4a:ca520 9%wlan0","192.168.45.100"],"device id":“XXXXX0044348101","app guid":"c5eeca5e-56ef-48721 8-af58-09b1e6a0e056","locale lang":"de","os version":"4.1.2","locale country":"AT","bs22 sid":"64:66:b3:c7:0b:bd","linker on23 area code":2031,"app id":"com.paypal.android.p2pmobile","total storage space":1235337224 160,"tz name":"Mitteleuropäische Zeit"}

Results 2 / 2: The good news Several banking/payment apps do exist which apply all SSLvalidation checks – homework properly done Certificate pinning is being done some cases(platformdependent) but not totally widespread If platform-provided validation functions are used instead ofhome-grown code, results look more decent (as long as there’sno other go-to fail of course )

Summary & Take-Aways Assessing SSL validation checks of a 3rd party app(lication) ispossible to a good degree even without source code Even in 2014 in the banking sector, SSL validation checking isnot done properly in all cases – bad guys have probablyfigured out where(locally) it’s worthwhile More education of developers creating apps with securechannels seem to be necessary to prevent the next go-to failfor widely-used apps

Thanks to:Christian Stoiber/FH St. Pöltenfor first working conceptPeter Panholzer/Stefan Keil of Limes Securityfor ideas and refinementMore information available atwww.limessecurity.com/sslvalidationContact info:thomas@limessecurity.com

BNY Mellon Business Banking BNY Mellon Private Banking Börse Frankfurt Börse, Aktien, Aktienkurse - finanzen.net Brokerjet BTV Banking bwin Sports bwin.com Poker cfd Banking Services Commerzbank DenizBank AG – Österreich easybank E-Central mobile Banking E-POST KontoPilot - Banking App

Related Documents:

l DecryptionServices DPI-SSL/TLSClient l ViewingDPI-SSLStatus l DeployingtheDPI-SSL/TLSClient DecryptionServices DPI-SSL/TLSClient TIP:ForinformationaboutDPI-SSL,seeAboutDPI-SSL. SonicOS7DPI-SSLAdministrationGuide ConfiguringtheDPI-SSL/TLSClient 2 8

administrators of Windows Server 2003 & 2008R2 to harden SSL/TLS support. Administrators can manually edit and backup the SSL configuration and set PCI-DSS compliant SSL rules with a click of a button. Link SSL Audit (alpha) - A remote SSL audit tool able scan for SSL/TLS support against remote servers.

Proposed SSL 2015 Salary Midpoints versus SSL 3 and Market Present (SSL 3) SSL 2015 Midpoint SSL 2015 Midpoint/Market Benchmark (%) 11,400 154 12,084 144 12,809 135 13,578 127 . SSL 2015 vs. Market for Nurses (Total Guaranteed Compensation PBB) 17 (254%) (281%) (209%) SSL 2015 vs. Market for Teachers (Total Guaranteed Compensation PBB) 18 .

Go to SETUP - VPN Settings - SSL VPN Server - SSL VPN Policies, create a policy that allow the SSL VPN users to access remote network. Add a SSL VPN policy and follow below parameters on SSL VPN Policy Configuration Page. Policy For: Global Apply Policy to: All Addresses Policy Name: Allow_all_address Begin: 0 End: 65535 Service: All .

Cleaning validation Process validation Analytical method validation Computer system validation Similarly, the activity of qualifying systems and . Keywords: Process validation, validation protocol, pharmaceutical process control. Nitish Maini*, Saroj Jain, Satish ABSTRACTABSTRACT Sardana Hindu College of Pharmacy, J. Adv. Pharm. Edu. & Res.

1 Navigate to the DPI-SSL Client SSL Certificates page. 2 Scroll to the Certification Re-signing Authority section. 3 Select the certificate to use from the Certificate drop-down menu. By default, DPI-SSL uses the Default SonicWall DPI-SSL CA certificate to re-sign traffic that has been inspected.

The document focuses on SonicWall SuperMassive next-generation firewalls for DPI, and A10 Networks Thunder SSL Insight (SSLi ) for SSL decryption and FWLB. INTRODUCTION With the end-to-end security promised through SSL encryption, the threat of hidden attacks continues to increase, mandating organizations to decrypt and inspect SSL traffic.

The Juniper Networks SA2500, SA4500, and SA6500 SSL VPN Appliances meet the needs of companies of all sizes. SA Series SSL VPN Appliances use SSL, the security protocol found in all standard Web browsers. The use of SSL eliminates the need for pre-installed client software, changes to int