Tuesday, 20 September 2016

[Idea] False Biased Extraction for SQLi using Prime numbers

I'm getting into this new style of blogging where I blog my unadulterated raw thoughts. Open to the ridicule of the entire world. Its liberating :) Its also very interesting to see how I make mistakes and what I learn from them, instead of just the monotonous, lifeless style of blogging what you got right or won at. So anyway here's todays thought...

A couple years ago, some dude from Immunity talked about how in "True"Blind SQLi it might be effective to favor responses that produce no-wait responses (here's the link: http://infiltratecon.com/miguelturner.html ). That is to say, if you are exploiting a Blind SQL injection vulnerability in which only time based responses are observable, it makes sense that responses that don't trigger sleeps or waits would get you information faster. Brilliant observation! This is quite clever because it allows you to throw the traditional computer science idea of efficiency out of the window (or rather the conventional idea computer scientists have grown into) and focus purely on extraction time. When musing on these ideas I tend to get trapped in thinking of computational cost in terms of strict computer science i.e. operations, network requests, cpu cycles etc. But here we are focusing on whats important, getting information fast.

Digression: The labels for efficiency you are "indoctrinated" into with computer science are merely the natural way people found computer science to be useful. We needed to make algorithms more efficient according to instructions because it allows us vertically (more bits per op instead of more information per bits) scale our computational power without scaling our solutions. But you should think of "instructions" and "memory" as a label you can generalize.  Why not try to find an efficient algorithm for picking up chicks as measured by the efficiency of how many drinks you need to buy hehe I literally just found an example of this line of thought... 

WARNING: This video is probably not totally safe for work!

So anyway the question we then need to answer becomes:

How can you construct a line of questioning (series of questions) that will almost always return no-wait responses, and terminate with enough information to accurately infer the number you are extracting?

My guess is using Prime numbers! So literally probing the database to indicate whether a number has a certain prime numbers as a factor. Why is this cool?

  • Prime number factors are unique; each number has a unique equation involving only prime numbers that multiply to it i.e. unique prime factorization
  • Distribution of prime numbers can be used to favor no-wait responses (we can order our line of inquiry in a such a way that we prioritize the prime numbers in terms of information extraction goodness and miss rate)
  • Many probes can be deployed in parallel
  • We can probe for multiple prime numbers at once i.e. password[0]%prime[0] ^ password[0]%prime[1] ^ ... if this number is 0 then we just extracted tons of information about the target letter.
  • Could be applied to extending,  or made useful in other paradigms of extraction i.e. hash based extraction where the alphabet is very small can be morphed to using the hash table to extract configurations of the prime numbers instead of literally values like lets say 2,5,7,11 could indicate bit positions and an extraction of 1,0,1,0 would mean 2 is a factor, 5 is not a factor, 7 is a factor and 11 is not a factor. You would probably not need such a big alphabet/hash table to effect an entire byte extraction. 
All that is left to get this idea off the ground is to construct an ordering that is chosen optimally. For that I could employ the shortest path algorithm, and assign the "goodness" and then search for the optimal ordering. But before that I need to find a costing function for the ordering! Will blog about that in the next one prob.

Monday, 19 September 2016

Abusing WebVTT and CORS for fun and profit

WebVTT is a way html5 developers can display and cue text as subtitles for video formats. The grammar for WebVTT is pretty simple and as we know browsers are always willing to forgive any "weird" looking grammar in an effort to provide best effort experience for users. This post looks at ways to take advantage of WebVTT in some attack contexts in order to extract information or perform general DOM abuse.


Video tags can make use of subtitle files, as follows:

WebVTT (subtitle) files need to follow this format:

The file merely describes cues, allows you to number them and associate a duration and display time for them. Display timestamps specify hours (hh), minutes (mm) , seconds (s) and milliseconds (ttt). According to my basically inspection of the grammar, most browser require you to respect the placeholders (significant figures) if you specify the magnitude. For instance, if you want to indicate hours you need to use both place holders, same goes for others. You must specify the "-->" to indicate the end timestamp.

Grammar Quirks

The grammar is not extremely strict, you can get away with alot. Here's a quick summary of some of the things I've noticed for Safari, Chrome and Firefox:

  • The file must start with "WEBVTT"
  • It doesn't matter what comes after the first few bytes (described above)
  • Numbering cues is optional, the browser usually just fills an array with these the cues.
  • Just about anything after the timestamp is considered part of the cue until another one is specified.
  • It doesn't matter what the content type of the subtitle file is 

Extraction Attacks

So now that we know what we can and can't do with the grammar lets see how we can abuse this. Here's the attack contet:

  1. A server hosts some authenticated content only a logged in user can access, with the metioned users access rights. 
  2. An attacker wants to extract this, but needs to do this under the mentioned user's access rights.
  3. The user is free to visit any arbitrary page and the attacker is on a remote network.
  4. The host web server has a cross origin headers like this: "Access-Control-Allow-Origin: *"
  5. The web server hosts a page that suffers from an injection vulnerability allowing the attacker to specify the first few bytes of the page

This is for all intents and purposes the same attack context as a CSRF vulenrability, and abuses the same mechanism in the browser that a CSRF attack does. Point number 4 is the kicker, should any JavaScript, JSON, or any arbitrary content harbor secrets in such a away that the attacker can inject into the first few bytes, there is a way to extract these secrets using WebVTT.

Straight Extraction Attack

Here's the basic attack idea, the attacker hosts the injectable page in such a way that it is interpreted as a WebVTT page, here's a demo
The trigger (as seen above) looks like this:


If this is inserted into the first few bytes of the page it will force it to be rendered as follows:

Which then forces the browser to interpret it as a valid WebVTT file, and the HTML content would be the subtitle text. Here's where the magic comes in; most browser have a javascript API for accessing the actual text in the cues, here's a quick demo of extracting the first cue's text:

And here's a screen shot of me using this trick to demonstrate that it could work against HTTP headers (random arbitrary content) should I be able to inject the WEBVTT preamble as discussed above (the screenshot shows Safari and Firefox):

Further Reading and References

Monday, 15 February 2016

Stealing Secrets with CSS : Cross Origin CSS Attacks

In this post I'm going to discuss a web attack that was designated CVE-2015-5826 and CVE-2015-1287 which abuses the way CSS parsing works in some browsers and expands the way we think about HTML injection attacks.

Wednesday, 15 July 2015

The Vaudenay Attack : A practical example

Hi guys in the previous post I discussed the theoretical basis for the vaudenay (or padding oracle attack) , in this one I'm going to share a little script that will help you play around with padding oracles and also manually perform the attack. But first a quick recap!

Sunday, 12 July 2015

Padding Oracle Attacks : The other padding that killed your secret key

The Oracle of Delphi
Hi folks! In this post I'd like to talk about something that's pretty old but still crops up every now and then (example). I know for most folks this is nothing new but I'd still like to have a post about this attack in my archive and also deliver a good explanation of the attack in a way that makes it easier for more people to understand (I know for new comers this attack can be a bit of a mind bending exercise :P). Also if you want to be a total infosec / crypto hipster you can refuse to call it padding oracle attacks and call it by its eponym "the Vaudenay attack" and pay homage to the inventor Serge Vaudenay :)

Update: The next post is a more practical explanation of this attack :)

Sunday, 23 November 2014

Automated DEX Decompilation using Androguard part II: Dex2Java

So I Googled Java Construction...
The next post in the Androguard tutorial series (By the way here's part one). Here we are going to see how to construct a novel script that de-compiles an APK into full Java code using Androguard and python.

Working from the previous post about de-compiling a dex file into Dalvik byte code (which is actually little more than purely interpreting the contents of the Dex file -__-) we're actually going to use Androguard here to take the analysis one step further, actually producing readable Java Code! With one or two caveats (like import statements :P).

Wednesday, 5 November 2014

Automated DEX Decompilation using Androguard

Hey guys, its been a while since my last post and my blog is beginning to gather dust. So I though I would drop a couple posts about some new stuff I've been trying and learning. This post is about Androguard and how to write a simple python script that dumps decompiled dalvik bytecode from an Android APK.

Monday, 17 March 2014

About addJavascriptInterface abuse in Android Browsers

So I started out writing this post like most of the other posts I've been writing this year, just another rash vulnerability disclosure; but I decided to turn it into more of a discussion about the addJavascriptInterface vulnerability.

I base my discussions here on some vulnerabilities I've found in various Android Browser apps. I'm going to specifically talk about some novel methods I used to enumerate Browser applications using JavaScript bridges insecurely. Obviously, in finding out how to detail the existence of the vulnerability you will also learn how to protect your applications from the discussed exploitation methods.

Monday, 24 February 2014

Path Traversal Vulnerability in OI File Manager for Android

# Disclosure Date: 12/02/2014
# Author: Keith Makan
# Vendor or Software Link: org.openintents.filemanager 
# Version: 2.0.5
# Tested on: Android 3.2.1 (HTC Flyer)
# Tools : Drozer, Bash

Wednesday, 16 October 2013

About.me Cookie Based XSS

About.me suffered from a Cross Site Scripting flaw I found a few days ago. The interesting thing about this flaw is that it was cookie based. The following post details how I found it and what I did to confirm that it was exploitable, it also discusses some interesting points to consider when you find a XSS triggered by Cookie Values.

Saturday, 12 October 2013

Even Faster Blind SQL injection methods

A method presented at DerbyCon and BlackHat involves extracting not the bits of the character but the bits of a characters position in a look up table which contains a number of character ascii values---more on this later. This post discusses the conceptual advantages and fundamental drawbacks of the bin2pos method and introduces a new variant I've developed which provides better stability and only requires a maximum of 4 requests per character extraction but imposes some configurational requirements to the target web server.

Wednesday, 9 October 2013

Grepping for Glory : using grep to uncover Android Application Level Vulns

I've spent some time trawling through masses of Android App Sauce lately and I thought I'd share some quick tips and tricks that can help you uncover some critical vulnerabilities. In this post I'll discuss some basic bash scripting that pin points code being either in Java or Jasmin/Smali form.

A quick disclaimer, 

the screenshots below are from actual apps sourced from the play store, I've used real examples here to motivate the need to look for the mentioned vulnerabilities and detail how easy they are to find. Although I've made sure to santize them for any useable or exploitable information seeing that some of these apps have been downloaded hundreds of the thousands of times.

Wednesday, 28 August 2013

Monday, 26 August 2013

More Details on the Android JCA PRNG Flaw

I've spent a couple days reading the source code for the Pseudo Random number generators in Android mostly because there aren't many breakdowns of the vulnerability around, none that walk through the code explicitly anyway. After some discussion with some people from the Android Security Discussion Google Group I realized that the issue goes a little deeper than  just the super calls and constructor definition as I previously thought.

I was also mislead by grepcode---the site I was using to read the code---since it it wasn't directing me to the Android SecureRandom Implementation but rather OpenJDK!

So I thought I'd correct myself re-post about the issue and study the code directly from the Android repo namely ( https://android.googlesource.com/platform/libcore/+/jb-release/luni/src/main/java/java/security/SecureRandom.java )

Saturday, 17 August 2013

Details on the Android JCA PRNG Flaws

Recently some bitcoin wallets suffered an attack that made use of a critical flaw in the way Java's Cryptography Architecture is implemented in Android. The following post discusses some of the technical details of the flaw by interpreting the code that causes the issue.

UPDATE: A more up to scratch attempt at explaining the vulnerability can be found here http://blog.k3170makan.com/2013/08/more-details-on-android-jca-prng-flaw.html 

Homomorphic Encryption : What it is and what it means for the future of security

There's a new idea brewing in the cryptographers' circles called Homomorphic encryption, and it will soon change the way we do everything from querying databases remotely to adding numbers. In this post I briefly explain what homomorphic encryption is and then list a few ideas others have had on how to use it in cool ways and one or two ideas I've had.

Given that this is a relatively new idea, many of you may be hearing about it for the first time; I'm going to spend a few paragraphs explaining what it is and at the end of this post I'll share a couple of papers and blog posts by awesome people on the subject and its applications.

Monday, 27 May 2013

Wordpress Plugin - ADIF Log Search Widget XSS Vulnerability

# Exploit Title: ADIF Log Search Widget XSS Vulnerability
# Google Dork:
# Date: 26/05/13
# Exploit Author: k3170makan
# Version: 1.0e
# Tested on: Ubuntu 12.04.2 LTS
Wordpress ADIF log book search plugin widget suffers from a Cross Site Scripting vulnerability.