EmaMaker
/
GShellAutomator
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

update README.md

master
EmaMaker 2021-11-05 23:03:13 +01:00
parent 5fb1d0edde
commit 648e2d7698
1 changed files with 22 additions and 24 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

46
README.md
View File

@ -1,11 +1,11 @@
# <b> Google Cloud Shell Automator! </b>
# <b> Google Cloud Shell Console Automator! </b>
# <b> What is this </b>
This program creates a botnet to execute arbitrary code using multiple Google Shell Docker containers.<br>
<br>
# <b> Dependendencies </b>
# <b> Dependencies </b>
This program needs some dependencies to work. All of python dependencies are already installed in the venv folder. Note that for now this makes use of xephyr to create virtual desktops and for now this only works on Linux with X11 as a display manager. The packages' names will vary from distro to distro, here are the most important ones which you will need to take care by yourself
* Xephyr (xorg-xephyr)
@ -14,7 +14,11 @@ This program needs some dependencies to work. All of python dependencies are alr
<br>
# <b> Execution </b>
From the root rolder of the project, execute
First start the Account Server, from the root of the folder, open a terminal session and run
python src/qwiklabs/account_server/account_server.py
Now start the bot. From the root rolder of the project, execute
src/colab_automator.sh
@ -26,33 +30,23 @@ order
# <b> Explanation of services and exploit </b>
### <b> Google Colab and Qwiklabs </b>
Google
The downside is that the account gets temporary blocked when a too andlong intense use is detected.
Qwiklabs (qwiklabs.com) is a third-party service which gives temporary Google Accounts for training in Google Cloud Shell use. Their first course (https://www.qwiklabs.com/focuses/2794?parent=catalog) is completely free, others require some in-site credits to be purchased.
Combining the two services, infinite temporary and disposable Google Accounts can be obtained from qwiklabs and used for mining on colab, until the qwiklabs session expires or the miner gets blocked by Colab. At such point, a new session can be started. That's basically free money. Obviously this can also be used to automated non-malicious tasks, as long as the Colab notebook is publicly available (e.g. as a github gist). After a certain time number of times repeating the course, the qwiklabs account might reach it's <i>quota</i> for that course and a new one needs to be created. I'll will look into a way of automating account creation in the future. For now, use temp mails from temp-mail.org when creating accounts
<br>
Google Cloud Shell is the well-know cloud computing platform by Google, just like Amazon AWS or Microsoft Azure. Unline those other two, Google Cloud Shell offers a free Console to every user, running 1vCPU of a Intel Xeon and 2GB of RAM, with some storage space. All for free, no credit card or other crap required. Also to be noted, that a reboot of the cloud shell console (especially in ephimeral mode) offers a complete new machine, with different ip and mac addresses.
Combining the two services, infinite temporary and disposable Google Accounts can be obtained from qwiklabs and used to execute arbitrary code on google cloud shell console, until the qwiklabs session expires. At such point, a new session can be started and the process be repeated. After a specific number of times repeating the course, the qwiklabs account might reach it's <i>quota</i> for that course and a new one needs to be created. This process has already been automated but has not been implemented into the AccountServer Yet
<br>
## <b> The whole exploit </b>
1) Prepare a list of multiple Qwiklabs accounts.
2) Get temp Google account from Qwiklabs (The MAC address has to be spoofed). However, when starting a lab on qwiklabs, sometimes the website presents a captcha and prevents the user from resolving it via audio (common bypass) for the following reasons:
* Account accessed too many times in a too little timeframe
* Tor, common VPN providers and most free proxies are recognized and presented a captcha
* Selenium is recognized as an automated browser session
This problems can easily be bypassed by starting a chrome session with an empty profile, spoofing the MAC but not the IP and automating the browser session by programmatically moving mouse and keyboard. (This is done in <i>get_account_from_qwiklabs.py</i>)
3) Access Google Colab with the newly obtained account, start a Proxy. Google Colab doesn't get recognized as a proxy
4) Start another script, which is proxed on GColab. This will create and destroy qwiklabs accounts on the need to replace accounts that have been blocked. Restart the colab-proxy session each time to get a new ip, and spoof the mac accordingly
5) Again, get a new ip from the proxy-colab session. Now head over again to qwiklabs.com, get a new google account and use this to start any notebook. The code will be automatically executed, the needed backend (None, GPU, TPU) can be choosen
6) Every 45 minutes, get new accounts from qwiklabs to replace the ones currently is use. Always get new accounts while proxed
<br>
### <b> The whole exploit </b>
1) Prepare a list of multiple Qwiklabs accounts. The Account Server will manage those.
2) Get temp Google account from Qwiklabs (spoof mac addr? Not needed if running in docker containers). Most free proxies (tor included) are flagged as such. In order not have problems with the website presenting captchas, proxies and mac spoofing need to be left aside. Manually automating google chrome with pyautogui instead of selenium also helps
3) Access Google Cloud Shell with the newly obtained account.
4) Execute arbitrary code. The machine can also be rebooted multiple times across the same session to simulate having new machine.
5) When the session expires, start again from 2.
<br>
## <b> What to do when some website prevent the use of Selenium </b>
Selenium carries some javascript and other stuff which can easily be detected by most websites - GColab and Qwiklabs included - and get the session blocked, especially if captchas are involved (There are workarounds to captchas for selenium - https://github.com/ohyicong/recaptcha_v2_solver - but often the audio captcha doesn't even get presented to the user if an automated browser session is detected)
### <b> What to do when some website prevent the use of Selenium </b>
Selenium carries some javascript and other stuff which can easily be detected by most websites - GColab and Qwiklabs included - and get the session blocked, especially if captchas are involved (There are workarounds to captchas for selenium - https://github.com/ohyicong/recaptcha_v2_solver - but often the audio captcha doesn't even get presented to the user if an automated browser session is detected).
However in the current setup this is not needed, has pyautogui works wonders
<br>
### <b> The workaround: Mouse and Keyboard control</b>
@ -62,6 +56,10 @@ For simpicity, and to avoid messing up the OS by clicking on the wrong stuff, bo
<br>
<br>
### <b> Account Server </b>
The idea here is to start multiple sessions from different docker containers running on the same machine. To do this, the management of Qwiklabs accounts needs to be centralized, in order to avoid having different instances of the bot crashing and stopping each other randomly.
The AccountServer does just this. It's a bare metal TCP Server which dispenses accounts to the different instances of the bot when they ask.
# Qwiklabs monthly subscription
There is a workaround to obtain a qwiklabs monthly subscription that actually works: https://www.youtube.com/watch?v=gF6agG9kyBs (actually works).<br>
Tested on account i3z8qtab@xojxe.com, now it has monthly sub