Initial commit

Car_Hacking.org

+#+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)
+
+Architecture:
+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
+
+
+

Hacking_Cryptocurrencies.org

+#+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.
+

Insecure_Deserialization.org

+#+TITLE: [in]secure Deserialization, and how [not] to do it
+#+DATE: 1/23/20
+
+Alexei Kojenov
+@kojenov
+LinkedIn.com/in/kjenov
+
+Exploit Gen: ysoserial
+
+All code shown today is on github: at https://github.com/kojenov/ideabox, 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
+
+Binary:
+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
+- ysoserial.net
+- 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

JWT_Parkour.org

+#+TITLE: JWT Parkour: Attacking JSON Web Tokens
+#+DATE: 1/23/20
+
+Jouse Nyffenegger
+@PentesterLab
+louis@pentesterlab.com
+
+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
+
+Acronyms:
+- JOSE
+- JWT - Token
+- JWE - Encrypted
+- JWS - Signature
+- JWK - Key
+- JWA - Algo
+  
+Multiple ways of signing:
+symmetric - HMAC
+vs
+PKI - RSA
+
+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.
+
+see https://jwt.io
+
+** Payload
+
+Anything in here. There are some reserved claims:
+
+iss
+sub
+aud
+jti
+exp
+ndf
+iat
+
+
+** 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.

Manicode/.#Day2.org

+user@crane.18592:1585891887
\ No newline at end of file

Manicode/Day1.org

+#+TITLE: Building Secure API's and Web Apps, Day 1
+#+DATE: January 21, 2020
+
+#+BEGIN_VERSE
+SLIDES at https://bit.ly/2TMYeWr
+
+Jim Manico
+
+https://www.owasp.org/index.php/ASVS ---- very important
+https://www.owasp.org/index.php/Cheat_Sheets
+https://www.owasp.org/index.php/Testing_Guide
+
+https://www.ssllabs.com
+https://hstspreload.org 
+https://securityheaders.com
+https://www.caniuse.com
+https://ssl-config.mozilla.org -- this is dope: https://ssl-config.mozilla.org/#server=traefik&server-version=2.1.2&config=modern
+
+https://jsfuck.com
+
+Twitter:
+@0x6D6172696F
+@kkotowicz
+@manicode
+#+END_VERSE
+
+
+
+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.
+
+ssllabs.com
+securityheaders.com
+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).  
+
+Defense:
+
+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!
+
+See HSTS
+
+One can /preload/ their website with HSTS. Register at https://hstspreload.org 
+
+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;=
+
+https://medium.com/bugbountywriteup/xss-auditor- ....
+
+- 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
+#+END_SRC
+
+*** Referred-Policy
+
+See above
+
+*** X-Permitted-Cross-Domain-Policies
+
+Disables flash or client-side Java permissions to handle requests
+
+
+**** CORS
+
+Cross-origin-resource-sharing
+
+** 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:
+
+https://news.example.com
+https://comments.example.com
+
+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
+#+END_SRC
+
+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!", "https://accounts.example.com");
+
+Receiving messages:
+window.A
+
+*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 two.com
+
+Origin is added to request: http://one.com
+
+
+Response: =Access-Control-Allow-Origin: http://one.com=