FaucetBOX.com Discussion

[minifrij]

It doesn't look at all like a SQL Injection vulnerability, I really don't think that's what causing it. Why do you thinks it's a SQL Injection? I'd say it's rather some subtle error in code that calculates the reward or handles the timer or both. Either way it's probably not trivial and would require a lot of time and effort to fully analyze. You can't expect that I'll fix every random script out there, that's just impossible. I have FaucetBOX.com, Faucet in a Box script and ScanTheBOX.com to maintain, that's engaging enough.

If you don't mind me asking, what makes it not look like a SQL Injection vulnerability? From what I can see in the code, there is nothing to escape any of the strings before running them.

For example, on core.php at line 169 (In the default script from gitlabs, looking at another faucet owner's script from this vulnerability it seems to be line 300), this function is used to run any SQL querys throughout the script:

Code:

function sql_query($sql)
{
    global $mysqli;
    return $mysqli->query($sql);
}

It literally gets the connection from config.php and runs the query. If this is as simple as it looks and there are no escape strings, this is a huge error in the script.

Perhaps using something similar to this:

Code:

function sql_query($sql)
{
    global $mysqli;
    $sql = $mysqli->real_escape_string($sql);
    return $mysqli->query($sql);
}

Will solve the problem, as it escapes the string before continuing with the query.

Hearing thefaucetrunner talk about SQL injection made me think about this again and had me search through all of the files to try and find this function. Apologies for not finding it earlier.

[elbandi]

Perhaps using something similar to this:

Code:

function sql_query($sql)
{
    global $mysqli;
    $sql = $mysqli->real_escape_string($sql);
    return $mysqli->query($sql);
}

Will solve the problem, as it escapes the string before continuing with the query.

It's half true: real_escape_string is not a silver bullet to protect against sql inject. google://sql+injection+with+mysql+real+escape+string.
If you always belive in realescapestring, you have in false safety.

My goal is to check/verify the input before the sql code, and do not execute sql if it is not good (eg verifyaddress).
I have only two eyes, so if you find place where i dont check something, feel free to msg me

The hacked faucets used a modified versions from minifaucet, so we dont know the bug/sqlinject/whatever is in the original code or in the modified code. So we are just groping in the dark

Did someone checked that modified code? At all, do someone have the modified code?

Elbandi

[minifrij]

It's half true: real_escape_string is not a silver bullet to protect against sql inject. google://sql+injection+with+mysql+real+escape+string.
If you always belive in realescapestring, you have in false safety.

The best way to go about it would probably be to use prepared statements, though that would take more complicated code to execute properly.

[Kazuldur]

It doesn't look at all like a SQL Injection vulnerability, I really don't think that's what causing it. Why do you thinks it's a SQL Injection? I'd say it's rather some subtle error in code that calculates the reward or handles the timer or both. Either way it's probably not trivial and would require a lot of time and effort to fully analyze. You can't expect that I'll fix every random script out there, that's just impossible. I have FaucetBOX.com, Faucet in a Box script and ScanTheBOX.com to maintain, that's engaging enough.

If you don't mind me asking, what makes it not look like a SQL Injection vulnerability? From what I can see in the code, there is nothing to escape any of the strings before running them.

This hack usually results in many small-to-moderate payouts to many addresses in time smaller than the timer. I guess it could be a result of SQL Injection, but why bother with something like that then? SQL Injection probably allows to just steal the API key from the database and I think that would be much easier.

[NeedIfFindIt]

The best way is to log all the 4 points:
- GET requests (if you have access log you already have them).
- POST requests and their parameters.
- All the claims.
- All the cashouts.

There is no way for him to escape.

Ofc. changing the API key before you restart paying is a must.

This is all I can help without a look at the code.

Edit: I think this could be a bot. Yesterday someone posted a link to my website in a forum discussing "a bot not working anymore" (probably because some faucets got dry).

Putting some randomness in the faucet functionality may complicate their lives.

[Dobrii]

A feeling as if from my faucet steal bitcoin. And every day.  It's very suspicious! I just can not explain it to you.

[carlitosandres2507]

After how long possibly broken disappears after satoshis enter your account?

[Kazuldur]

After how long possibly broken disappears after satoshis enter your account?

6-8 hours after first successful payout.

[paliboy]

Hi, I noticed that clicking on banner ads inside ScanTheBox.com doesn't open the ad. Do you know how to fix or work around that 

[paliboy]

Hi, I noticed that clicking on banner ads inside ScanTheBox.com doesn't open the ad. Do you know how to fix or work around that 

I found the reason... it's because the iframe is sandboxed and therefore link cannot open new tabs/windows. To fix it, ScanTheBox needs to be changed from

Code:

<iframe sandbox="allow-same-origin allow-scripts allow-forms" src="" id="iframe"></iframe>

to

Code:

<iframe sandbox="allow-same-origin allow-scripts allow-forms allow-popups" src="" id="iframe"></iframe>

[Kazuldur]

Hi, I noticed that clicking on banner ads inside ScanTheBox.com doesn't open the ad. Do you know how to fix or work around that 

I found the reason... it's because the iframe is sandboxed and therefore link cannot open new tabs/windows. To fix it, ScanTheBox needs to be changed from

Code:

<iframe sandbox="allow-same-origin allow-scripts allow-forms" src="" id="iframe"></iframe>

to

Code:

<iframe sandbox="allow-same-origin allow-scripts allow-forms allow-popups" src="" id="iframe"></iframe>

That's a known issue and we did block the popups and redirection deliberately. It prevents faucets from opening annoying popups and redirecting out from the rotator. We even give a warning to faucet users about that when they're adding their faucets to the rotator.

What we plan to do is adding a button for user like "Open this faucet in new window". Such window wouldn't be sandboxed then.

[Dobrii]

Why is my faucet Satoshi disappear even when I'm not crying?

[ranlo]

It doesn't look at all like a SQL Injection vulnerability, I really don't think that's what causing it. Why do you thinks it's a SQL Injection? I'd say it's rather some subtle error in code that calculates the reward or handles the timer or both. Either way it's probably not trivial and would require a lot of time and effort to fully analyze. You can't expect that I'll fix every random script out there, that's just impossible. I have FaucetBOX.com, Faucet in a Box script and ScanTheBOX.com to maintain, that's engaging enough.

If you don't mind me asking, what makes it not look like a SQL Injection vulnerability? From what I can see in the code, there is nothing to escape any of the strings before running them.

For example, on core.php at line 169 (In the default script from gitlabs, looking at another faucet owner's script from this vulnerability it seems to be line 300), this function is used to run any SQL querys throughout the script:

Code:

function sql_query($sql)
{
    global $mysqli;
    return $mysqli->query($sql);
}

It literally gets the connection from config.php and runs the query. If this is as simple as it looks and there are no escape strings, this is a huge error in the script.

Perhaps using something similar to this:

Code:

function sql_query($sql)
{
    global $mysqli;
    $sql = $mysqli->real_escape_string($sql);
    return $mysqli->query($sql);
}

Will solve the problem, as it escapes the string before continuing with the query.

Hearing thefaucetrunner talk about SQL injection made me think about this again and had me search through all of the files to try and find this function. Apologies for not finding it earlier.

Even with your code changes (such as escaping strings), there are many vulnerabilities still open. I'm actually somewhat surprised something as important as dealing with people's finances (in the sense that the script has access to the wallet's funds) is even using SQLi, much less in a very unsecure method. real_escape_string only prevents a small portion of injections from being possible, and if you really want to use that route, you should fix all of them.

[minifrij]

Even with your code changes (such as escaping strings), there are many vulnerabilities still open. I'm actually somewhat surprised something as important as dealing with people's finances (in the sense that the script has access to the wallet's funds) is even using SQLi, much less in a very unsecure method. real_escape_string only prevents a small portion of injections from being possible, and if you really want to use that route, you should fix all of them.

As I said, the best way to do it without completely changing the DB software would be to use prepared statements, though that would still leave the script open to some forms of injection. What would you suggest to fix it?

[Kazuldur]

We are experiencing issues with transaction confirmations due to the recent change in Bitcoin network fees. We're working on it, but transactions can take a long time to confirm for now.

[ragi]

We are experiencing issues with transaction confirmations due to the recent change in Bitcoin network fees. We're working on it, but transactions can take a long time to confirm for now.

This sucks. I want this test/attack to be over with.

[ptrio]

Either way, it seems pretty easy to implement. Just checking against the referrer and returning to the homepage if it was found to be elsewhere should be sufficient.
Something like this maybe:

Code:

if($_SERVER['HTTP_REFERER'] != 'http://yoursitewhatever.com'){
header('Location: /');
}

Once the form has submitted (~line 1138 on index.php).

I'm not that good with PHP, but I think that

Code:

header('Location: /');

won't end the script. So it will send the coins either way and only redirect to main page after that.

Code:

header('Location: /'); die();

should work though.

As soon as that header hits, the page forwards, so there's no need for closing out the PHP connection -- it's done by default. Even if you have other code after that, it will stop parsing at that line.

I myself wouldn't trust referer headers as they could be fabricated.

Even with your code changes (such as escaping strings), there are many vulnerabilities still open. I'm actually somewhat surprised something as important as dealing with people's finances (in the sense that the script has access to the wallet's funds) is even using SQLi, much less in a very unsecure method. real_escape_string only prevents a small portion of injections from being possible, and if you really want to use that route, you should fix all of them.

As I said, the best way to do it without completely changing the DB software would be to use prepared statements, though that would still leave the script open to some forms of injection. What would you suggest to fix it?

I think PDO would do just fine. That plus validating the input (which in this case is only a wallet address) with base58 encoding/decoding (if anyones interested I can provide a simple script).

Anyway, you're doing a great job guys! Keep it up.

[Kazuldur]

We are experiencing issues with transaction confirmations due to the recent change in Bitcoin network fees. We're working on it, but transactions can take a long time to confirm for now.

This sucks. I want this test/attack to be over with.

It's more because of the new floating fees than the stress test, which I think is long gone now.

EDIT: I know see that it's happening again: https://www.reddit.com/r/Bitcoin/comments/3ck5z9/80000_unconfirmed_transactions_right_now/ . Also here: https://bitcoinfees.github.io/#3h . Does anyone knows anything more about it?

I myself wouldn't trust referer headers as they could be fabricated.

While I didn't trust them too for FaucetBOX.com, how could they be fabricated in context of CSRF? If I were to attack you using CSRF I wouldn't be able to force your browser to fake the referrer.

[ptrio]

I myself wouldn't trust referer headers as they could be fabricated.

While I didn't trust them too for FaucetBOX.com, how could they be fabricated in context of CSRF? If I were to attack you using CSRF I wouldn't be able to force your browser to fake the referrer.

You are right. Referer check seems to be good enough to protect against CSRF. However there's ways to get in control of someone's browser and then spoof the headers(is XSS + CSRF possible?). Also what about HTTPS or if someone's browser doesn't send the referer headers (guess 99% do but still)? That would be considered as an attack.

BTW Do you guys support p2sh for litecoin yet?

[Kazuldur]

I myself wouldn't trust referer headers as they could be fabricated.

While I didn't trust them too for FaucetBOX.com, how could they be fabricated in context of CSRF? If I were to attack you using CSRF I wouldn't be able to force your browser to fake the referrer.

You are right. Referer check seems to be good enough to protect against CSRF. However there's ways to get in control of someone's browser and then spoof the headers(is XSS + CSRF possible?). Also what about HTTPS or if someone's browser doesn't send the referer headers (guess 99% do but still)? That would be considered as an attack.

BTW Do you guys support p2sh for litecoin yet?

If you control someone's browser, why bother with CSRF? You can just attack directly . HTTPS isn't a problem, referrer will be correct on the site itself and possibly not set/empty when coming from other sites (then one just assumes it's invalid). If someone's browser doesn't send headers, too bad. It's not perfect solution, it's just easiest. You should generate a token, save it in session, add it as hidden input in form and compare it on request. But that require more changes, while referrer check will be sufficient for most.

Still no P2SH for Litecoin yet. No ETA either.