freishner
Beta
Verificado por Whatsapp
¡Usuario con pocos negocios! ¡Utiliza siempre saldo de Forobeta!
Me gusta el título, por favor no lo cambiéis como hicisteis con el otro post.
Este es otro de mis experimentos en el inframundo, el que antecedió al otro post y que aparentemente muy pocos pudieron comprender. Para aquellos que tengan la disposición de considerar lo inconcebible, les dejo un mensaje en clave.
Contexto
En internet hay multitud de sitios webs, algunos tienen un archivo llamado ads.txt. Cualquier petición HEAD a una url "https://dominio.com/ads.txt" debería arrojar un 200 o algo diferente. Diría que la web no es infalible y en variedad de situaciones, es perfectamente factible tomar el control de mas de alguna y reescribir algunos datos.
Colección de dominios
Aquellos entendidos ya habrán conjeturado que el proceso debería ser realizado en masa, y que para ello un listado válido ha de ser necesario. Afortunadamente no tardé encontrar uno, gracias al módulo googlesearch-python.
Detección de agujeros
Podemos usar alguno de los scripts disponibles con nmap y si procediera, usar directamente wp-scan. Pero cuidado que es bien sabido que nmap es un precursor cuando es usado en recursos ajenos. Luego si hace falta, podemos ingresar con metasploit o codear manualmente las puertas.
Llaves permanentes
Con las puertas abiertas tocaría fabricar las llaves permanentes, o de larga estadía, porque como comentaré mas adelante, la reescritura no es algo que pudiera pasar desapercibido a los dueños originales.
Recomiendo mas que urgar en el servidor, reescribir el código fuente del sitio como si fuera real, para ejecutar código remoto mas que tener la funcionalidad de consola externa. En la mayoría de los casos los archivos del tipo 217887ajhj2gh.ext son detectados y los comandos del tipo exec, system, etc, bloqueados de antemano o en el futuro próximo. Cpanel tiene funcionalidades para bloquear la IP interesada (temporalmente).
Tambien recomendaría tener un stack al menos básico de js, php y python, ya que éste último pése a no reinar en web, si nos será de utilidad para codear herramientas o mirar como están hechas. Si no encontramos php en backend, seguramente si que encontremos js, de ahí saber usarlo con node (y generalmente con expressjs) vendrá muy bien. Si encontrais php, tened por seguro que quizá tambien os haga falta code igniter, laravel u otro framework.
Reescritura
No es algo que se haga por vez única. Al contrario, el código deberá validar en cada ejecución del sitio que la reescritura siga vigente o actualizar los datos del publicante. Tampoco deberéis dar por sentado que el web master se quedará tranquilo al ver que sus ingresos empiezan a decaer de un día para otro. Afortunada a Google, poco le importará, podéis buscar en internet preguntas relacionadas o usuarios que comentan que de la noche a la mañana adsense ha dejado de funcionar y las respuestas son siempre las mismas. El dueño es reesponsable de mantener la publicidad operando.
El baner rojo
Ya lo habréis conjeturado, pero si no, os lo confirmo. La cuenta debe existir con anterioridad. En algunos casos, cuando los datos sean restablecidos por el webmaster, os aparecerá un baner rojo como el siguiente:
Lo único que hay que hacer en tal caso, es asegurarse de que ads.txt muestre lo que tiene que mostrar y luego pinchar en "Solucionar ahora" (a la derecha del banner). Llegaréis a un menu con el nombre del sitio y al pinchar en el link veréis lo siguiente:
Debéis presionar en "Buscar actualizaciones". Y no, por desgracia no es automatizable.
Una vez que Google se coma el ads.txt, el sitio quedará funcionando al instante nuevamente. Ésto solo sucederá si tenemos la mala suerte de que el bot de Google se encontrara con un ads.txt distinto, de no ser así todo irá como siempre. No obstante, eventualmente os econtraréis con el banner rojo.
Registro
Como el sitio ya tendrá el ads.txt, lo mas probable es que adsense ya exista y la aprovación solo tarde días. No deberían haber reparos, pero si los hay, esperad a leer los próximos items antes de proceder con soluciones rebuscadas.
Search Console, Analytics y otras herramientas
Os sentiréis tentados a tener el search console, pero creedme, no registreis nada mas que analytics.
Supongamos que hay dos dueños queriendo registrar un sitio. Cuando el dueño original realice el registro, vendrá el dueño temporal (nosotros) a registrar. Google enviará nuestro email al dueño original y de ahí pudieran aparecer un gran número de por menores para nosotros. Con analytics obtenemos telemetría igualmente y antes de aventurarnos con adsense, tendrémos certidumbre sobre el panorama respecto de las visitas. Seguiremos en el anonimato, de ahí que no recomiendo search console.
Caché
Si lo hay tendréis que regenerarlo
Sitio en blanco
Algunos dueños se cabrean rápido, dejando el sitio en blanco, tambien en su desesperación intentan reinstalar todo. Ante eso, una capa de caché pudiera ser preparada y mostrada en cada visita, no es complicado de realizar. Tambien se puede redireccionar cada url a dicha instantánea, de forma que adsense siga trabajando.
Bloqueo de IP para inyección remota
No hace falta gastar en una VPN o un proxy, con que hagais todo desde Google Script o desconectéis temporalmente el cable de fibra del router, ya tendréis una IP nueva.
Uso de GET
Preferid POST, y si podéis permitiroslo, enviad toda la data encriptada. Podéis usar un cifrado de sustitución de bits, no es complicado de implementar, pero si de descubrir para quien tenga que revisar. Todo lo que ingresar por GET queda registrado en logs. POST debe ser manualmente regitrado, y aunque pudiera ser registrado en la capa de red, el web master no tendría acceso a la data.
Wordfence y Wordpress
Puede que tengais que hacer algunas modificaciones en mas de algún plugin de wordpress. Extraed una copia de la base de datos y jugad con una instalación local, veréis que podréis borrar mucho de lo que wordfence u otro plugin registra. El administrador nunca se dará cuenta.
Usuario fantasma en panel admin
Muchas plataformas disponen de un panel admin. Pocos administradores se percatan de que pasa a nivel de base de datos. Podéis perfectamente agregar un usuario que no se liste ni del que se tenga registro, incluso incrustándolo directamente en el código.
Este es otro de mis experimentos en el inframundo, el que antecedió al otro post y que aparentemente muy pocos pudieron comprender. Para aquellos que tengan la disposición de considerar lo inconcebible, les dejo un mensaje en clave.
Contexto
En internet hay multitud de sitios webs, algunos tienen un archivo llamado ads.txt. Cualquier petición HEAD a una url "https://dominio.com/ads.txt" debería arrojar un 200 o algo diferente. Diría que la web no es infalible y en variedad de situaciones, es perfectamente factible tomar el control de mas de alguna y reescribir algunos datos.
Colección de dominios
Aquellos entendidos ya habrán conjeturado que el proceso debería ser realizado en masa, y que para ello un listado válido ha de ser necesario. Afortunadamente no tardé encontrar uno, gracias al módulo googlesearch-python.
Detección de agujeros
Podemos usar alguno de los scripts disponibles con nmap y si procediera, usar directamente wp-scan. Pero cuidado que es bien sabido que nmap es un precursor cuando es usado en recursos ajenos. Luego si hace falta, podemos ingresar con metasploit o codear manualmente las puertas.
Llaves permanentes
Con las puertas abiertas tocaría fabricar las llaves permanentes, o de larga estadía, porque como comentaré mas adelante, la reescritura no es algo que pudiera pasar desapercibido a los dueños originales.
Recomiendo mas que urgar en el servidor, reescribir el código fuente del sitio como si fuera real, para ejecutar código remoto mas que tener la funcionalidad de consola externa. En la mayoría de los casos los archivos del tipo 217887ajhj2gh.ext son detectados y los comandos del tipo exec, system, etc, bloqueados de antemano o en el futuro próximo. Cpanel tiene funcionalidades para bloquear la IP interesada (temporalmente).
Tambien recomendaría tener un stack al menos básico de js, php y python, ya que éste último pése a no reinar en web, si nos será de utilidad para codear herramientas o mirar como están hechas. Si no encontramos php en backend, seguramente si que encontremos js, de ahí saber usarlo con node (y generalmente con expressjs) vendrá muy bien. Si encontrais php, tened por seguro que quizá tambien os haga falta code igniter, laravel u otro framework.
Reescritura
No es algo que se haga por vez única. Al contrario, el código deberá validar en cada ejecución del sitio que la reescritura siga vigente o actualizar los datos del publicante. Tampoco deberéis dar por sentado que el web master se quedará tranquilo al ver que sus ingresos empiezan a decaer de un día para otro. Afortunada a Google, poco le importará, podéis buscar en internet preguntas relacionadas o usuarios que comentan que de la noche a la mañana adsense ha dejado de funcionar y las respuestas son siempre las mismas. El dueño es reesponsable de mantener la publicidad operando.
El baner rojo
Ya lo habréis conjeturado, pero si no, os lo confirmo. La cuenta debe existir con anterioridad. En algunos casos, cuando los datos sean restablecidos por el webmaster, os aparecerá un baner rojo como el siguiente:
Lo único que hay que hacer en tal caso, es asegurarse de que ads.txt muestre lo que tiene que mostrar y luego pinchar en "Solucionar ahora" (a la derecha del banner). Llegaréis a un menu con el nombre del sitio y al pinchar en el link veréis lo siguiente:
Debéis presionar en "Buscar actualizaciones". Y no, por desgracia no es automatizable.
Una vez que Google se coma el ads.txt, el sitio quedará funcionando al instante nuevamente. Ésto solo sucederá si tenemos la mala suerte de que el bot de Google se encontrara con un ads.txt distinto, de no ser así todo irá como siempre. No obstante, eventualmente os econtraréis con el banner rojo.
Registro
Como el sitio ya tendrá el ads.txt, lo mas probable es que adsense ya exista y la aprovación solo tarde días. No deberían haber reparos, pero si los hay, esperad a leer los próximos items antes de proceder con soluciones rebuscadas.
Search Console, Analytics y otras herramientas
Os sentiréis tentados a tener el search console, pero creedme, no registreis nada mas que analytics.
Supongamos que hay dos dueños queriendo registrar un sitio. Cuando el dueño original realice el registro, vendrá el dueño temporal (nosotros) a registrar. Google enviará nuestro email al dueño original y de ahí pudieran aparecer un gran número de por menores para nosotros. Con analytics obtenemos telemetría igualmente y antes de aventurarnos con adsense, tendrémos certidumbre sobre el panorama respecto de las visitas. Seguiremos en el anonimato, de ahí que no recomiendo search console.
Caché
Si lo hay tendréis que regenerarlo
Sitio en blanco
Algunos dueños se cabrean rápido, dejando el sitio en blanco, tambien en su desesperación intentan reinstalar todo. Ante eso, una capa de caché pudiera ser preparada y mostrada en cada visita, no es complicado de realizar. Tambien se puede redireccionar cada url a dicha instantánea, de forma que adsense siga trabajando.
Bloqueo de IP para inyección remota
No hace falta gastar en una VPN o un proxy, con que hagais todo desde Google Script o desconectéis temporalmente el cable de fibra del router, ya tendréis una IP nueva.
Uso de GET
Preferid POST, y si podéis permitiroslo, enviad toda la data encriptada. Podéis usar un cifrado de sustitución de bits, no es complicado de implementar, pero si de descubrir para quien tenga que revisar. Todo lo que ingresar por GET queda registrado en logs. POST debe ser manualmente regitrado, y aunque pudiera ser registrado en la capa de red, el web master no tendría acceso a la data.
Wordfence y Wordpress
Puede que tengais que hacer algunas modificaciones en mas de algún plugin de wordpress. Extraed una copia de la base de datos y jugad con una instalación local, veréis que podréis borrar mucho de lo que wordfence u otro plugin registra. El administrador nunca se dará cuenta.
Usuario fantasma en panel admin
Muchas plataformas disponen de un panel admin. Pocos administradores se percatan de que pasa a nivel de base de datos. Podéis perfectamente agregar un usuario que no se liste ni del que se tenga registro, incluso incrustándolo directamente en el código.
Última edición:
