El Blog de Gualtrysoft

Windows 2000/2003/2008, Active Directory, VBScript, Hyper-V, PowerShell y todo aquello interesante a la hora de usar, configurar y administrar Windows Server. También tenemos longanizas…

Encriptación de Scripts VBScript: SCRENC.EXE

Posted by urpiano en Jueves 7 \07\UTC diciembre \07\UTC 2006

En ocasiones podemos querer que nuestros scripts puedan ser utilizados, pero que no se pueda leer el código. Imaginemos que tenemos un script en el cual necesitamos que aparezca, por ejemplo, la contraseña de determinado usuario, pues estamos ejecutándolo haciendo un RunAs y por ello la contraseña está ahí. Si este script es ejecutable por cualquiera (por ejemplo en un script de logon), cualquiera puede abrirlo con un editor de texto y ver esa contraseña. Para evitar esto podemos tener el script encriptado. Realmente usar la encriptación del VBScript es un error en esta caso (ya veremos porqué más adelante), pues tenemos mejores formas de hacerlo. Lo correcto es que el script solicite que sea entrada la contraseña; para solucionar el problema añadido de que alguien pueda estar mirando mientras entramos la contraseña y, por tanto, sea capaz de verla, se puede entrar en una caja de texto que enmascare la constraseña, por medio de automatización de Internet Explorer, tal y como indica este artículo:

Masking Passwords by Using Internet Explorer
http://www.microsoft.com/technet/scriptcenter/guide/sas_ent_lppm.mspx?mfr=true

Sí puede ser interesante para, por ejemplo, ocultar rutas de carpetas compartidas ocultas, o sencillamente porque no queremos compartir nuestro código. Para la encriptación de los scripts, necesitamos instalar Script Encoder:

Download details Script Encoder
http://www.microsoft.com/downloads/details.aspx?FamilyID=E7877F67-C447-4873-B1B0-21F0626A6329&displaylang=en&Hash=C6kjX0zrFadqi1l0ER11JFbwRkL2U1eSIKYcP8LDovRo%2fkb4udrHW0caMz8uraO1JNCnQK88HYbGKVRJnUlqtA%3d%3d

La forma de uso es:

screnc <fichero.vbs> <fichero.vbe>

Veamos un ejemplo con un simple script de “Hola Mundo”:

WScript.Echo "Hola Mundo"

Lo guardamos como hola-mundo.vbs y ejecutamos:

screnc hola-mundo.vbs hola-mundo.vbe

Ahora abrimos el fichero hola-mundo.vbe y vemos lo siguiente:

#@~^GQAAAA== Um.bwDR21tK~J_Wsl,H;U9WJhAgAAA==^#~@

¡Rraarrro, rraarro, rrrarrrooo!

¡Ale, ya tenemos nuestro script operativo y a salvo de ojos indiscretos!… ¿o no?. Pues va a ser que no. Como la propia documentación de screnc advierte:

Note that this encoding only prevents casual viewing of your code; it will not prevent the determined hacker from seeing what you’ve done and how.

Es decir, que sólo lo protejemos de la vista de pipiolos, pero no de gente más avezada. Y si no, basta con ver este par de enlaces:

VBE decoder – Decode all files encoded (original version) with screnc.exe
http://www.interclasse.com/scripts/decovbe.php

Windows Script Decoder
http://www.virtualconspiracy.com/index.php?page=scrdec/intro

Así que protejer de ojos indiscretos una contraseña por medio de la encriptación es una forma no recomendable, por no decir mala, de hacerlo; aunque sea más complejo, lo seguro es utilizar el método del primer enlace que he puesto. Así pues, encriptar un script sólo vale para evitar que se pueda ver el código de éste, y ni siquiera la encriptación asegura ésto, pues es fácilmente rompible.

Conclusión: si te preocupa que pueda acceder a tu código otra gente, olvídate de VBScript, usa VB y trabaja con programas compilados como EXE en su lugar. Encriptar scripts sólo sirve para que un usuario no muy ducho en estas lides se quede “a cuadros” al abrir el script, pero un usuario un poquito espabilado podrá ver tu código y, es más, el hecho de estar encriptado probablemente le lanzará a desear con más ahínco ver el código, pues sospechará que algo se quiere ocultar, como, por ejemplo, una contraseña. Por último, encriptar un script para ocultar una contraseña es inseguro, se debe solicitarl entrar la contraseña y utilizar el método de enmascaramiento por medio de Internet Explorer. No obstante, en ocasiones nos veremos que es necesario poner la contraseña en el script, pues por tratarse de algo automatizado totalmente, por no poder estar suministrando la contraseña cada vez que sea necesario (pensemos en un script de logon, por ejemplo, que necesita escribir en el registro en HKLM y por tanto requiere un usuario con ese derecho). Si nos encontramos en esta tesitura, lo mejor es que estudiemos la forma de evitar usar el adminsitrador con el script; en su lugar debemos de tratar que el usuario cuya contraseña está en el script tenga la capacidad, únicamente, de hacer lo que queremos que haga en el script (imaginemos que queremos que escriba en determinada rama de HKLM, podríamos crear una GPO que le diera permiso de escritura en esa clave a un usuario normal y así evitar que nos cacen una contraseña de un administrador).

5 comentarios to “Encriptación de Scripts VBScript: SCRENC.EXE”

  1. […] es, ni mucho menos algo demasiado seguro, pues es muy fácil saltarse esa encriptación, como se ve aquí. Otra estrategia es el hacerlo de forma interactiva, desde un equipo en el que lanzamos el script […]

  2. Cristian Solervicens C. said

    VB es INTERPRETADO, y hay herramientas muy accesibles que permiten decompilar y volver al código fuente.
    Lo mejor es hacer los scripts que quieran y al momento de lanzarlos hacerlo con “runas” (dentro dell host) o con la utilidad PsExec, de PsTools si desearan hacerlo de forma remota.

    • urpiano said

      Eso es algo que está clarísimo. El espíritu de esta entrada es la de hablar de scripts que se ejecutan de manera automatizada, no interactivamente. En estos casos si haces un BAT que llama a psexec, pondrás la contraseña en el BAT, lo cual es peor que encriptar un un VbScript con SCRENC.EXE, que al menos para poder leerlo hay que andar buscando herramientas de “niño malo”; si llamas a RunAs desde un VbScript en ese script tendrá que ir la contraseña (no valdría un BAT por que RunAs no recibe la contraseña, sólo la pide de manera interactiva; con VbScript al menos se la puedes pasar por medio de SendKeys), con lo que mejor será dificultar su acceso con SCRENC.EXE a dejar el script en texto plano: no estarás securizando del todo el script, pero al menos establecerás un filtro sobre quién es capaz de acceder a ella, sólo usuarios muy avanzados podrán saber qué hacer para “destriparlo”. La mejor posibilidad es PowerShell, que te permite obtener la contraseña encriptada desde un fichero, en su contra que no podemos contar con que todos los equipos tengan PowerShell, sólo los Windows 7 y Windows Server 2008 R2 es seguro que tendrán PowerShell.

      Obviamente, lo mejor es lo que tú dices, no ejecutar nunca un script que lleve en sí la contraseña, si no utilizar RunAs o PsExec para lanzar ese script de manera interactiva; en el momento en que te veas obligado a automatizar la ejecución empieza el riesgo. Por ello, lo mejor es que una ejecución automatizada de un script nunca debe llevar una contraseña dentro, pero hay veces que es inevitable (por ejemplo, la necesidad de hacer algo que requiere privilegios administrativos desde un script de inicio de sesión). Son platillos de una balanza: por un lado la seguridad y por el otro el esfuerzo administrativo de no realizar la tarea “corriendo el riesgo”; en muchas ocasiones, los administradores de red optarán por el riesgo, pues preferirán eso a tener que, realizar de forma manual un atarea (nEquipos * Nusuariosporequipo) veces.

  3. […] del script, para que así no sea legible la contraseña, pero, como se ve en esta entrada de este mismo blog, no es una solución ni mucho menos definitiva, pudiendo averiguar la […]

  4. Edward said

    Hay muchas formas, se puede crear un archivo y leer la contraseña desde ahí, ya sea para pasarla a un runas con sendkeys. Ese archivo se encripta usando los métodos de encripción modernos, eso sí. si alguien toma ese archivo podría eventualmente obtener la contraseña.

    Otra manera que se me ocurre es usar un servicio web (interno) que provea la contraseña, desde VBscript se pregunta y se devuelve encriptada, si se desea correr una tarea automática en nEquiposxNusuarios se pueden usar las credenciales de la máquina para registrarse y los IP de las máquinas como autorizados a ese servicio web. Es más si se desea se puede hacer un servicio web que devuelva el script de ejecución, el script del cliente solo seria un script para correr otro script en memoria (por medio de Execute)

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

 
A %d blogueros les gusta esto: