computer security engineer, carnet, national cert (2010 · 2020. 4. 9. · ul. metodija shatorov...
TRANSCRIPT
2
• Computer Security Engineer, CARNet, National CERT (2010 –2014)
• Erste Group Card Processor, Senior ICT Security Specialist (2014 - 2018)
• Infigo IS Penetration testing team member (2018-)
Trends in mobile application vulnerabilities in the region
Jagor Čakmak
4
Mobile application vulnerability tests
Mobile application test has two parts
Application itself Server side
5
Mobile application vulnerability tests
• To test the whole system we must have the ability to inspect and alter parameters in the communication channel
• Communication channel is protected by a strong encryption
• To successfully conduct the penetration, the first step is to set up a man-in-the-middle proxy
• Problem: Android and iOS do not accept new trusted root certificates• Solution: Devices must be rooted or jailbroken
• Modern applications usually have protection against running on jailbroken devices
6
Mobile application vulnerability tests
• The goal of a penetration test is not to check if is it possible to avoid rooting or jailbreaking a device.
• That is always possible with enough time, since the attacker controls the binary file.
7
Mobile application vulnerability testsThe setup
8
Mobile application vulnerability testsThe setup
9
Common and Interesting Mobile Application Vulnerabilities
When it comes to application running on mobile phones these two vulnerabilities are the most common:
• Local storage
• Fingerprint problem
10
Local storage
• One of the most common vulnerabilities found on a device is using local storage to store secrets in an unencrypted way.
11
Local storage
• Sensitive information should never be stored on the device. If required, such information should always be stored encrypted, in safe locations (i.e. in hardware provided secure storage areas).
12
Fingerprint Problem
• Since not all users have PIN or good pattern for unlocking a mobile phone, some applications with higher security requirements have additional layer of authorization.
• Banking and payment application always required additional PIN for opening.
• For customers' ease of use, and wide availability of fingerprints, banks allowed using this method for entering the application and signing transactions.
• However there is a problem that we found in many applications…
13
Fingerprint ProblemNormal Flow
14
Fingerprint ProblemMalicious Flow
Add a new fingerprint
15
Fingerprint ProblemSecure Flow
Add a new fingerprint
16
Server side vulnerabilities
• Server side testing is very similar to testing any other API for web application
• Once we have our setup working from the beginning of the presentation, we can use a proxy to manipulate the data
• In some cases clients add additional layer of encryption
• This additional layer of encryption solves possible issues within client's infrastructure, but has no effect on security of the application itself
17
Server side vulnerabilitiesAdditional encryption layer
SSL/TLS offload
PCI DSS Scope
AES enc.
18
Server side vulnerabilitiesAdditional encryption layer
• Inner symmetric (AES) key is exchanged and saved in memory of a smartphone.
• Any algorithm for encryption and decryption is already inside of an application.
• Al we need to do is to extract and reproduce this inside of a proxy
19
Server side vulnerabilitiesAdditional encryption layer
SSL/TLS offload
PCI DSS Scope
AES enc.
20
Server side vulnerabilitiesAdditional encryption layer
21
Insecure direct object references (IDOR)
• Most common vulnerability in mobile application testing
• Through this type of vulnerability it is often possible to access:• Payment confirmations
• Account information
• Transaction history
• Client information
• …
• Particularly dangerous if ID of an object is number with increment
22
Insecure direct object references (IDOR)
POST /BankAPI/v1/somePath HTTP/1.1Authentication: NJs7MOgDBOCeKccFo7aduO0dhGALlZCc5Xk0jBsNuyg=Timestamp: 2020-03-23 18:40:50Cache-Control: max-age=5Content-Type: application/json; charset=UTF-8Content-Length: 138Host: somebank.comConnection: closeAccept-Encoding: gzip, deflateUser-Agent: okhttp/3.10.0
{"request":"{"account_id":"4300004001188396EUR","appID":"1","month":3,"year":2020}"}
23
Insecure direct object references (IDOR)
PUT /creditonline/api/ HTTP/1.1Host: somebank.comUser-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:71.0) Gecko/20100101 Firefox/71.0Accept: application/json, text/plain, */*Accept-Language: en-US,en;q=0.5Accept-Encoding: gzip, deflateAuthorization: Bearer [REDACTED]Content-Type: application/jsonContent-Length: 1102Origin: https://somebank.comConnection: closeReferer: https://somebank.com{"id": 11,"upitiID": 13,"upitklijentid": 13,"Composite": {"id": 13,
"aktivan": true...}
24
Insecure direct object references (IDOR)
• vulnerable application should verify if the logged in user has permissions to access the requested objects. If the user does not have required permissions, the request should be denied and logged.
• Use GUID:
9fce9c97-681f-4baf-b4ce-e6bfc0f56af0
25
Lack of Authorization
On more than a few applications there is a possibility to bypass two factor authorization scheme. Here are a few examples:HTTP/1.1 200 OKMax-Forwards: 20Via: 1.0 hrs000lin501 ()Access-Control-Allow-Origin: https://somebank.comAccess-Control-Allow-Credentials: trueAccess-Control-Expose-Headers: [REDACTED]Connection: closeServer: Content-Type: application/jsonContent-Length: 731
{"authorizationType" : "CASE_MOBILE","signInfo" : {"state" : "OPEN","oneID" : "155692207","fees" : [ {"fee" : {"value" : 99990,"currency" : "HRK"
},
26
Lack of Authorization
POST /submit HTTP/1.1Host: somebank.com
{"authorizationType" : "NONE","signInfo" : {"state" : "OPEN","oneID" : "155692207","fees" : [ {"fee" : {"value" : 99990,"currency" : "HRK"
},
27
Lack of Authorization
POST /submit HTTP/1.1Host: somebank.com
{"authorizationType" : “MOBILE","twoFactor" : "TRUE“,"signInfo" : {"state" : "OPEN","oneID" : "155692207","fees" : [ {"fee" : {"value" : 99990,"currency" : "HRK"
},
28
Lack of Authorization
POST /submit HTTP/1.1Host: somebank.com
{"authorizationType" : "MOBILE","twoFactor" : "FALSE","signInfo" : {"state" : "OPEN","oneID" : "155692207","fees" : [ {"fee" : {"value" : 99990,"currency" : "HRK"
},
29
Lack of Authorization
POST /submit HTTP/1.1Host: somebank.com
{"authorizationType" : “MOBILE",
"signInfo" : {"state" : "OPEN","oneID" : "155692207","fees" : [ {"fee" : {"value" : 99990,"currency" : "HRK"
},
30
ChatBot IDOR
• Chatbots are getting really popular. We can do more and more with them, including instructing them to do actions in the name of the client.
31
ChatBot IDOR
{"chatbotID" : "42","action" : {"change" : "SUBSCRIPTION","newStatus" : "PREMIUM","charge" : [ {"fee" : {"value" : 1111,"currency" : "EUR"
},
32
Bonus round - Web Vulnerabilites in Mobile Applications
Sometimes applications are not actually applications.
When application is just wrap around WebView some interesting things can occur like: Cross Site Scripting (XSS)
20
Get in TouchINFIGO IS d.o.o.Karlovačka 24a10020 ZagrebCroatia+385 1 4662 700https://www.infigo.hr
INFIGO IS d.o.o.Ul. Metodija Shatorov Sharlo br. 30/2-171000 SkopjeNorth Macedonia+389 (0)2 3151 203https://www.infigo.mk
INFIGO Software Design L.L.C2902, Level 29, Marina PlazaDubai Marina, DubaiPO Box 5000307United Arab Emirates+ 971 4 512 4081https://www.infigo.ae
Infigo IS d.o.o.Tešanjska 24A71000 SarajevoBosnia and Herzegovina+387 33 821 245https://www.infigo.ba
Infigo IS d.o.o.Tivolska cesta 501000 LjubljanaSlovenia+386 1 777 89 00https://www.infigo.si
INFIGO IS d.o.o.Rr. Bardhok Biba, Pll. Hodaj, Shk. A, Ap.8TiranaAlbania+355 42 42 16 33https://www.infigo.al