Identified by OWASP as one of the top-10 security threats facing developers, Underprotected APIs are subject to common exploitation that can be difficult to detect. This presentation outlines the reasoning and methodology behind securing these APIs. By Adam Cecchetti, CEO of Deja vu Security

1. SECURING
UNDERPROTECTED APIS
Adam Cecchetti
Deja vu Security & Peach Fuzzer

2. Hello!
 Adam Cecchetti
 Founder CEO Deja vu Security
 Co-Founder Chairman Peach Tech
 Former Amazonian
 CMU : M.S. Information Network
 SVC : B.S. Computer Science

3. Deja vu Security
 Seattle based operating since 2010
 100s of Web API assessments
 Various stacks, frameworks, and security models.
 IoT, Cryptocurrency, Infrastructure, etc
 Training of developers, engineers, and teams
to better understand modern threats.

4. Peach Tech
 Seattle WA, Spun out 2014
 Web API Security Testing
 Fuzzing framework for Protocols, File formats

5. OWASP A10 : Why all the fuss?

6. TIME IS UNDEFEATED

7. Time Erodes All Things.

8. Security: A Snapshot in Time
 A company, product, technology, group, or
person.
 Made up of a set of components to form that
system.
 The systems components all have a creation
date.
 The ability to withstand any given attack is
temporary.
 No different with computers and hackers
 Except technology moves much faster.

9. You Wouldn’t March This Army
Today

10. You Wouldn’t March This Army in
2116

11. The Problem is Big
 The first step to recovery is the hardest.
 Awareness is good, but it doesn’t cure cancer.
 Security issues must be found they can’t be
created.
 Inherited, passed down the software genepool.
 Plentiful, defense helps but we kick over more
rocks.
 Random, the future is asymmetrically secured.
 Polymorphic, the tools we use to build systems
are security issues.
 We are going to have to start thinking

12. Tick, Tock.
 Data movement is a cadence to how we’ve built things.
 Echoes, the ghosts of usage models past.
 We leave data and code everywhere users go.
 User data replicates every decade or so.
t
Centralized
Distributed
70’s 90’s 2010 2030
80’s 00’s 2020
Mainframe Web/Email Cloud Internet of Me
PC Social Networks IoT

13. Computers are Awesome!
 They don’t LET you do anything.
 They DO anything!
 And only things you tell them
 APIs are the things that enable us to orchestrate
these wonderful machines!
 CPU: AMMA that’s about Machine code to
Microcode
 Good luck with the rest! That’s not what I do!
 General computation is good however it means:
 No reliability, no availability, no security.
 This includes anything we build.
 Complexity leads to side effects and exploitation is
programing with side effects.

14. Memory Leak in /dev/litterbox?!

15. There are Only 4 Security Bugs

16. Bug 1: Data as Code
 What do Cross Site Scripting, SQL Injection,
and Buffer Overflows all have in common?
 They are all data being interpreted as code.
 Any place that user or machine controlled data is
being used, interpreted, parsed; a security issue
awaits.
 This is big enough to master that you can
spend multiple lifetimes right here.
 We’ve actually started to make steps towards
fixing this problem in some places.

17. Bug 2: Gamers are Going to
Game
 Logical Issues require someone to game the
system
 Must try and understand all the unexpected
behavior of the logic of the system.
 Few good ways of automated testing here
 The Meta Game
 Attackers will continue to go for the weakest link
 Unless the time vs. reward scenario is high

18. Bug 3: We Rely on Secrets
 Password1!
 Upper Lower, Numeric, Special!
 Secure by most standards!
 “ Or ‘1’=‘1’; --
 Upper, Lower, Numeric, Special!
 No key words!
 16 characters!
 Secure!
 If not bad jumbles then bits generated by a
machine given back to a machine!

19. Bug 4: The Thing is in the Wrong
Place
 What is this?
 This shouldn’t be here….
 OMG! Why is this here?

20. The “New” Computers
 IoT
 Blockchain
 Literally Everything
 APIs enable us to access them all!

21. If it Turings like a computer…
 REST API
 GET - READ
 POST - WRITE
 UPDATE - UPDATE
 DELETE - DELETE
 Looks like someone took CRUD and threw it over
the firewall.
 Because someone took CRUD and threw it over the
firewall.
 We’ve found how to talk to our computer!
 That someone threw over the firewall.

22. APIs: Data as Code
 Data Interpreted as Code
 Our API let’s a computer talks to our computer.
 Browser JavaScript VM -> API (VM) -> Database
 Computer talks to the computer to get or alter data
from a computer
 Takes user data and hopefully doesn’t turn it
into code (Command Injection, SQL Injection)
and returns some useful data which the VM
hopefully doesn’t turn into attacker controlled
code (XSS, etc).

23. APIs: Logic Issues
 Identification
 Who is accessing the API?
 Authentication
 Have the proven they’re who they say they are?
 Authorization
 Are they allowed to access this function of the API?
 Cross User Testing
 Is someone else accessing the thing that someone else has
access to?
 Replay
 We were allowed to do it once can we do it again?
 Session Management
 For what period of time are they allowed to access or do the
thing?

24. APIs: Weak Secrets
 Session Token Crypto Issues
 Can we make our own tokens or predict yours?
 Can we sign our own API calls or tamper with a signed
API call?
 Password and Key Storage
 Where am I supposed to store this?

25. APIs: This shouldn’t be here.
 API exposed that shouldn’t be
 Admin API to the public
 Data exposed that shouldn’t be
 Data permissions not set right
 API exposes functionality that it shouldn’t
 API not authenticated that should be
 Can we sign our own API calls or tamper with a signed
API call?

26. Enough of the Problem!
 How do we take a snapshot and move it
through time?
 Ensure developers have the security
understanding they need to assess the snapshot
 Understand the snapshot
 Keep the snapshot fresh!

27. Training Developers
 Helps development team become more
security aware
 Helps eliminate future bugs
 Helps knowledge move from one team to the
next
 Good at eliminating a bug classes in code via
halo testing

28. Security Testing
 Better understanding of security for the
architecture and design
 Identify issues of all types
 Takes a snapshot of the API state of security
 Regressing testing of fixes

29. CI Security Testing and Fuzzing
 As API evolves the security snapshot shifts.
 Change enough of the API and the snapshot out
of focus.
 How do we continuously take the snapshot?
 By integrating with the build system.
 API changes? Let’s retest as soon as the build
passes.
 Partial snapshot

30. I borrowed some Peach
slides…..

31.  Agile Development
 Continuous Deployment
 Modern Applications
• In-Browser
• Backed by APIs
 Web APIs and Web Services
• Standard services
• Micro services
Industry Trends

32. CI Pipeline
Build
Peach API
Security
Deploy

33. Peach API Security
Log Monitoring
Traffic
Generator
Log Messages
Test Engine
Target
Service
Target
Service
Target
Services
Fuzzed TrafficValid Traffic

34. Securing Unsecure APIs
 What to look for!
 Data being interpreted as code in your API
 Logic Issues in APIs
 Weak Secrets in APIs and Infrastructure
 APIs functions or data exposed in the wrong
place!

35. Securing Unsecure APIs
 Get a security snapshot!
 Design Review
 Penetration Testing
 Code Review
 Training

36. Securing Unsecure APIs
 Keep the Snapshot Fresh!
 Integrate security checks into build pipeline!
 Unit Tests
 Regression Tests
 Security Tests / Fuzzing

37. Questions?
https://peachfuzzer.com
https://www.dejavusecurity.com
secure@dejavusecurity.com
@dejavusecurity