Meeting Topic: Exploiting Web APIs Speaker: Matt Scheurer https://twitter.com/c3rkah Abstract: This talk features live demos of Web API exploits against the “Tiredful API”, which is an intentionally broken web app. The objectives are to teach developers, QA, or security professionals about flaws present in a Web Services (REST API) due to insecure coding practices. Examples include: Information Disclosure, Insecure Direct Object Reference, Access Control, Throttling, SQL Injection (SQLite), and Cross Site Scripting (XSS). Many of these vulnerabilities are contained in the OWASP Top 10. Bio: Matt Scheurer works on a Computer Security Incident Response Team (CSIRT) performing Digital Forensics and Incident Response (DFIR). Matt has more than twenty years of combined experience in Information Technology and Information Security. He is the Security Director for the Cincinnati Networking Professionals Association (CiNPA) and a 2019 comSpark “Rising Tech Stars Award” winner. He has presented on numerous Information Security topics at many local area technology groups and large Information Security conferences across the country. Matt maintains active memberships in several professional organizations including the Association for Computing Machinery (ACM), Cincinnati Networking Professionals Association (CiNPA), Financial Services - Information Sharing and Analysis Center (FS-ISAC), Information Systems Security Association (ISSA), and InfraGard.

1. Exploiting Web APIsTheThePwnSchoolProject
July,202020
I mean have
you gotten any insight as
to why a bright guy like this
would exploit some vulnerable
Web APIs?
No sir.
He says he does this
sort of thing for fun.
Exploiting
Web APIs
@c3rkah | https://www.linkedin.com/in/mattscheurer/
https://www.slideshare.net/cerkah/
-Matt Scheurer

2. I work for a big well-known
organization...
As an Information Security
(InfoSec) Engineer,
Performing Digital Forensics &
Incident Response (DFIR)
On a Computer Security Incident
Response Team (CSIRT)
About Me...About Me...
I serve as Chair for the
S||||

3. DisclaimerDisclaimer
Yes, I have a day job.
However…
Opinions expressed are
based solely on my own
independent security
research and do not
express or reflect the views
or opinions of my employer.
BLAME

4. ObjectivesObjectives
I work here:
As a Sr.
Systems Security Engineer
●
Learn and understand
– How API’s are abused by malicious threat actors
– The risks associated with poorly coded API’s
●
See the technical details of how exploited web
API vulnerabilities may lead to a data breach
– We’ve all seen how this plays out in the news

5. What is an API?What is an API?
I work here:
As a Sr.
Systems Security Engineer
Matt’s K.I.S.S. Definition
An API is an “Application Programming Interface”. API’s
allow access or interaction between systems. They often
provide developers and power users with a means to
access or leverage data and services on external or
cloud-based systems and services. API’s may grant read,
write, or modify privileges depending on design,
configuration, implementation, and applied permissions.

6. Why is this important?Why is this important?
Web API’s increase attack surfaces with the
possibility of a potential avenue for compromise,
data exfiltration, destruction, or manipulation in an
otherwise reasonably secured system. Web API’s
are purposely targeted by cyber-criminals in the
event that finding an exploitable vulnerability may
lead to a system compromise and / or a data
breach.

7. What is REST?What is REST?
●
REST is an acronym for REpresentational State
Transfer.
●
Web Services that conform to the REST
architectural style, called RESTful Web
Services, provide interoperability between
computer systems on the Internet.

8. What is the Tiredful API?What is the Tiredful API?
I work here:
As a Sr.
Systems Security Engineer
The Tiredful API is an intentionally broken web
app by design. The purpose of the application is to
teach developers, QA testers, or security
professionals about flaws present in Web Services
(REST API) due to insecure coding practices.

9. Tiredful API VulnerabilitiesTiredful API Vulnerabilities
I work here:
As a Sr.
Systems Security Engineer
●
Information Disclosure
●
Insecure Direct Object Reference (IDOR)
●
Access Control
●
Throttling
●
SQL Injection (SQLi)
●
Cross Site Scripting (XSS)

10. House KeepingHouse Keeping
I work here:
As a Sr.
Systems Security Engineer
●
For demo purposes, I am using the Firefox web
browser with the RESTClient extension
●
Some challenges require authentication under
an account with appropriate access
– Exercises involving access to protected data
require an access key

11. Authentication ControlAuthentication Control
●
OAuth 2.0 Access
– The token credentials consist of an access token
and token secret used in lieu of a username and
password
– The required “token_type” typically uses the string
“Bearer” under most implementations

12. Potential access token exposurePotential access token exposure
●
Some ways access tokens are stolen / exposed
– Intercepting proxy / MitM / HTTP 307 attacks
– Open browser sessions / browser history
– Cross-Site Request Forgery (CSRF) attacks
– Token stored in JavaScript
– Token stored in an unencrypted session cookie

13. Getting StartedGetting Started
I work here:
As a Sr.
Systems Security Engineer
1)Browse to the local Tiredful API home page
• By default, http://127.0.0.1:8000/
2)Click on “User Token”
3)Login to obtain a user token (i.e., ‘batman’)
4)Note the returned “access_token” value

14. Information DisclosureInformation Disclosure
I work here:
As a Sr.
Systems Security Engineer
●
Sensitive data examples
– Financial data (i.e., PCI, account data, credit cards)
– Personally Identifiable Information (PII)
– System / Stacktrace Information
●
Reconnaissance
A3:2017 – Sensitive Data Exposure

15. Demo 1 / 6Demo 1 / 6
I work here:
As a Sr.
Systems Security Engineer
Scenario: Information Disclosure
Objective: Try to get stacktrace information.
A3:2017 – Sensitive Data Exposure

16. Insecure Direct Object ReferenceInsecure Direct Object Reference
I work here:
As a Sr.
Systems Security Engineer
●
IDOR Risks
– Failure to restrict access appropriately
– Threat actors exploiting flaws to gain
unauthorized access to data or traversing
other parts of a system
A5:2017 – Broken Access Control

17. Demo 2 / 6Demo 2 / 6
I work here:
As a Sr.
Systems Security Engineer
Scenario: Insecure Direct Object Reference (IDOR)
Objective: Try to access exam results of another user.
A5:2017 – Broken Access Control

18. Access ControlAccess Control
I work here:
As a Sr.
Systems Security Engineer
●
Risks
– Allowing unintended access from the way a system
or application was designed
– Failure to restrict protected or administrative actions
to authorized users
A5:2017 – Broken Access Control

19. Demo 3 / 6Demo 3 / 6
I work here:
As a Sr.
Systems Security Engineer
Scenario: Access Control
Objective: Try to execute an operation which should be
only allowed to admin users.
A5:2017 – Broken Access Control

20. ThrottlingThrottling
I work here:
As a Sr.
Systems Security Engineer
●
Risks
– Denial of Service (DoS)
●
A way to flood system resources which effectively makes
a system unavailable
●
Prevents legitimate users from access to a system

21. Demo 4 / 6Demo 4 / 6
I work here:
As a Sr.
Systems Security Engineer
Scenario: Throttling (a.k.a. Rate Limit Implementation)
Objective: Force server to respond with HTTP response
code 429 to abuse system resources by launching a DoS
attack.
NOTE: A HTTP 429 response code means "Too Many
Requests".
A5:2017 – Broken Access Control

22. SQL InjectionSQL Injection
I work here:
As a Sr.
Systems Security Engineer
●
SQLi Risks
– Vulnerabilities which allow unauthorized access to a
back-end database
– Abuses
●
Data exfiltration, destruction, or manipulation
A1:2017 – Injection

23. Demo 5 / 6Demo 5 / 6
I work here:
As a Sr.
Systems Security Engineer
Scenario: SQL Injection (a.k.a. "SQLi")
Objective: Find table names of the SQLite database.
A5:2017 – Broken Access Control

24. Cross Site ScriptingCross Site Scripting
I work here:
As a Sr.
Systems Security Engineer
●
Cross Site Scripting (XSS) Risks
– Performs automatic code execution in client
browsers upon access
– Stolen credentials or form data
– Execution of exploit kit payloads
A7:2017 – Cross-Site Scripting (XSS)

25. Demo 6 / 6Demo 6 / 6
I work here:
As a Sr.
Systems Security Engineer
Scenario: Cross Site Scripting (XSS)
Objective: Find parameters accepting cross site scripting
meta-characters.
A5:2017 – Broken Access Control

26. Reducing these risksReducing these risks
●
Recommendations
– Adopting a secure development life cycle
●
Having a security champion on each dev team
●
Testing as early in the SDLC process as possible
– Adhering to the Principle of Least Privilege
– OWASP resources
●
https://owasp.org/

27. QuestionsQuestions
8
1
01
010
Who?
What?
When?
Where?
Why?
How?

28. Thank you for attending!TheThePwnSchoolProject
July,202020
I mean have
you gotten any insight as
to why a bright guy like this
would exploit some vulnerable
Web APIs?
No sir.
He says he does this
sort of thing for fun.
Exploiting
Web APIs
@c3rkah | https://www.linkedin.com/in/mattscheurer/
https://www.slideshare.net/cerkah/
-Matt Scheurer