Digital Log

    Csep-564-Lec-7

    Pixel Perfect Timing Attacks

    • Discussion around the paper.
      • Timing link painting doesn't actually violate the SOP.
      • What about applying an SVG filter to an iframe?
        • You are not supposed to be able to interact with it... so arbitrary image transformations feel contradictory to the SOP.
        • Still allowed in all browsers, Firefox has made the filters constant time though. Safari just forces a null filter on all cross origin content.
    • Note: ad tech companies are the ones abusing these types of vulnerabilities. And there's really no legislation or strong social efforts to curb them from doing so.

    SQL Injection

    • Typical example:
    $user = $_GET['user'];
$sql = "SELECT id, name FROM table WHERE username = '$user';";
    • User hits example.com/page?user="'; DROP TABLE USERS; -- '" (appropriately url encoded).
    • Or if the user passes ' OR 1=1; --, they can try to get passed an auth check.
    • Side note: There's actually a company registered under the name ; DROP TABLE companies.

    The problem of course, is shoving user input directly into code.

    • This is an input validation vulnerability.
    • Prevention: prepared statements! These bind variables that can only be data not code.

    Note: if you find a vulnerability, contact your local CERT to safely and anonymously report it.

    Question: why not do "prepared statements" for HTML to avoid XSS?

    • Both of these situations are similar to buffer overflows, executing user supplied code unexpectedly.
    • But, HTML is just text.. and it's expected to have javascript dynamically inserted and fucking shit up. So HTML (as we know it) can't really do this.

    CSRF: Cross Site Request Forgery

    Recall the features of the browser sandbox review:

    • Active content can send requests anywhere, but it can't read response.

    Consider:

    • User logs into bank.com, forgets to sign off.
      • Session cookie remains in browser
    • User then visits malicious site containing <form action=http://bank.com/BillPay.php> and JS to submit it.
      • This is OK, you can make requests to anywhere you want.
      • But the browser is going to send the cookie too! So the payment request will be fulfilled.
    • Lesson: cookie authentication is not sufficient when side effects can happen.

    Impact:

    • Hijack any ongoing session (steal accounts, make purchases, etc.)
    • Reprogram the user's home router
      • Very popular technique. Routers for many years just let people on the network modify whatever they wanted; so attackers could arbitrarily open ports on the victim's network, etc.

    XSRF True Story:

    • Advertise a malicious cybervillians.com site on a stock trading forum .
    • Assume that many of these users have cookies for ticker.stockbroker.com.
    • Embed an iframe that hits stockbroker.com and
      • turns off user's email notifications
      • links a new checking account
      • transfers out $5k
      • unlinks the account
      • restores email notifications
    • Profit.

    Defenses:

    • Secret validation token: <input type=hidden value=23a3af01b>
      • Embedded in forms
      • Token often based on user's session ID
      • Server verifies correctness of token before operation
      • Notice this relies on SOP: iframe can load the form but malicious external site can't read it!
    • Referer validation: ensure referer header value matches the expected origin
      • What if referer is empty? Shrug
      • Lenient referer checking: optional
      • Strict referer checking: required
      • Tons of practical reasons to suppress the header:
        • Organizations may strip outgoing requests so as to not leak private internal sites
        • Browster strips this when going from https -> http.

    Authentication

    Many ways to prove who you are

    • Something you know: e.g. password, answers to security questions
    • Something you have: e.g. tokens, mobile devices
    • Something you are: e.g. biometrics

    What is authentication trying to do, fundamentally? Well, it depends:

    • You might pass around a Netflix login. You are considering the auth here as a token that others can use.
    • Netflix might instead try to tie auth to a particular human for business purposes.

    We don't have great answers in authentication.

    Passwords

    Passwords suck.

    • They get leaked, they get reused, they're hard to remember.
    • They are the first thing that attackers try to get after intrusion, via key loggers.
    • Even if you hash shit like crazy in the most modern, cryptographically secure way, a poorly chosen password by user is easily cracked.
    • Other risks:
      • key loggers
      • shoulder surfing
      • same password at multiple sites
        • this is how almost all compromises happen
      • social engineering

    How to make them suck less?

    • Salt passwords. This prevents a large offline precomputation of common hashes to match against.
    • Also pepper: secret salt

    Shitty default passwords:

    • US District Courthouse server: "public" / "public"
    • NY Times employee database: pwd = last 4 SSN
    • Mirai IoT botnet:
      • tried weak/default passwords on tons of routers and other devices
      • built to take down competitor's minecraft server