(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Although a lot has been written about SQL injection vulnerabilities, they can still be found relatively often. In most of the cases Ive seen in last couple of years, I had to deal with blind SQL injection vulnerabilities. Typically, they can be exploited relatively easy, by carefully modifying the resulting SQL queries and deducing the answer either by monitoring the resulting web page or, for example, by measuring the time it took for the answer to arrive.

Long time ago (phew, its been almost 7 years!) I wrote a diary where I gave an example of exploiting a blind SQL injection vulnerability that needed a specific value in a parameter (see https://isc.sans.edu/diary/Advanced+blind+SQL+injection+%28with+Oracle+examples%29/6409). In this particular case, the SQL querys result had to be either true or false (literally) ">queueID">queueID).

What">743994 OR 1=1 and off you go. Well, it wasnt that easy ">UNION didnt work either the application expected exactly certain values in the columns (not only column types) and all I could get with both of these cases was a nice, generic error screen (hey, no insufficient error handling either!).

The idea here was to prove that this is exploitable and although it looks a bit more complex, it is certainly exploitable here">queueID = 743994 AND 1=1
queueID = 743994 AND 1=2
queueID = 743995
queueID = 743994

The first 3 queries all return a no results page. The last one returns the generic error page due to the SQL error that happened in the background. A tough cookie.

As with any blind SQL injection vulnerability, we need a true/false cases. And if you take a look we actually have them: the true case can be the no results page, while the false case can be the error page. The only question that remains is how to provoke the error page its easy to do manually by entering a ">queueID = 743994 AND1 = 1 / (select case when substr(banner, 1, 1) = A then 1 else 0 end from (select banner from v$version where banner like %Oracle%">substr() call) and compared to the letter A. If it is A, the query returns 1, otherwise it returns 0.">1 = 1 / 0. The former will display the no results page while the latter will display the error page. Game over!
In this particular case the goal was to show what an attacker can do with the vulnerability. While it was relatively easy to confirm its existence, by showing that arbitrary data can be retrieved from the database, the resulting risk indeed gets pretty high.

Have more ideas on how to exploit this? Let us know!


(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(credit: NoHoDamon)

Hackers have siphoned about $103,000 out of Bitcoin accounts that were protected with an alternative security measure, according to research that tracked six years' worth of transactions. Account-holders used easy-to-remember passwords to protect their accounts instead of the long cryptographic keys normally required.

The heists were carried out against almost 900 accounts where the owners used passwords to generate the private encryption keys required to withdraw funds. In many cases, the vulnerable accounts were drained within minutes or seconds of going live. The electronic wallets were popularly known as "brain wallets" because, the thinking went, Bitcoin funds were stored in users' minds through memorization of a password rather than a 64-character private key that had to be written on paper or stored digitally. For years, brain wallets were promoted as a safer and more user-friendly way to secure Bitcoins and other digital currencies, although Gregory Maxwell, Gavin Andresen, and many other Bitcoin experts had long warned that they were a bad idea.

The security concerns were finally proven once and for all last August when Ryan Castellucci, a researcher with security firm White Ops, presented research at the Defcon hacker convention that showed how easy it was to attack brain wallets at scale. Brain wallets used no cryptographic salt and passed plaintext passwords through a single hash iteration (in this case, the SHA256 function), a shortcoming that made it possible for attackers to crack large numbers of brain wallet passwords at once. Worse, a form of the insecurely hashed passwords are stored in the Bitcoin blockchain, providing all the material needed to compromise the accounts.

Read 9 remaining paragraphs | Comments


Attackers have problems too: Attacks against Internet of Things (IoT) devices are simple (as in log in...), but the attacker never knows what kind of architecture they may hit. IoT devices often go beyond the standard x86 architecture we are used to on our servers and workstations. What I typically see is the attempt to launch multiple binaries, compiled for different architectures, to see what runs.

For example, this was the #1 # clean out /tmp... ouch. /var ? that can break stuff. cat arm cat mips cat mipsel ./busybox

so essentially, the standard busybox binary is replaces with one of the other binaries. In this case, an ARM, MIPS and MIPS Little Ending version is retrieved.

The sad part about this: These attackers appear to go through some length to compile these scripts for various platforms, but the dont appear to do much at all, or are just broken. This is probably another indication of how simple it is to go after the IoTs.

FWIW: If you use a Raspberry Pi, make sure to change the default password!!!! I am seeing a LOT of attempts to use the default credentials.

Johannes B. Ullrich, Ph.D.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
BFS-SA-2016-001: FireEye Detection Evasion and Whitelisting of Arbitrary Malware
Internet Storm Center Infocon Status