Commit 3acf596a authored by Clark's avatar Clark

Initial commit

#+TITLE: Car Hacking: A Security Analysis of In-Vehicle-Infotainment and App Platform
#+DATE: January 24, 2020
Sahar Mazloom
Results of research conducted several years ago
Increasing trend to integrate 3rd Party App platforms into IVI (In-Vehicle-Infotainment) systems.
Research studies: to what extent are these systems vulnerable?
* Modern Vehicle Architecture
ECU - Electronic Control Unit:
monitor and control different subsystems: engine control, driver assist, hvac, + non critical components. Designed to overcome hardware limitations.
CAN - Controller Area Network, network over which ECU's communicate
Every single device is connected to CAN bus controller.
There are some components that work as internal proxies, for example. Others that act like a gateway or firewall.
OBD-II port - On Board Diagnostic. Acts like ethernet jack for a car. Mandated by US govt!
** CAN Bus
Broadcast nature of CAN. CAN packets are similar to network packets from a pcap.
There is /no/ confidentiality in CAN bus communications.
There is /no/ authentication. Easy to impersonate.
There is /no/ integrity. Just CRC for error checking.
Garage workers abuse this port to modify ECUs. CAN bus access is critical (and pwn!)
* Current State of Auto Security
** History
May 2010, first demo of CAN bus abuse. After disclosure, regulators did not take notice until several years. Car security was thought of /only/ as seatbelts, airbags, etc.
Gaining access, or delivering and exploit, to /any/ ECU permits trivial pivoting to another ECU, because the CAN network is wide open one inside.
Telematics Unit: On-Star, was adapted by many manufacturers. Sends signals in analog form. Researchers founds a buffer overflow in Telematics unit between analog modem and data processing code. The researchers could hijack the car by delivering particular 'song of death' - which was the sound of a dial-up modem sending data... which was the transmission of the buffer overflow payload.
Remote Access was possible on a 2014 Jeep Cherokee via Uconnect head-unit and Telematics... resulted in recall of 1.4mm cars! Found similar vuln on the patched cars!
Cars can be hacked via insurance dongles, which insurers attach to cars to enable kill switches for customers that don't pay.
Jamming/replaying/hijacking keyless entry systems is also trivial. Sammy (Kumar?) developed this attack w/ successful POC.
* Findings
** Anatomy of an Attack
Head Units - infotainment systems get equiped with expensive extra features. To combat this, manufacturers introduced 3rd party connections.
- Apple Car Play
- MirrorLink - intended to mirror the phone display on the IVI head unit
The attack, while executed by [speaker] on a particular car w/ some phone, can be executed on many cars, and via many types of smartphones.
** Attack
Targets mirrorlink.
*** MirrorLink Components:
IVI (Client) -[mirrorlink connector via microUSB]- Smartphone (Server)
RTP, UPnP, VNC, DAP - Application Layer
UDP/TCP - Transport layer
IPv4 - Network layer
USB 2.0 + BT - Physical layer
UPnP (Universal Plug-n-Play) is the most vulnerable protocol here, although there are variety of vulns on the stack.
- UPnP - usually allows unknown devices to communicate with one-another, typically requiring no configuration. Super fucking vulnerable. Final step of the protocol communication, request sent to add a trusted device. Data format is XML, with information leaked like crazy.
Easy to impersonate server by sending malformed XML files to the client (car IVI). Required reverse engineering hardware from the IVI system, desoldering chips, buying specialized chips readers... ultimately were able to dump the firmware.
Discovered and focused on binary files in IVI firmware: TMSControlPoint.DLL and AppTm.EXE
Discovered lacking mitigations:
- No ASLR, for example.
** UART + JTAG Debugger
Most important tools. Fuzzed radio and saw reaction.
Unsafe libc functions used: memcopy! + no ASLR. Easy buffer overflow!
*** Vuln to Exploit
After discovering buffer overflow and crashing program, confirming stack pointer redirection. Looked for function pointers in .data section of memory, but Windows introduced some mitigations.
Developed ROP chain to perform, some-8 jumps to the specific location in memory for a pointer to memcopy.
High level steps:
- Overflow Buffer on Heap
- Overwrite Function Pointer - allows attacker to send any kind of packet to CAN bus
It's also *trivial* to /enable/ MirrorLink on an IVI that doesn't even have it enabled! Basically all IVIs are vulnerable to this...
* Lessons Learned
** Future Research
Self-Driving Cars, have tons of sensors, can easily be tampered with and confused (e.g., making a car interpret a stop sign as a speed limit sign)
Also V2V (vehicle-to-vehicle) communication
#+TITLE: Hacking Cryptocurrencies, Execution of 51% Attack
#+DATE: January 24, 2020
Mark Nesbitt
51% Attack double spend attacks: Walking through examples from the wild and identifying patterns.
** CIA Triad in Crypto Context
Most blockchains use PKI.
Wallets hold private keys. Anyone can build a type of wallet on top of a blockchain.
- Confidentiality: Leaking pivate key
- Integrity: modifiying transaction
Availability: Usually results in permanent loss of funds, therefor less common attack vector.
** 51% Attack via CIA Triad
Confidentiality: there is none, by design
Availability: Due to protocol design issues
Integrity: Focus of this talk, modifying data on the blockchain
*** Exchanges' Attack Vectors
Exchanges hold crypto
Liquidity/volume is important
Speed of transactions
Remote interaction
Some exchanges claim to provide anonymity
*** Exploit
Blockchains are shared, append-only, in batches of transactions (blocks).
Who and how is block N+1? Varies by cryptocurrency. One of the major characteristics!
High profile examples:
- Validator node voting
- EOS - elections and turn0-taking
- Tesos - Proof of stake (% of funds)
- BTC/ETH - Proof of work, via computational effort
**** Proof of work exploit: Stealing BTC from Coinbase via Computational Power Over "MUH"
Generally done by brute forcing a computaitonal problem, then being able to add a block to the chain. If there is a dispute (i.e., 2 /canonical/ blocks), then the chain splits (forks), and whichever forked blockchain has the most additional blocks (consensus) is considered legit, by having shown most proof of work,
An attacker could deliberately "hold back" blocks that were discovered, and then releasing all to the chain simultaneously and quickly show a significant amount of work on the blockchain...
This is why, to validate a block, the best way to do so is waiting for a lot more newly discovered blocks to appear.
Suppose an attacker has computational power over a crypto MUH.
Attacker can conduct secret mining activity on 2 blockchains in MUH - where the attacker sends funds to Coinbase on chain 1, and sends the same funds (*double spend*) to another attacker controlled wallet on chain 2. Then, once Coinbase confirms it (and the attacker exil's BTC via Coinbase via conversion), the attacker changes the true blockchain on MUH to chain 2, and recovers the funds.
The more of MUH an attacker owns, the more they can double-spend and steal.
** Detection
51% attacks are easy to detect:
Reorganizations (Reorgs) happen often in blockchains (imagine random race conditions via network speed). But, a "deep" reorg happens with many blocks change - this is observable via the hash of recent blocks.
The smoking gun for coinbase is when they receive MUH from a wallet on chain 1, which vanished as part of an observable reorg.
It's similar to bouncing a check.
** Real world attacks, ETC (Ethereum Classic) 51% attack
Over a 12-month period, observer 2x reorgs, each 6 and 7 blocks each, orphaning 5 and 6 recent blocks respectively. No double-spends were attempted.
Then, 57 blocks were popped off on 1/5/2019 and lots of double-spends were pushed
See ETC, VIRT, and BTG
** Patterns
If not detected, an attacker can repeat this attack against an exchange until detected.
Theoretically, an attacker can double their double-spend on each successful fork. Can observe this pattern by analyzing historical double-spends
There's also patterns in the timing of attacks.
There's also sometimes /suboptimal/ transaction placement, indicative of fishy business. .e.g., it's unusual for an attacker to place a known block deep in a chain (and attempt to orphan 14 blocks). Often, an attacker does enough computational work to orphan /more/ blocks, but places their starting block in a suboptimal block.
** Evasion techniques
Moving transactions around to (many) different owned wallets for originating transactions.
** Q&A
Blockchains w/ protocols requiring less computational power for proof-of-work can be overwhelmed more easily.
#+TITLE: [in]secure Deserialization, and how [not] to do it
#+DATE: 1/23/20
Alexei Kojenov
Exploit Gen: ysoserial
All code shown today is on github: at, only dependency is vagrant
* Definitions
object (program A) -(serialzation)-> byte stream -> x -> byte stream -(deserialization)-> object (program B)
where X: persistent storage, network, REST API, etc.
* Formats and Languages
Java, Python, .NET
Human readable:
JSON, YAML, etc.
* Demos
Object Output Stream, (other a method like, write object), performs serialization.
Read Object performs deserialization.
Typical parts of any class.
** Hexdump object files
Can hexdump an object w/ =xxd= and see it's format.
For example, see Python writing an object to file, then hexdump... it's nothing special. Lots of info is leaked, and can be tampered with
** Session cookies
Trivial to execute. See browser localStorage and decode base64 fields
Always verify integrity and authenticity
** Unvalidated Deserialization on Server
Death by deserialization. Can force N GB of RAM consumption w/ a small object.
** Java Whitelisting
To prevent malicious uploads with non-whitelisted classes.
** Python __reduce
Executes code, before any deserialization. Pwn! Allows remote code execution, for example.
class rce(object)
def __reduce(object):
Similar methods in Java, but a little more code to execute.
** CyberArk Password Vault (.NET gadget chain)
RCE via a .NET gadget chain attack
REST API auth token is vulnerable:
A serialized .NET object
No integrity checking
No class type validation
See ysoserial.exe to develop exploits and pipe to curl to deliver.
* Toolset
Need to know:
- Reverse engineering, any method
- ysoserial, payload generator for Java
- Burp Suite
- Write custom code
* Takeaways
- Can be dangerous!
- Need to validate all input: format, where is it from, mTLS
- 3rd Party components are vulnerable
#+TITLE: JWT Parkour: Attacking JSON Web Tokens
#+DATE: 1/23/20
Jouse Nyffenegger
Lots of interesting bugs lie in Applied Cryptography. It is difficult to teach by making up protocols - impractical.
JWT is a good way to learn applied crypto.
* Background
** Why use JWT?
- for OAuth2
- for sessions
- to manage trust
- for password reset
- for signing infomation
- JWT - Token
- JWE - Encrypted
- JWS - Signature
- JWK - Key
- JWA - Algo
Multiple ways of signing:
symmetric - HMAC
JWS Compact format - JSON format with:
1. Header
2. payload
3. signature
All base64 encoded with padding. Designed to work well w/ HTTP. e.g., Takes out equals/slashes. The padding is missing/removed. When encoding/decoding, need to take care.
Format is easy to detect.
** Header
Algos: lots supported, and multiple ways to implement. Asymmetric better for security, where private key only kept on one server. Harder to deploy, hurts performance, requires more power.
** Payload
Anything in here. There are some reserved claims:
** Signature
After creating Header + Payload, encode it, then sign header.payload
Verifying requires lots of steps, which provides large attack surface
* Vulns
Some apps don't verify signature...
** None Algo
Some tokens use *none* algorithm... most often used for debugging, can be used when tampering with payloads to trick a server.
** Weak Secrets
/ Trivial Secrets. Can be cracked offline. Supported by hashcat.
** Algorithm Confusion.
Signed of token controls algo used to verify. Imagine having a RSA token. Consider, changing the algo from RSA (PKI) to HMAC (symmetric), and using the same [public] key, and the verifier may accept. Need a library that accepts RSA and HMAC, and also has non-hashed public key.
** Kid Injection
Get signed token with kid parameter.
SQL injection attack.
Sign token using return value from SQLi
** CVE 2018-0114
JWS allows to add jwk attribute to header, to tell receiver key used to sign token.
Node-Jose trusts embedded jwk keys.
** jku and x5u
References to URL. Exposes CSRF bugs.
See jku and x5u headers.
Remediation is to filter URL, but it's difficult to implement.
startsWith is vulnerable (if not used w/ URL encoder)
jku vulns:
- Open Redirect
- Header Injection - 2 steps, inject key into db
- Downgrade attack on TLS. Some libraries implement TLS wrong. Enforcing when you set the value vs fetch the key
* Recommendations
- Review 3rd party libraries.
- Make sure check signature.
- Make tokens expire.
- Enforce the algorithm.
JWTs are complex and insecure by design. Check paseto for newer, better implementation.
* Q&A
Key rotation best practices? Not written into JWT spec at all.
\ No newline at end of file
#+TITLE: Building Secure API's and Web Apps, Day 1
#+DATE: January 21, 2020
Jim Manico ---- very important -- this is dope:
What is this class?
2-day class set primarily for a web developer. Intended for web developers and API programmers.
We are focusing primarily on defense. We will cover attack theory very briefly.
* Testing Live Sites
Rely on using HTTPS correctly for good cryptography and to prevent data leakage.
RetireJS browser add-in
* HTTP Security
Security centric response headers.
How much control does a programmer have over the request: none, obv. And nothing can be done to stop malformed request. Need to defend against it.
Most common defenses: code scanners (SAST), web scanners (DAST), WAFs
Code scanner accuracy is difficult, lots of false positives and negatives.
** Verbs
GET & POST are most common, POST /needs/ a form submission with POST method set. With no method set, a form performs a GET by default.
*** GET
- should be nullimpotent = has no side effects
- should be idempotent = has the same effect on all users
All GET requests imply a URL. URL Parameter Leakage:
- bookmarks
- browser hist
- proxy servers
- web servers
- Referer Request Headers - URL we came from. If sensitive data exists, the host (3rd party) can log it
**** Referrer Header leakage
Previous versions of OAuth did not restrict sensitive data in URLs. Google still doesn't (because data in URLs it's convenient for caching).
HTML link attribute: rel="nonreferrer"
Applies to *a* and *area* elements, telling the browser to omit the *Referrer*
Use =Referrer-Policy=no-referred=
*** POST
More secure, because it doesn't put any data in URL
=Corollary= base jumping. Be sure to include the entire base URL in POST requests, instead of the relative location
Sensitive data need go in the payload; a request body or header. Never in a URL.
** HTTP Response Security Headers Summary
Import response headers to add to your response:
*** Strict-transport-security
*A browser standard.* A response header the server tells the browser. Be sure to include all subdomains!
One can /preload/ their website with HSTS. Register at
Strict-transport-security: max-age=31536000; includeSubdomains; preload
*** X-Frame-Options
- Protect users from click-jacking.
=X-Frame-Options: SAMEORIGIN;=
- Disable the browser's built-in XSS auditor
=X-Xss-Protection: 0;= ....
- Prevents sniffing
=X-Content-Type-Options: nosniff=
- Disable browser caching
Browser caches have a limit. Data remains in the cache until it's full.
#+BEGIN_SRC html
Expires: -1
Cache-Control: no-store, no-cache, must-revalidate, max-age=0;
Last-modified: {now} GMT
Pragma: no-cache
*** Referred-Policy
See above
*** X-Permitted-Cross-Domain-Policies
Disables flash or client-side Java permissions to handle requests
**** CORS
** Origins
Origin is a combination of protocol, host, and port. Different subdomains are /different/ hosts.
Origin Policy Limitations of XHR. XMLHttpRequest cannot send a request from origin A to origin B.
There is a =SOP (Same Origin Policy)=, unless the server provides /explicit/ permission using =CORS= policy.
Cross Origin Resource Sharing
*** SOP and Basic Content Isolation
Isolate using different subdomains:
Another method is to use a /sandboxed iframe/.
#+BEGIN_SRC html
<iframe src="demo_iframe_sandbox.jsp" sandbox=""></iframe>
Apply some of these options:
Allow-same-origin, allow-top-navigation, allow-forms, allow-scripts
The content is assigned a separate origin.
For more granular control, use *Cross-Document Messaging*.
*** Cross Document Messaging
Sending messages:
let f = document.getElementById("frame_one");
f.contentWindow.postMessage("Hello!", "");
Receiving messages:
*See slide*
*** HTML5 Storage
Local Storage and Session Storage
localStorage.setItem("animal", "elephant");
let animal = localStorage.getItem("animal);
Can also use =sessionStorage= instead of =localStorage=.
This data is /Origin-bound/.
*Never* put sensitive data in =localStorage=. It should also be treated as *untrusted*. Validate.
Prefer =sessionStorage= for data that does not need to be persistent.
It's trivial to steal all localStorage for websites that are vulnerable to XSS. See slide 31 (from CORS slides?)
It is /never/ safe to store sensitive data in the browser, in any type of storage.
** CORS - Cross Origin Resource Sharing
=Corollary=: to totally avoid CORS, make server-side requests, between server origins, instead of client validations via CORS.
*** Simple Requests
Must be GET or POST
Cross-origin XHR request: GET
Origin is added to request:
Response: =Access-Control-Allow-Origin: