Monday, July 10, 2017

2017-07-05 incident report

Chronology


On Tuesday, July 04, we received a vulnerability report from Jens A Mueller (@jensvoid)

It appeared that our web server’s Cross-Origin Resource Sharing (CORS) settings were misconfigured and it potentially allowed a third party to take over user accounts and perform a man-in-the-middle (MITM) attack. We fixed the reported vulnerability in less than 24 hours.

On Wednesday, July 05, one of our users reported on a public forum that his bitcoin address had been altered.


Initially we didn’t attach much importance to it, but the following day we received a few similar reports and it became evident that something bad was happening.

On Thursday, July 06, we suspended our bitcoin withdrawals and asked our users via site, twitter, forum and email to double check their withdrawal addresses and contact us in case if they had been altered.


We received even more reports after that. 

We’ve spent lots of time trying to identify a problem and  discovered that:
- some of our backup routines didn't work properly;
- we had lots of logs, but they were mostly useless and hard to analyze;
- we had a few security-related bugs that were unrelated to the problem.

Eventually we came to a conclusion that the problem was most likely caused by the CORS issue mentioned in the beginning of this post.

Scope

The vulnerability enabled attacker (let's call him or her Alice) to access at least dozens of accounts of our users who visited her site while being signed in at A-ADS.

Alice was probably able to collect user names / emails of those users and alter any editable data of their accounts (e. g. withdrawal settings, emails and passwords). We don't know when she discovered this vulnerability and for how long she was exploiting it.

When Alice noticed that we had fixed the CORS issue, she hurried up to profit from her possessed abilities and altered withdrawal addresses of the controlled accounts before their sessions expired.

She was smart enough to use unique IPs and bitcoin addresses, so we couldn't identify neither her, nor the exact amount of the hacked accounts.

Aftermath

On Monday, July 07, we resumed the bitcoin withdrawals. We did it with mixed feelings because we still have more questions than answers.


According to our estimations Alice was able to withdraw only a fraction of bitcoin and we'll be able to cover it from our funds.

She may still control some of the accounts (in case if she managed to change their passwords) and profit from them. So if you haven't signed in for a while, please check your account and contact support in case of a problem.


We apologize to our users for this incident and thank them for their patience. We hope that the affected users will not stop bombing our support with their messages until their issues get fully resolved. Unfortunately it may take a lot of time and we apologize for that too. 

We also Jens A Mueller for his precious help.

We feel that we got a valuable lesson, and we are still to do our homework, but we would like to ask Alice and other hackers to refrain from attacking us in the future.

If you find any serious vulnerability, please send us a bug report with proof of concept as @jensvoid did and we will pay you a bounty depending on the potential damage. It would be ethically correct and would save lots of time for both you and us.

Thursday, June 15, 2017

Introducing CPM bids - a new way to buy traffic at A-Ads

Unlike other advertising networks we neither use JavaScript nor cookies in our banners which means that our means of fending fake traffic off are limited. This is why we were reluctant to implement CPM and only offered a less traditional payment model where advertisers spend the money at the chosen pace and get a share of impressions, regardless of their quality and quantity.

However due to a popular request we've decided to offer a CPM-based advertising as well.

Along with our normal mode of operation we are now introducing CPM bids in order to give you a flexibility in managing your budget and controlling your expenses.

You can choose either "Daily budget" or the "CPM" model in the simplified campaign creation interface.


You are free to use both models at the same time -- see the "Budget" tab in your campaign's settings.

CPM bids allow you to pay exactly what you want for the number of impressions that you want. Bids are paid upfront from the advertising campaign budget (it may take a few minutes before the bid changes its state to "Funded").



Please note that we do not guarantee the quality of the traffic that you receive -- we only ensure that you get the wanted number of impressions generated by unique IP addresses in the scope of your advertising campaign.

Mind that if the price of the traffic is higher than your bid then you may never receive your impressions. You can cancel your bid any time and the remaining funds will be returned to your campaign (it may take a few minutes).

Monday, May 1, 2017

Withdrawal thresholds increase

Withdrawal thresholds increase

As a response to Bitcoin congestion problems, we have increased the minimum withdrawal threshold to 0.001 btc and the default withdrawal threshold to 0.002 btc.

These limits apply only to Bitcoin transactions. If you want to withdraw less than 0.001 btc, you can enable FaucetSystem in your withdrawal settings.

Friday, April 14, 2017

Micro-withdrawals via FaucetSystem

Since the beginning of 2017 we've being searching for ways to keep the withdrawal thresholds low despite the rise of bitcoin fees.

Recently we found a temporary solution to this problem: your satoshis can be withdrawn to FaucetSystem - a user-agnostic service that accumulates off-chain micro-transactions before sending them to your bitcoin address.

You can enable FaucetSystem in your user (or ad unit) settings. This option hides 'Withdrawal threshold' as irrelevant because FaucetSystem allows 1-satoshi transactions.

Disclaimer:

We believe that FaucetSystem is a legit service, but we can't guarantee the safety of the funds sent to them. Please use at your own risk!

Wednesday, January 25, 2017

Bitcoin network congestion problems & withdrawal threshold increase

Bitcoin network congestion

It is well known that due to the temporary anti-DoS limit introduced by Satoshi Nakamoto in 2010, the current Bitcoin throughput is constrained to about 3 transactions per second.

With every difficulty increase it temporarily drops and then starts growing with miners' hashing power until the next difficulty adjustment.

That is why on the 21st of January after the expected 16.64% difficulty increase many Bitcoin users faced higher bitcoin fees and longer transaction confirmation times. Dozens of thousands of unconfirmed transactions still reside in the mempool.


It will probably take a few days for most of them to get confirmed. But the situation is going to become worse with every difficulty adjustment unless Bitcoin adoption stops or its throughput is increased.

Bitcoin scalability controversy


Bitcoin community has been discussing the scalability problem for years and despite the fact that it came up with a few potential solutions, it has been failing to find the one that would satisfy everybody.

According to Nodecounter, about 17% of mining power is in favour of increasing the block size limit via a hard fork proposed by Bitcoin Unlimited team, whereas 24% support Segwit proposed by Bitcoin Core developers. For some reason the compromise that would include the benefits of both solutions has not yet been achieved.

This leaves us in the reality where a constrained Bitcoin throughput diminishes our ability to handle micro-transactions and forces us to keep users' money longer than we would prefer to.

Low value transactions

The problem with micro-transactions is that they take the same amount of block space as high value transactions, but it doesn't make economic sense to add high fees to them.

Hence they have a relatively low fee and in the current state of Bitcoin there is no guarantee that the low fee transaction will ever be confirmed.

E. g. the recommended fee currently is 120 satoshi per byte and the average transaction size is 226 bytes, thus if you want to quickly move 10000 satoshi, you have to pay a fee of 27120 satoshi.

In order to save the block space we use hourly sendmany transactions to pay our users. It allows us to send money to multiple recipients in a single transaction. E. g. if there are 64 recipients, then the transaction is only ~2309 bytes, or about 4329 satoshi per recipient (that is still prodigal for 10000 satoshi withdrawals).

That's why use use a small fee of 20 satoshi per byte (or 721 satoshi per recipient). It worked just fine until recently.

"Insufficient funds" incident

Yesterday we noticed that our bitcoin node couldn't create new transactions and returned the "Insufficient funds" errors despite the fact that the listaccounts command returned sufficient balance on our account (unlike getbalance and getinfo calls that returned a negligible balance).

We investigated the cause of this inconsistent behaviour and figured out that all of our hourly outgoing transactions got stuck after the latest difficulty increase thus forming a long chain of unconfirmed transactions. Our bitcoin node refused to continue this chain and decided to wait for confirmation of the change.

Thanks to ViaBTC pool for its transaction accelerator that enabled us to push through the stuck transactions and thus temporarily solve the problem.

Really, thank you!

Withdrawal thresholds increase

Recently we increased the default withdrawal threshold to 0.0001 btc , but many users still had lower values in their settings.

Since they might be unaware of how expensive it could be for them to spend the received micro-amounts, we decided to increase their withdrawal thresholds to 0.00100001 btc (while allowing them to set it back to 0.0001 btc if they want to).
 
We still need to develop a long-term solution and may be forced to increase the minimal withdrawal threshold, the interval between transactions, or to add a withdrawal fee in the future.

Wednesday, January 18, 2017

A 10x increase of the default withdrawal threshold

Dear A-ads users,

For security reasons we don't want to keep your money for a long time. That's why once your earnings hit the configurable withdrawal threshold, we send them to your bitcoin address automatically (on a daily basis).

The default withdrawal threshold used to be BTC 0.0001 (10 thousand satoshi) but due to increased bitcoin transaction fees caused by the limited blockchain capacity we decided to increase it to BTC 0.001 (100 thousand satoshi).

You still have the ability to set the minimum withdrawal threshold to BTC 0.0001 however you must keep in mind that if you want to receive many tiny transactions it might be very expensive for you to spend them later. E. g. if your spending transaction has hundreds of inputs, it may require a fee of about $30 worth of bitcoins.

Despite our desire to withdraw funds as soon as possible if bitcoin fees continue to rise we may be obliged to adjust our withdrawal policy.

Monday, October 10, 2016

A change in our policy: the number of ad units per page limit or how many ad units are allowed

After a careful consideration we are announcing a slight alteration of our policy which we believe will affect only a fraction of our publishers.

Starting from October 2016 we now only guarantee that only up to three ad units per page will be served to the visitors of your website and here's why.

Unlike other advertising networks, A-Ads doesn't pay merely for impressions or for clicks: we consider globally unique impressions within our entire network. It becomes obvious then that having more than several ad units per page doesn't make a lot of sense from the financial point of view: additional ad units might not necessarily bring your additional earnings.

Secondly, we've had a number of publishers who placed literally dozens of dozens of ad units per page in a hope that extra ad units would proportionally increase their earnings and of course that hadn't helped their cause. Consequently our servers bore a very substantial computational burden and it jeopardized our operations.