Is it possible to make money on a mobile application for viewing advertising for money?
The article is an analysis of one of the applications in the list . The article was written immediately after the discovery of vulnerabilities in the application. The developer received a report and confirmed the existence of the problem, promising to fix it soon. At the moment, the application has been updated on both platforms.
For several years now AppNana (AppJoy) has been on the wave of popularity, because they make it possible to download paid applications from iOS and Android apps stores for free, without SMS. What is the catch, you ask? Where are the pitfalls hidden? Everything is very simple: you spend your time viewing advertisements, installing left-handed, unsigned applications via direct links, and also share your personal information with half a dozen advertising aggregators for mobile phones, transferring to them all the information that AppNana has access to (including personal email).
It seems everything is clear. Free cheese is only in a mousetrap, there is also a fee and it is not commensurate with the reward. To be precise, the minimum amount for "withdrawal" is 45,000 nanas (local currency, 45,000 nanas = $ 2), start-up capital is 10,400, daily active users receive 400 nanas (if they managed to collect 4,000 nanas in one way or another over the past 24 hours) , one “task” is paid from 20 (most) to 450 nanas (so far there is only one such task), with the largest amount of nanas received by users through referrals (2,500 nanas to the inviter and invited).
Now it becomes clearer. The application itself is not used for meager premiums for downloading antiviruses for free without SMS, but for inviting everyone and everything. It turns out that all users (500,000 - 1,000,000 on the Google Play metric) do nothing but create several accounts and send invitations to themselves in turn? It's not that simple, Max Guan (a Chinese developer living in San Francisco) thought this out beforehand. In order to use the referral code, which will bring 2,500 nanas, you must first earn 15,000 nanas, which in itself is a feat.
')
Okay, let's leave alone the "legal" ways of earning. Let's try the other side. Install Fiddler2 and proxy for Android. We configure proxy for AppNana and we look requests. And they are very interesting. For example, this one:
POST to appnana2.mapiz.com/api/nanaer_login email = someone% 40example.com & password = 1234567890 & source = Android & android_id = abc
SUCCESS will come back and you will be given a cookie with the session ID. It seems everything is just right? But only this script does not limit the number of requests. Brute Force provided. Unfortunately, if you check all email and password combinations, the server will simply fall off. Although it turns out that he can fall off with a five-hundredth error if android_id is a space character ...
Let's try to solve the problem of email selection. For this we need the following query:
GET appnana2.mapiz.com/api/get_nanaer_info/?email=someone%40example.com
A complete list with input_invitation (the number of accepted referrals) b paypal_email (AppNana gets it when withdrawing money to PayPal), redeem_times (how many times the reward was received), login_times (how many times the input was made), bitcoin_address (used for output to BitCoin), offer_nanas (the number of "earned" nanas), register_ip (IP used during registration), devices (contains a list of all devices from which the input was made, along with their mac addresses and ios identifiers), email (address used during registration), lastlogin_ip (last IP), nanas (account balance), sent_invitation (quantity sent referrals invitations), gift_email (additional address for sending a gift code). And a couple more irrelevant fields.
What we have? An API that issues all user data without authorization. How will he help us? It is enough to google AppNana hack and we will immediately get an almost complete list of people who are trying to collect as many nanos as possible through referrals. In blogs you can find posts with one and a half thousand comments, each contains a referral code and ... almost everyone is tied to a Google account, since the blog runs on Blogger. Our task is simplified several times: Parsim issue of Google, we find all references to the referral code (one letter, then 8 digits), next to it we look for links to the Google profile or email for communication. In a couple of hours, such a parser can create a high-quality dictionary for brute force attacks on the above script.
Now we have a base of hundreds or even thousands of users with a balance of their personal accounts. What can we do? Everything. Everything. You will say that this is impossible, but I have not yet revealed all the cards! Next we need two more APIs:
POST to appnana2.mapiz.com/api/invite_verify
POST to appnana2.mapiz.com/api/redeem
First, it activates the referral code and charges 2,500 nanas to the account. The second, brings nanas to Bitcoin or PayPal. Both work without authorization.
First of all, you will create a pair of accounts that have more than 15,000 nanas in the account. Then we take the referral codes associated with the accounts and cash them out for all accounts. When everything is ready, it can be assumed that with 1000 codes and the accounts associated with them, you can get 999,000 valid links. Given that many actively use the codes of others to receive a referral reward, we can assume that 25% of the links have already been used, this leaves us with almost 750 new links to the account. Each connection brings 5,000 nanas to the system. By cashouting all the referral codes available to us (750,000 inquiries), we get 3.75 billion nanos distributed throughout the system.
If you take the most expensive reward (1,200,000 nanos for $ 100 PayPal), then we will generate $ 312,500, or if we prefer anonymity, and are willing to not pay, then we can withdraw all the money in Bitcoins, which will result in $ 267,857 in bitcoins on conversion day. This is without regard to the already available user balances. All we have to do is use the Redeem API to transfer money to our PayPal account or Bitcoin wallet.
Of course, it is unlikely that a startup with a single developer, who is also the head of support (information from a LinkedIn profile), has a PayPal account or a bitcoin wallet with $ 312,500, but if you automate the whole process and don’t cause strong suspicion, you can easily withdraw a round sum .
The most interesting is that this is not a direct violation of the public offer of the service. It contains clause 8a which prohibits the collection and storage of personal information of users, while its analysis is allowed without further storage, you can also ignore personal information, and save only the user name, account balance and referral code. Point 8k prohibits interference with the protection system, including its disabling, in this case there is no protection system as such, that is, using the API without authorization, I do not violate this point. Point 8r is the most extensive. It prohibits the use of automatic software to access the service, bypassing their protection system and / or robots.txt file (they don’t have the other), and modifying and using modified versions of the software for unauthorized access to the AppNana infrastructure. It's still easier, software modification is not needed, while API requests are not closed by the robots.txt file.
I have withdrawn 90,000 nanas from an account with over 1.5 million nanas. Then I sent an email to tech support asking to cancel the transaction and return the funds to the user, or at least return the funds to the user if the transaction has already been completed. The next morning I received a response from Max himself (the owner of the company), that he already knows (!) About the problem and it is solved. It is interesting that this API has been running since at least May 2013. Attached to a million people. Advertising revenue should cover all costs and is enough for one programmer who closes all the holes.
Fortunately, or unfortunately, this is the only application of the 20 installed by me from the top of Google Play, which contained a clear vulnerability. Almost half of the installed applications were built on one “engine”. Requests were like a carbon copy, and, accordingly, they were protected by the session key and required any reauthorization with the slightest interference. A couple of applications could not load ads for display. Another one, apparently, was not going to pay the money, since balance accounting was entered into SharedPrefrences, and requests were sent only to get a list of advertisers.
For several years now AppNana (AppJoy) has been on the wave of popularity, because they make it possible to download paid applications from iOS and Android apps stores for free, without SMS. What is the catch, you ask? Where are the pitfalls hidden? Everything is very simple: you spend your time viewing advertisements, installing left-handed, unsigned applications via direct links, and also share your personal information with half a dozen advertising aggregators for mobile phones, transferring to them all the information that AppNana has access to (including personal email).
It seems everything is clear. Free cheese is only in a mousetrap, there is also a fee and it is not commensurate with the reward. To be precise, the minimum amount for "withdrawal" is 45,000 nanas (local currency, 45,000 nanas = $ 2), start-up capital is 10,400, daily active users receive 400 nanas (if they managed to collect 4,000 nanas in one way or another over the past 24 hours) , one “task” is paid from 20 (most) to 450 nanas (so far there is only one such task), with the largest amount of nanas received by users through referrals (2,500 nanas to the inviter and invited).
Now it becomes clearer. The application itself is not used for meager premiums for downloading antiviruses for free without SMS, but for inviting everyone and everything. It turns out that all users (500,000 - 1,000,000 on the Google Play metric) do nothing but create several accounts and send invitations to themselves in turn? It's not that simple, Max Guan (a Chinese developer living in San Francisco) thought this out beforehand. In order to use the referral code, which will bring 2,500 nanas, you must first earn 15,000 nanas, which in itself is a feat.
')
Okay, let's leave alone the "legal" ways of earning. Let's try the other side. Install Fiddler2 and proxy for Android. We configure proxy for AppNana and we look requests. And they are very interesting. For example, this one:
POST to appnana2.mapiz.com/api/nanaer_login email = someone% 40example.com & password = 1234567890 & source = Android & android_id = abc
SUCCESS will come back and you will be given a cookie with the session ID. It seems everything is just right? But only this script does not limit the number of requests. Brute Force provided. Unfortunately, if you check all email and password combinations, the server will simply fall off. Although it turns out that he can fall off with a five-hundredth error if android_id is a space character ...
Let's try to solve the problem of email selection. For this we need the following query:
GET appnana2.mapiz.com/api/get_nanaer_info/?email=someone%40example.com
A complete list with input_invitation (the number of accepted referrals) b paypal_email (AppNana gets it when withdrawing money to PayPal), redeem_times (how many times the reward was received), login_times (how many times the input was made), bitcoin_address (used for output to BitCoin), offer_nanas (the number of "earned" nanas), register_ip (IP used during registration), devices (contains a list of all devices from which the input was made, along with their mac addresses and ios identifiers), email (address used during registration), lastlogin_ip (last IP), nanas (account balance), sent_invitation (quantity sent referrals invitations), gift_email (additional address for sending a gift code). And a couple more irrelevant fields.
What we have? An API that issues all user data without authorization. How will he help us? It is enough to google AppNana hack and we will immediately get an almost complete list of people who are trying to collect as many nanos as possible through referrals. In blogs you can find posts with one and a half thousand comments, each contains a referral code and ... almost everyone is tied to a Google account, since the blog runs on Blogger. Our task is simplified several times: Parsim issue of Google, we find all references to the referral code (one letter, then 8 digits), next to it we look for links to the Google profile or email for communication. In a couple of hours, such a parser can create a high-quality dictionary for brute force attacks on the above script.
Now we have a base of hundreds or even thousands of users with a balance of their personal accounts. What can we do? Everything. Everything. You will say that this is impossible, but I have not yet revealed all the cards! Next we need two more APIs:
POST to appnana2.mapiz.com/api/invite_verify
POST to appnana2.mapiz.com/api/redeem
First, it activates the referral code and charges 2,500 nanas to the account. The second, brings nanas to Bitcoin or PayPal. Both work without authorization.
First of all, you will create a pair of accounts that have more than 15,000 nanas in the account. Then we take the referral codes associated with the accounts and cash them out for all accounts. When everything is ready, it can be assumed that with 1000 codes and the accounts associated with them, you can get 999,000 valid links. Given that many actively use the codes of others to receive a referral reward, we can assume that 25% of the links have already been used, this leaves us with almost 750 new links to the account. Each connection brings 5,000 nanas to the system. By cashouting all the referral codes available to us (750,000 inquiries), we get 3.75 billion nanos distributed throughout the system.
If you take the most expensive reward (1,200,000 nanos for $ 100 PayPal), then we will generate $ 312,500, or if we prefer anonymity, and are willing to not pay, then we can withdraw all the money in Bitcoins, which will result in $ 267,857 in bitcoins on conversion day. This is without regard to the already available user balances. All we have to do is use the Redeem API to transfer money to our PayPal account or Bitcoin wallet.
Of course, it is unlikely that a startup with a single developer, who is also the head of support (information from a LinkedIn profile), has a PayPal account or a bitcoin wallet with $ 312,500, but if you automate the whole process and don’t cause strong suspicion, you can easily withdraw a round sum .
The most interesting is that this is not a direct violation of the public offer of the service. It contains clause 8a which prohibits the collection and storage of personal information of users, while its analysis is allowed without further storage, you can also ignore personal information, and save only the user name, account balance and referral code. Point 8k prohibits interference with the protection system, including its disabling, in this case there is no protection system as such, that is, using the API without authorization, I do not violate this point. Point 8r is the most extensive. It prohibits the use of automatic software to access the service, bypassing their protection system and / or robots.txt file (they don’t have the other), and modifying and using modified versions of the software for unauthorized access to the AppNana infrastructure. It's still easier, software modification is not needed, while API requests are not closed by the robots.txt file.
I have withdrawn 90,000 nanas from an account with over 1.5 million nanas. Then I sent an email to tech support asking to cancel the transaction and return the funds to the user, or at least return the funds to the user if the transaction has already been completed. The next morning I received a response from Max himself (the owner of the company), that he already knows (!) About the problem and it is solved. It is interesting that this API has been running since at least May 2013. Attached to a million people. Advertising revenue should cover all costs and is enough for one programmer who closes all the holes.
Fortunately, or unfortunately, this is the only application of the 20 installed by me from the top of Google Play, which contained a clear vulnerability. Almost half of the installed applications were built on one “engine”. Requests were like a carbon copy, and, accordingly, they were protected by the session key and required any reauthorization with the slightest interference. A couple of applications could not load ads for display. Another one, apparently, was not going to pay the money, since balance accounting was entered into SharedPrefrences, and requests were sent only to get a list of advertisers.
Source: https://habr.com/ru/post/207334/
All Articles