Información blog

Linux, tutoriales, noticias, sistemas, redes y seguridad informática, entre otras cosas.

miércoles, 29 de julio de 2015

Cómo salvaguardar parcialmente Android de Stagefright

Ayer ya hablé sobre la nueva gran vulnerabilidad de AndroidStagefright; la cual me tiene altamente preocupado; especialmente debido a la incógnita de la recepción del parche... Lo ideal sería que todos publicasen los parches para todos los móviles y versiones de Android, pero más allá de esa utopía: ¿Cuantos fabricantes moverán ficha? ¿Cuantos móviles cubrirán? ¿Cuantos móviles quedarán desamparados y sin protección alguna?

Debido a ello, indagando por Internet encontré una solución que, aunque no es un parche en sí, nos proveerá de cierta protección contra este ataque. Eso no significa que no se deba actualizar el móvil (en caso de tener la posibilidad de hacerlo); pero si eres uno de aquellos que han quedado desamparados, obviamente será muy recomendable aplicar está solución, ya que en caso contrario hay muchas posibilidades de que tu móvil quede infectado, pues lo único que el atacante necesitaría sería nuestro número de móvil.

portada_android

La solución es bastante sencilla, y se basa en deshabilitar la autorrecuperación de los mensajes; funcionalidad que ejecuta los vídeos recibidos automáticamente sin intervención del usuario. Esto no inhabilita la funcionalidad en sí, sino que evita que los MMS se carguen automáticamente, evitando que el ataque se pueda producir; a menos que obviamente se cargue el MMS en cuestión manualmente. Obviamente no es una solución infalible, pero sí que añade una capa de seguridad considerable a nuestro dispositivo; capa necesaria visto lo "jugoso" que puede resultar dicho ataque.

Para lograr dicha deshabilitación habría que dirigirse a la sección Mensajes --> Ajustes --> Mensajes Multimedia (MMS). Dentro de dicha sección observaríamos diferentes parámetro relacionados con los mensajes multimedia; entre ellos hay una opción llamada Autorecuperar. Esa opción está activada por defecto y hace que el mensaje multimedia se cargue automáticamente, con todo el peligro que ello conlleva. Afortunadamente dicha opción se puede deshabilitar, impidiendo la carga automática del contenido y protegiendo notablemente nuestro equipo.

Obviamente no es una solución infalible, ya que si por ejemplo cargásemos manualmente el mensaje recibido no tendríamos escapatoria, pero al menos la infección de nuestro equipo requeriría la intervención del usuario.

Dicho proceso se vería representado en el siguiente esquema:

esquema:MMS

Esquema MMS

El problema con esto sería que mucha gente podría cargar el mensaje por accidente; por ello sería necesaria la concienciación de las personas acerca de este problema, pero para empezar... ¿Son las personas conscientes de esta noticia?

Más allá de las páginas dedicadas exclusivamente a la informática y/o tecnología; ¿Habéis leído algún periódico que haya alertado a la gente sobre este problema? ¿Habéis visto las noticias locales advirtiendo sobre este problema? Desafortunadamente he visto pocas noticias al respecto y todas ellas muy poco promulgadas o muy mal posicionadas (esquinas de periódicos online en las cuales se ve la noticia pero no de forma llamativa)... Tal vez le den más relevancia más tarde, no lo sé; pero lo cierto es que la mayoría de los usuarios no técnicos no son conscientes del peligro que corren y de esto gran parte de la culpa es de los medios de comunicación... Tal vez el hecho de que Windows10 vea hoy la luz haya eclipsado esta catástrofe, pero eso no es excusa para que no se molesten en darle relevancia a una catástrofe como ésta.

Os recomiendo probar a preguntar a 5 personas de vuestro circulo cercano que no esté relacionado con el mundo de la informática. Preguntadles acerca de la nueva vulnerabilidad de Android; no de forma técnica, sino de forma coloquial. Algo como: "Te has enterado del nuevo fallo de seguridad de Android?". Probablemente el 99% os conteste con un rotundo no.

Esto ha sido todo por hoy. Espero que el "truco" os haya resultado útil.

Saludos cordiales.

martes, 28 de julio de 2015

Stagefright, la mayor vulnerabilidad de Android

Android ha sufrido otro enorme golpe... Nada ni más y nada menos que respecto a la seguridad. Todos sabemos que Android dista de ser seguro; en parte debido a las malas prácticas de los usuarios finales, pero también por el libre albedrío que existe en el Play Store. Con el tiempo el sistema ha ido mejorando algunos aspectos para fortificar sus sistemas, pero aún así aún le queda un largo camino, tal y como se ha ido demostrando en los últimos meses... Hasta ahora si se seguían una serie buenas prácticas todo iba bien; pero ya ha dejado de ser así... Stagefright, la nueva vulnerabilidad de Android, publicada por Zimperium, ha sido catalogada como la más grave y escandalosa hasta la fecha... Nada menos que el 95% de los móviles presentan dicha vulnerabilidad, ya que la vulnerabilidad se presenta desde Android 2.2 a Android 5.1.


Portada_stagefright

Más allá de la cantidad de dispositivos, la vulnerabilidad en sí está catalogada como una de gravedad extremadamente alta, pues consiste en que, debido a un error en el manejo de Android en el procesamiento de vídeos recibidos vía MMS (Mensaje multimedia), un atacante puede aprovechar el error para enviar un vídeo falso con código malintencionado dentro, permitiendole al atacante tomar el control de nuestro dispositivo. Más de uno pensará que, mientras que no se abra ningún mensaje de ese tipo, nuestros móviles estarán a salvo... Desgraciadamente no es así. El mero hecho de recibir el vídeo es suficiente para que nuestro sistema quede infectado, es decir que podrían infectar nuestro dispositivo sin que el usuario final intervenga en momento alguno...

Afortunadamente no se ha visto que hayan explotado esta vulnerabilidad hasta el momento, y además Zimperium no ha querido revelar demasiado detalles acerca de dicho fallo por razones obvias, si bien explicarán todos los detalles en la black hat, la cual comienza el día 1 de Agosto y finaliza el día 6. Obviamente Google ha recibido la información correspondiente a la vulnerabilidad, y ya ha publicado el parche correspondiente a los fabricantes de móviles. Es más, Zimperium dice haber reportado la vulnerabilidad a Google en Abril.

El problema en este punto es que a partir de aquí es responsabilidad de los fabricantes publicar los parches para cada uno de sus dispositivos y sistemas operativos. ¿Se publicarán parches para todos? Después de revelar los detalle de la vulnerabilidad en la black hat, todos aquellos móviles que no hayan recibido la actualización quedarán gravemente expuestos... ¿Cuanto tiempo tardarán los fabricantes en publicar los parches? Hablamos de una carrera contrareloj en la que lamentablemente los fabricantes tienen desventaja debido a uno de los mayores problemas de Android: la enorme fragmentación que existen en el mercado.

Tantas versiones, tantos dispositivos y tan poco tiempo; hablamos de un problema de una enorme magnitud en el que millones de dispositivos corren peligro ¿Se salvarán todos a tiempo o solamente se preocuparán por los dispositivos de alta gama? ¿Tal vez esta sea la oportunidad para que todos los dispositivos salten a Lollipop y se atenúe la fragmentación? Teniendo en cuenta la trayectoria actual de los fabricantes tengo dudo que "salven" a todos, aunque en breve lo sabremos...

Saludos.

Man: Creando nuestros propios manuales Linux

Recientemente mirando diferentes manuales y ayudas de algunas aplicaciones y/o scripts estuve pensando que si bien son realmente útiles, no tenemos por costumbre crear nuestros propias guías de ayuda. Esto no lo digo desde el punto de un desarrollador o un administrador de sistemas, sino desde el punto de la manejabilidad de un programa o script. Cuando alguien crea una aplicación, conoce ésta como si fuese su propio "hijo" ya que ha estado creándola con cariño y esfuerzo hasta alcanzar el resultado deseado, pero el hecho de que el creador conozca los entresijos de su aplicación, no implica que el resto tenga la misma facilidad... A veces la aplicación en cuestión no tiene misterio alguno, ya que se basa en un simple ejecutable que efectúa una tarea y listo ¿Pero que ocurre cuando tenemos una aplicación que ofrece diferentes posibilidades? Probablemente alguno piense en la posibilidad de añadir un parámetro -h (help) para brindar ayuda al usuario, pero el uso de este recurso debe de ser con fines muy genéricos... Es decir, no podemos poner un enorme párrafo que explique al detalle todo, sino unas ayudas generales de los parámetros que ofrece la aplicación. Es por ello que cuando se quiere brindar una guía muy detallada con respecto a la aplicación, se debe recurrir a un recurso un poco más profundo y avanzado: Un recurso llamado man.

Portada_manuales

¿Cuantas veces hemos usado el comando man para orientarnos en el uso de un nuevo programa? ¿De cuantos atolladeros hemos salido al navegar por los entresijos de los manuales ofrecidos por este comando? Esta herramienta, aunque es muy minimista, pues está basada en la consola, ofrece una ayuda indispensable a los usuarios, sin importar el nivel de conocimientos de éstos; es por ello que se trata de un recurso muy a tener en cuenta a la hora de querer compartir una herramienta con el público... Así bien ¿De donde proceden dichos manuales? Obviamente han sido escritos y generados por alguien, pero más de uno puede pensar que este proceso resulta laborioso y complicado, si bien no lo es tanto como parece... Para ello, lo primero y más aconsejable sería coger un manual y "diseccionarlo" con el fin de saber como funciona, ya que aunque a primera vista no lo parezca, el contenido de un manual, y lo mostrado por éste al escribir man "programa" difieren bastante.

Comencemos entonces seleccionando un programa al azar; yo en mi caso he optado por uno que viene incluido en el sistema por defecto llamado gpg, pero no importa cual escojamos siempre y cuando éste se encuentre instalado en el sistema y tenga un manual incluido... Para ello lo primero que habría que saber es donde se "esconde" gpg y todo lo relacionado con éste; lo cual lograríamos preguntando al sistema donde ésta; es decir, usando el comando whereis tal y como muestro a continuación:

  1. whereis gpg

Al preguntarle esto al sistema, obtendremos la localización de los distintos ficheros asociados a éste, entre los cuales uno de ellos nos interesaría especialmente; Dicho fichero (sea cual sea el programa que estemos buscando) siempre estará alojado en un subdirectorio que se encontraría en el interior de /usr/share/man. El subdirectorio en cuestión variaría dependiendo del programa buscado, pero es importante tener presente esta ruta inicial para buscar nuestro manual; Por ejemplo en mi caso el manual de gpg estaría alojado es /usr/share/man/man1/ y su nombre sería gpg.1.gz. Para no alterar este fichero tan importante, lo ideal sería copiarlo en otro directorio para poder manipularlo sin miedo alguno a modificar su interior o a corromperlo por accidente; esto se realizaría mediante el comando cp y yo por ejemplo he optado por copiarlo al directorio /usr/src/:

  1. cp /usr/share/man/man1/gpg.1.gz /usr/src/

Dependiendo del manual que estemos buscando puede estar almacenado en una carpeta man distinta, pues si observáis el contenido de la carpeta man, veréis que aparecen 8 secciones distintas referentes a la carpeta man; secciones con una representación numérica que va del 1 al 8. Por ejemplo gpg se encuentra en la sección 1 (man1) pero en cambio si buscásemos iptables veríamos que se encuentra en la sección número 8... Estos números tienen su razón de ser... Con el fin de tener todo correctamente estructurado, se han establecido una serie de estándares numéricos, para que dependiendo del tipo de programa, su manual correspondiente sea almacenado en una carpeta u otra.  Dichos estándares son denominados números de sección y he aquí el listado de los susodichos junto con su función y/o propósito correspondiente:

  1. 1 Programas ejecutables y guiones del intérprete de órdenes
  2. 2 Funciones provistas por el núcleo (kernel) del sistema
  3. 3 Funciones de la biblioteca del sistema
  4. 4 Ficheros especiales (se encuentran generalmente en /dev)
  5. 5 Formato de ficheros y convenios p.ej. I/etc/passwd
  6. 6 Juegos
  7. 7 Paquetes de macros y convenios p.ej. man(7), groff(7).
  8. 8 Órdenes de administración del sistema (generalmente solo son para root)

Ahora que tenemos nuestro fichero en un lugar seguro, podemos manipularlo sin miedo. Si observáis bien, el fichero en cuestión está comprimido en formato gzip, con lo que lo primero que tendríamos que hacer para poder pasar a su manipulación sería descomprimirlo mediante el comando:

  1. gzip -d /usr/src/gpg.1.gz

Con el fichero descomprimido, ya se podría observar lo que hay en su interior sin problema alguno... Al ser un fichero bastante extenso y que queremos revisar con atención, recomiendo prescindir del uso del comando cat y optar por un editor de texto a vuestra elección (vi, nano, mcedit...) o por hacer uso del comando less. Explorando con atención el fichero veréis que está plagado de diferentes secciones que definen cada uno de los aspectos del manual; desde el título, a párrafos y secciones que luego son mostradas en el manual de distintas formas, dependiendo de las nomenclaturas utilizadas en el manual... Dichos parámetros o nomenclaturas son denominados macros de formato, y forman parte del formato de texto que se mostrará al usuario final. Las macros que aparecen en el fichero pueden resultar algo confusas para nosotros... No son descriptivas ni tienen un guión que muestre qué hace cada cosa; es por ello que a continuación os explicaré la función de cada uno de los éstas.

Comencemos con la primer macro de todas, que hace referencia al título del manual; representada como .TH. Aquí es muy importante tener en cuenta que el título que se vaya a poner debe de seguir una estructura determinada, estructura que debe de seguirse si queremos que la macro en cuestión funcione correctamente. La estructura siempre sería la misma:

.TH nombre-comando número-sección fecha-creación Autor título-manual

Por ejemplo en gpg el título sería:

.TH GPG 1 2015-03-08 "GnuPG 1.4.12" "GNU Privacy Guard"

Además del título, se pueden generar diferentes secciones en el manual; secciones que vienen representadas con la macro .SH y que siempre tienen la estructura:

.SH nombre_sección

A diferencia de con el título, aquí no es necesario seguir procedimiento alguno para la asignación de secciones... Lo importante es tener clara la estructura del manual para ser lo más informativo posible para el usuario final... Un listado de ejemplo de los nombre de secciones más usados sería:

NAME /NOMBRE
Nombre del comando, archivo o herramienta.
SYNOPSIS /SINOPSIS
Sintaxis de uso de forma muy resumida.
DESCRIPTION /DESCRIPCION
Descripción del comando, archivo o herramienta.
OPTIONS/OPCIONES
Descripción de las opciones aceptadas en la línea de comandos por el comando o herramienta. Normalmente solo se implementa en las secciones 1 y 8.
COMMANDS/COMANDOS
Listado de los comandos asociados a la herramienta. Por lo general solo se suelen usar opciones pero a veces también se hace uso de esta sección.
ENVIRONMENT /ENTORNO
Muestra una lista de las variables utilizadas por el comando o herramienta, describiendo cómo son usadas.
FILES /ARCHIVOS
Listado de todos los archivos utilizados por el comando o herramienta.
BUGS /ERRORES
Descripción de errores o problemas conocidos.
EXAMPLE /EJEMPLO
Ejemplos de uso del comando o herramienta.
AUTHORS/AUTORES
Lista de los nombres de los autores. Generalmente se utiliza el formato: Nombre del Autor <email@example.org>.
SEE ALSO/VÉASE TAMBIÉN
Una lista de páginas man sugeridas, separadas por coma.


El listado puede ser mayor, pero estos podrían considerarse como los recursos "estándar" o los recursos más usados... Teniendo definidas las secciones, no podemos olvidar que a veces es necesario recurrir a algunos formatos para resaltar algunas partes de nuestro contenido, ya sea para ponerlo en negrita o para ponerlo en subrayado. Los métodos para dar formato al texto serían:

.B --> Negrita
.I --> Subrayado
.R --> Romana

Estos parámetros o macros podrían combinarse entre sí, creando cosas tales como .BI, .IR, etc... Un inconveniente que ofrecen estos parámetros es que ocupan toda la línea, a menos que les digas lo contrario... Todo lo que vaya después de una de estas macros de formato, iría automáticamente en dicho formato, a menos que después se introdujese de otro formato nuevo que interrumpiese el anterior; por ejemplo:

.B esto es una .I prueba --> esto es una prueba

Otra forma de hacer esta cambio pero teniendo todo mejor controlado ,sería usando los mismos caracteres (es decir B I y R) precedidos por \f. Con esto no sería necesario recurrir a espacios entre cada macro, siendo muy cómodo cuando queremos introducir pequeños cambios en párrafos grandes. Si nos basásemos en el ejemplo anterior sería:

\fBesto es una \fIprueba --> esto es una prueba

Con los formatos bien claros, podríamos pasar a otro aspecto muy importante de los manuales. los párrafos y saltos de línea. El salto de línea es muy parecido al que se usa en HTML; ya que se usa la macro .br. Mientras que cuando queremos presentar un párrafo, la macro .PP sería la encargada de lograr dicho objetivo.

Por último pero no menos importante estarían los comentarios... Un comentario se trata de más ni menos que texto que solamente aquel que entre en el propio manual (es decir, que haya entrado como nosotros y no mediante el comando man) puede ver. Esto puede ser útil cuando queremos que las futuras ediciones de éste sean realizadas por otra persona. Esto lo lograría mediante la macro .\

Ahora que tenemos las nociones generales, vamos a crear un pequeño manual basándonos en estos conceptos. El manual hará referencia a un script; con lo que su número de sección sería el 1; Al tener que poner siempre el número de sección como extensión del manual, en este manual de ejemplo llamaríamos a nuestro manual test.1. He aquí el texto que incluiremos en nuestro manual:

  1. .\Comentarios del autor
  2. .TH test 2015-07-23 Ivan "Manual de test"
  3. .SH NAME
  4. \fB test\fR - Manual de test con test en negrita
  5. .SH SYNOPSIS
  6. .I Este es un breve manual de pruebas subrayado
  7. .SH DESCRIPCION
  8. Aquí describiremos todas las características del programa
  9. .PP
  10. Este es un párrafo nuevo aparte del primero
  11. .br
  12. Además hemos añadido una nueva línea
  13. .SH FILES
  14. Los ficheros necesarios para usar el programa en caso de haberlos
  15. .SH AUTHOR
  16. .BI He aquí los datos del autor

Aunque tenemos el manual preparado, todavía no estaría listo para ser usado... Aun falta agregarlo al directorio de manuales... Para ello habría que comprimir el archivo en el mismo formato que el resto de ficheros, es decir; hay que comprimirlo en formato gzip. Esto es tan sencillo como escribir:

  1. gzip -q test.1

El comando daría como resultado un fichero denominado test.1.gz... fichero perfectamente válido para ser usado como manual; solamente quedaría alojarlo en el directorio correcto. Tal y como he comentado antes, se trata de un fichero cuyo número de sección es 1, con lo que la carpeta en la que habría que alojarlo sería en /usr/share/man/man1/. Con el fichero correctamente situado, ya podríamos escribir el comando:

  1. man test

Que daría como resultado el siguiente manual:

Manual_ejemplo

Esto sería todo por hoy. El manual creado es muy sencillo, pero puede extenderse tanto como nosotros necesitemos, siempre y cuando respetemos la sintaxis y las macros atrás mencionadas.

Espero que os haya resultado útil.

Saludos.

domingo, 26 de julio de 2015

Guía rápida de git

Hoy vengo a hablaros de una de las utilidades favoritas de aquellos que se dedican al desarrollo de aplicaciones, especialmente para los desarrolladores Open Source; se trata de git. Git, no es ni más ni menos que una herramienta de control de versiones diseñado por uno de los padres de Linux, Linus Torvalds. El objetivo de dicha herramienta es mantener con facilidad y eficiencia un gran número de archivos de código fuente, sea del lenguaje que sea, y gracias a github se ha convertido en la herramienta por excelencia de muchísimos desarrolladores, ya sean profesionales o amateurs.

Aunque el funcionamiento de esta herramienta puede parecer algo intimidante, una vez aprendidos los conceptos básicos resulta muy fácil de usar. Simplemente con memorizar unos pocos comandos bastaría para poder empezar a trabajar con git; comandos que es muy importante tener claros si queremos trabajar con eficiencia.

Git-logo

Comencemos con lo básico; lo primero que habría que hacer sería copiar el código alojado en un repositorio (ya sea de un servidor privado o de github) en nuestro equipo con el fin de poder manipularlo a nuestro antojo. Dicho objetivo se logra mediante el parámetro clone y posee la siguiente estructura:

git clone ${URL}

Por ejemplo, supongamos que queremos clonar el código de SHC en nuestro equipo para manipularlo a nuestro gusto:

  1. git clone "https://github.com/existz/shc-3.8.9"

Con el código en nuestro poder, podemos editar los archivos que queramos y prepararlos para subirlos al repositorio... Dicha preparación se puede hacer de forma individual o simplemente se pueden seleccionar todos los ficheros. Para añadir los ficheros al repositorio habría que recurrir al parámetro add de la siguiente forma:

  1. git add test.txt

Aún cuando parece que hemos añadido los ficheros al repositorio; no es así, pues primero hay que modificar nuestro repositorio local y después podríamos modificar el repositorio remoto en cuestión. Por ello, primero empezaríamos con la modificación local, la cual se realizaría mediante el parámetro commit:

  1. git commit -m test.txt

El proceso de modificación local es muy veloz, y apenas  tarda un par de segundos, tras lo cual podríamos proceder a la modificación del repositorio remoto mediante el parámetro push, lo que podría ser por ejemplo algo como:

  1. git push URL

El proceso de modificación del repositorio remoto suele requerir una autenticación basada en un usuario y una contraseña... En caso de conocer ambos datos podría modificarse el repositorio remoto, en caso contrario la modificación remota no sería posible.

Teniendo estos conceptos básicos claros, ya estaríamos preparados para hacer uso de esta estupenda herramienta de control de versiones.

Saludos.

jueves, 23 de julio de 2015

Cómo sincronizar Android y KDE con KDEconnect

En ocasiones uno puede tener las ganas de manejar un equipo remotamente, generalmente por aquel gran mal denominado pereza, pero también debido a la curiosidad que uno puede tener por manejar el PC sin tener que recurrir a los periféricos habituales. Imaginemos que deseamos utilizar algo tan común como un móvil con Android instalado; la comunicación entre éste y el PC es posible, siempre y cuando ambos tengan el software adecuado instalado y el PC posea el entorno de escritorio KDE. Para lograr nuestro objetivo necesitaremos hacer uso de un software llamado KDEconnect, capaz de establecer la comunicación entre ambos equipos que nosotros buscamos. Para aquellos que puedan tener miedo a que alguien no deseado manipule vuestro PC mediante esta herramienta; tranquilos, solamente podrán acceder aquellos móviles que vosotros autoricéis, con lo que no deberíais sufrir sorpresas.

icono-kde-connect
Icono KDE Connect

Comencemos con el PC que recibirá las conexiones. Aún poseyendo el entorno de escritorio KDE, la herramienta de control remoto que necesitamos no viene incluida por defecto en su instalación; afortunadamente, sí que viene incluida en los repositorios oficiales, con lo que simplemente habría que escribir:

  1. sudo apt-get install kdeconnect

Ahora pasaríamos a la instalación del software en el móvil, cuyo nombre es el mismo; KDE Connect, el cual se obtiene a través del Play Store. Al ser un proceso estándar que todo el mundo conoce, no alargaré en vano este post para explicar como instalar una aplicación desde el Play Store. Aún así, si que veo importante que os cercioréis que el icono relacionado con la aplicación que deseáis descargar sea el mismo que el mostrado en la primera imagen (Icono KDE Connect).

Una vez poseemos ambos puntos con los softwares instalados, habría que hacer que ambos estuviesen dentro de la misma red para que ambos se puedan detectar entre sí, lo cual significa que requeriríamos de una red wifi para poder establecer la comunicación entre ambos dispositivos. En caso de cumplir este requisito, si nos dirigiresemos a móvil y abriésemos la aplicación descargada, observaríamos que nuestro dispositivo ha detectado un PC con KDE con el que puede conectar.

Detecciónkde

El hecho de que el dispositivo esté disponible no implica que podamos conectar con él; Para poder conectar necesitaríamos "pulsar" el nombre del dispositivo, pulsación que nos llevaría a otra pantalla en la que tendremos la posibilidad de solicitar vinculación tal y como veis en la siguiente captura:

Vinculaciónkde

Dicha solicitud haría que el equipo en cuestión mostrase una notificación.de vinculación; una petición que en caso de ser aceptada, haría que en el futuro no fuese necesario volver a realizar dicha vinculación:

Recepción-vínculo

Solamente con aceptar, nuestro móvil sería capaz de conectarse con el PC. Por eso, el aspecto de nuestra aplicación móvil cambiará y se mostrará de la siguiente forma:

KDE_connectado

Con la conexión preparada, con simplemente pulsar el dispositivo con el que se tiene conexión podríamos proceder a diferentes acciones, tales como la conexión remota, el envío de pings o el control multimedia. Por ejemplo, podríamos usar la pantalla tactil del ratón para manipular el ratón remotamente o escribir en el teclado:

KDE_control

Obviamente este tipo de soluciones no son tan eficientes como el uso directo del PC, pero puede ser realmente útil en algunos momentos específicos.

Saludos.

martes, 21 de julio de 2015

Por qué NO usar telnet

El mundo cada vez se va evolucionando más y más en todos los aspectos, desde cosas tan triviales como las modas hasta la tecnología...  Raro es el usuario que hoy en día no se preocupa por aspectos de seguridad ¿Pero realmente hacemos algo al respecto? En algunas cosas se ha evolucionado a niveles que hasta hace poco parecían irreales, si bien hay otras que parece que se han quedado estancadas, aún cuando se ha demostrado que existen alternativas mucho más confiables... Hoy vengo a hablaros de una tecnología que en mi opinión se ha quedado obsoleta a nivel de seguridad pero que todavía se sigue usando de forma habitual... Vengo a hablaros del protocolo telnet.
Portada_telnet
Telnet se trata de un protocolo de comunicación que permite "viajar" de una máquina a otra para poder controlar esta última remotamente como si estuviésemos en ella. Dicho protocolo fue ideado en 1983, época en la que no había preocupación alguna por la seguridad y en la que conceptos tan comunes hoy en día, tales como los firewalls o protocolos de cifrado eran desconocidos... Por ello para realizar la comunicación entre un punto y otro se enviaban las credenciales de acceso en texto plano... ¿Eso qué implica? Que si alguna persona maliciosa se pusiese en medio e interceptase el tráfico entre ambos puntos, podría leer directamente la contraseña sin tener que recurrir a ninguna herramienta especial, ya que aparecerían las credenciales en un texto plano perfectamente legible...

Por ello más adelante se ideó otro protocolo de comunicación. el cual es muy popular en entornos Linux, denominado ssh, que no solo tiene más potencia que su antecesor, sino que además toda la comunicación realizada a través de este protocolo va cifrada, dificultando cualquier tipo de robo por parte del atacante...

Probablemente alguno piense que este tipo de robo de credenciales de una comunicación telnet es dificultosa o que solo cuatro "geeks" se molestarían en hacer dicha intercepción, pero la verdad es que es tan sencillo como ponerse en el medio de ambos puntos, lo cual se puede lograr haciendo un man in the middle que se puede lograr con multitud de herramientas y sin poseer conocimientos de redes.

Imaginemos que nos encontramos entre ambos puntos... Únicamente usando una herramienta como wireshark, podríamos obtener el resultado y ni siquiera es necesario "romper" nada... Imaginemos que tenemos un equipo entre ambos puntos "escuchando" toda la comunicación entre un punto A y un punto B... Simplemente habría que dejar en marcha wireshark hasta que llegase alguna comunicación TELNET, tas lo cual se podría detener la "escucha" de wireshark para analizar mejor el tráfico... Con el tráfico captura presente únicamente habría que escribir en la sección filter, la expresión telnet:

filtro-telnet

Esto haría que de toda la marabunta de paquetes que teníamos presentes, solo se mostrasen aquellos que se hubiesen transmitido mediante el protocolo telnet, ahorrándonos buscar uno por uno dentro de la lista de paquetes. Ahora solamente habría que realizar click derecho en uno de los paquetes y seleccionar la opción Follow TCP Stream:

follow-tcp

Esto haría un seguimiento de la comunicación TCP realizada entre ambos puntos. Como la información mostrada es referente a la comunicación entre ambos puntos, lo ideal suele ser mostrar la traza enviada desde el punto desde que se realiza la conexión de telnet, al destino, eso significaría que habría que cambiar la opción del menú desplegable de Entire Conversation a formato ip_origen telnet --> ip_destino_telnet, mostrando un resultado como el siguiente:

resultado-captura

Como podéis ver no hay ningún carácter raro... El texto es mostrado sin más, siendo altamente peligroso utilizar este tipo de comunicación a menos que te conectes con el dispositivo de destino directamente...

Es por ello que es altamente recomendable evitar cualquier uso de este protocolo para evitar posibles disgustos y que se opten por comunicaciones ssh en caso de ser posible.

Saludos.

domingo, 19 de julio de 2015

Cómo configurar y usar clamAV.

Hoy vengo a hablaros sobre una de las facetas más infravaloradas en el mundo de Linux; los antivirus. Probablemente más de uno se ría al ver este post, pero lo cierto es que los virus también existen en Linux, aunque sean en mucha menor medida que en Windows... Es por ello que aunque todos sabemos que los antivirus no son infalibles, es recomendable tener uno instalado en nuestro equipo, tenga el sistema que tenga. En Windows existen multitud de opciones, las cuales no voy a comentar en esta ocasión; en Linux en cambio, aunque existen también varias opciones (menores que en Windows, pero sigue habiendo la posibilidad de elegir) existe una opción que se ha ganado una fama mucho mayor que resto. Se trata de ClamAV.

clamav_portada
Imagen de clamAV.net

ClamAV podría ser considerado como EL antivirus de Linux por excelencia, que aunque en un principio está diseñado para funcionar únicamente por consola, también tiene la posibilidad de instalar una interfaz gráfica para todo aquel que desee olvidarse de la consola. El software en sí no está incluido por defecto en nuestro sistema operativo, pero afortunadamente sí que está incluido en nuestros repositorios con lo que lo único que haría falta hacer sería escribir:

  1. apt-get install clamav clamav-daemon

Con el antivirus instalado ya podríamos disfrutar de las funcionalidades de éste, si bien como bien he dicho antes, es necesario conocer algunos comandos para poder "defendernos" en este entorno. El primer comando es muy importante aunque es subestimado por muchas personas, se trata del comando freshclam.


  1. freshclam

El comando es muy sencillo y simplemente realiza una actualización manual de la base de datos de clamav. En caso de no hacer nada, la base de datos se actualizaría automáticamente cada hora, pero nunca está de más tener este comando presente, pues a veces la conexión a Internet puede fallar o simplemente tenemos que hacer una actualización de emergencia. Con dicha base asimilada ya podríamos pasar a lo más importante, que sería el escaneo y la eliminación de viruses. 

Comencemos con el escaneo puro. Esta es una función básica que todo antivirus incluye, que se trata de que simplemente busca posibles archivos que contengan viruses, pero sin eliminarlos, ya que perfectamente puede ser un "falso positivo". Además es muy recomendable que, en caso de ser posible, se escriba el comando con privilegios de sudo, ya que en caso contrario no podrá escanear nada más allá de la carpeta home. Todo esto se logra usando la siguiente estructura:

sudo clamscan -r ${ruta}

Por ejemplo, si deseasemos escanear nuestra carpeta personal habría que escribir:
  1. sudo clamscan -r /home/ivan
Mientras que para para hacer un escaneo de todo el sistema sería:
  1. sudo clamscan -r /

Todo dependería de la ruta que escogiésemos pero el concepto es el mismo. Para un escaneo de absolutamente todo el sistema sería una buena idea hacerlo como root con el fin de escanear todos los recovecos sin falta. Imaginemos que hemos encontrado algún virus y queremos eliminarlo, la manera de eliminar dicho virus de forma automática sería usando el mismo comando que antes, con el parámetro añadido --remove, teniendo la siguiente estructura:

sudo clamscan -r --remove ${ruta}

Es decir que para los dos casos anteriores habría que aplicar el cambio de la siguiente forma:

Carpeta personal:
  1. sudo clamscan -r --remove  /home/ivan
Todo el sistema:
  1. sudo clamscan -r --remove  /

Uno de los "peros" que tienen estos escaneos y acciones que toman un tiempo más que considerable por parte del sistema para que se finalicen; especialmente cuando hablamos de carpetas o particiones grandes. Es por ello que durante la instalación he incluido el paquete servicio clamav-daemon. Este servicio posee las mismas funcionalidades que el clamav original, con la diferencia de que al tener ya este servicio corriendo en segundo plano y al estar usando un usuario creado especialmente para este servicio, los tiempos de escaneo y borrado de viruses es mucho menor. Aún así, es importante tener presente que el usuario creado por este servicio, llamado clamav, debe de ser incluido dentro de algún grupo con permisos especiales o dentro del grupo "sudoers", si queremos sacarle el máximo partida a la herramienta, pues en caso contrario el servicio no tendrá permisos para acceder a muchos directorios y/o ficheros. Una virtud que posee este servicio es que sus comandos de escaneo son los mismos que los de clamav con la diferencia de que en vez de usar el comando clamscan se usa clamdscan. Eso conlleva que si queremos usar el servicio para realizar el escaneo, los comando serían (en base a lo anterior):

  1. sudo clamdscan -r  /home/ivan
  2. sudo clamdscan -r  /
  3. sudo clamdscan -r --remove  /home/ivan
  4. sudo clamdscan -r --remove  /

También tenemos la posibilidad de usar esta utilidad mediante una interfaz gráfica. Para ello se necesitaría un entorno de escritorio instalado (KDE, Gnome, XFCE...) y una aplicación que debería instalarse además de los paquetes anteriores llamada clamtk. El proceso de instalación de esta aplicación sería tan sencillo como el de los anteriores, pues al igual que el resto está incluido en los repositorios. El comando para instalar el software sería:

  1. apt-get install clamtk

El aspecto de esta aplicación puede variar dependiendo de la versión de sistema operativo que usemos o el entorno de escritorio, pero la imagen de a continuación sería una muestra de lo que obtendríamos mediante la instalación de esta herramienta. Esta imagen en concreto pertenecería a clamtk instalado en un entorno Debian8 con KDE.


antivirus_grafico

Obviamente, en caso de tener un entorno gráfico es muy recomendable aprovechar esta utilidad. Aún así, esto no siempre es posible y por ello siempre es bueno tener presentes los comandos básicos del sistema.

Saludos.

viernes, 17 de julio de 2015

Mini guía de buenas prácticas con Android

Si alguien nos preguntase qué sistema operativo es el más usado dentro del mundo de las tablets y la telefonía móvil, a todos nos vendría a la cabeza un sólo nombre: Android. Para bien o para mal, android forma parte de nuestras vidas, pero muchas personas no son conscientes (especialmente con los móviles) que lo que llevan encima no son nada más ni nada menos que ordenadores de bolsillo y al igual que cuidamos (o deberíamos cuidar) nuestros ordenadores, también debemos de cuidar nuestros móviles; bien para que no se deterioren o bien para que no nos llevemos posibles sustos. Este sistema operativo es un mundo, pero aún así en este post voy a intentar explicaros de forma breve y concisa las pautas que uno debería seguir para tener un móvil "sano" y duradero en forma de lista.
Portada-android

  1. Mantén tu móvil actualizado: Esto parece una tontería, pero muchísima gente usa aplicaciones desactualizadas o peor aún, sistemas operativos desactualizados que contienen graves fallas de seguridad. El hecho de mantener el sistema android actualizado depende de que los fabricantes liberen actualizaciones, pero aún así es importante estar al tanto de este datos, pues un sistema desactualizado es un sistema vulnerable.
  2. Nunca permitir aplicaciones de Orígenes desconocidos: Los mercados "libres" tales como Black Market, o las aplicaciones de Android que se descargan desde una página web en vez de desde el market oficial suelen ser inseguras y suelen contener virus; dar permiso a este tipo de orígenes, dejamos altamente expuesto nuestro móvil a viruses.
  3. No os fiéis de todo lo que aparece en el Play Store: Muchas gente se piensa que por bajarse las aplicaciones desde el mercado oficial de Android no corren riesgo de infección de virús, cuando en realidad no es así, ya que existen muchas aplicaciones fraudulentas que intentan hacerse pasar por otras para así infectar tu móvil. También hay aplicaciones que piden demasiados permisos o que fingen hacer una cosa cuando luego hacen otra... Debido a que el market actual prima la cantidad de aplicaciones sobre la calidad, son muchísimas las aplicaciones fraudulentas que hay en el mercado, con lo que hay que tener muchísimo cuidado. Una forma muy eficiente de saber si una aplicación es fraudulenta o no es mirar qué desarrollador y/o empresa ha subido la aplicación en cuestión... No es lo mismo que aparezca WhatsApp Inc como desarrolador que Andrés; con lo que es muy recomendable fijarse en este detalle.
  4. Instalar un antivirus en el móvil: Al igual que usamos antivirus en nuestro ordenador; ¿Por qué no usar uno en el móvil? He de admitir que éstos no son infalibles, pero sería una locura no tener uno instalado para protegernos de posibles amenazas.
  5. Instalar un limpiador en el móvil: ¿Cuantas aplicaciones instalamos y desinstalamos? ¿Borramos el historial al finalizar nuestra navegación? Al igual que se suelen tener limpiadore en los PCs, el hecho de tener un limpiador en el móvil no solo nos liberará espacio sino que también limpiará cualquier información delicada almacenada en los historiales y/o otras aplicaciones.
  6. Quitar aplicaciones corriendo en segundo plano: Cuando uno se sale de una aplicación no es consciente que ésta no se cierra sino que sigue corriendo en segundo plano, consumiendo batería, recursos... Es por ello que siempre es bueno mantener el móvil "limpio" de ese tipo de procesos.
  7. Evitar tener el móvil siempre encendido: La adicción a los móviles ha hecho que mucha gente duerma con el móvil pegado a la cama y encendido... Al igual que no es bueno tener un ordenador todo el día encendido, tampoco es bueno los dispositivos encendidos... Todo elemento electrónico encendido genera calor cuando está encendido, y tenerlo todo el rato encendido puede generar sobrecalentamientos y deterioro de elementos de hardware, reduciendo la vida útil de nuestro elemento. Aquellos que usen el móvil como despertador han de saber que la mayoría de los móviles modernos siguen siendo capaces de ejercer de despertador aún estando apagados, pues éstos generan la alarma a la hora indicada igualmente.
  8. Evitar tener el móvil cargando toda la noche: Aunque la mayoría de las baterías modernas están protegidas contra sobrecargas, el móvil sigue estando recibiendo energía lo cual genera calor y puede deteriorar nuestros componentes.
  9. NO rootear el móvil: Rootear un móvil ofrece la posibilidad de usar aplicaciones que por lo general sería imposible usar, pero también facilita la elevación de privilegios a los atacantes... Es por ello que, a menos que sea realmente necesario, se recomienda no rootear el móvil. Además el hecho de rootearlo haría que el móvil perdiese la garantía a menos que se quitase dicho rooteo.
  10. Desactivar el uso de datos en zonas con poca o nula cobertura: Cada vez que recuperamos la cobertura, en caso de tener el uso de datos activado el dispositivo se conectará a la red de datos del operador de telefonía, lo cual implica que el móvil tenga que realizar un pequeño "esfuerzo" para lograrlo. Dicho esfuerzo es mínimo, pero el estar en zonas con mala cobertura implica que el móvil esté conectando y desconectandose constantemente, malgastando la batería en vano.
Obviamente existen más prácticas que uno puede considerar indispensables, pero creo que esta pequeña lista engloba lo esencial.

Espero que os resulte útil.

Saludos.

Cómo ofuscar el código de un script bash

Hasta ahora hemos visto los distintos usos a los que se le puede dar a bash. Desde un sencillo firewall hasta las diferentes formas de sacarle el máximo partido. Pero imaginemos que dicho script tiene que ser entregado a otro usuario; un usuario que casualmente tiene permisos de root en su equipo, y como tal puede hacer lo que quiera el contenido de dicho script... Esto a veces no es importante, pues a veces los cambios que el otro usuario quiere introducir puede suponer una mejora, pero otras veces puede perfectamente ser código malicioso o código que podría "romper" el script que nosotros habíamos creado. Es por ello que a veces es necesario recurrir a herramientas que dificulten la lectura y modificación del contenido del script... Una de ellas se trata de una herramienta que personalmente he encontrado muy útil: shc.

Portada-ofuscación

En este caso hablamos de un software que no podemos obtener desde los repositorios oficiales, sino que se trata de un software de terceros que ha sido compartido en la famosa plataforma github. Dicho software es sorprendentemente fácil de configurar y usar; solamente es necesario descargarse dicho software en el link que os muestro a continuación:

https://github.com/existz/shc-3.8.9

El fichero está disponible para ser bajado en "bruto" mediante git o en formato zip. En este caso optaremos por el método más universal y escogeremos la segunda opción, si bien la primera es perfectamente válida. La primera tarea que deberíamos afrontar para hacer uso de esta herramienta sería la descompresión del fichero en cuestión, que se puede realizar directamente clickando en el archivo (en caso de tener entorno gráfico) o mediante el uso del comando unzip:

  1. unzip shc-3.8.9-master.zip

Esto nos descomprimiría el archivo y nos dejaría un directorio con el nombre shc-3.8.9-master  al cual habría que acceder para poder seguir adelante. Estando presentes en dicho directorio, muchas personas acostumbradas a lidiar con paquetes de este tipo suelen tender a hacer uso de los comandos relacionados con gcc, tales como make o configure; pero en este caso el proceso es mucho más sencillo... Simplemente habría que copiar el binario shc al directorio bin y darle permisos de ejecución de la siguiente forma:

  1. cp shc /bin
  2. chmod +x /bin/shc

Dicha copia nos ha permitido poder disfrutar de la herramienta de ofuscación de código sin recurrir a ningún tipo de instalación adicional o a compilación alguna... Ahora únicamente faltaría darle uso al programa en cuestión, uso de lo más sencillo pues consta de únicamente tres parámetros que se podrían calificar como importantes:

  • -f --> El parámetro indispensable en esta aplicación, cualquier uso del comando -f debe de concluir con el parámetro -f más el nombre del fichero que se desee ofuscar, cualquier intento de ofuscación sin este parámetro será fallido.
  • -e --> Opcionalmente es posible dar una fecha de expiración al código ofuscado. Esto viene bien para ocasiones en las que uno desee que el script que se vaya a entregar a alguien posea una fecha de caducidad. Si el script supera la fecha de caducidad establecida, éste quedará inutilizable. El formato de la fecha establecida siempre será: día/mes/año.
  • -m --> Este parámetro es directamente dependiente del anterior (-e), pues no es ni más ni menos que el mensaje que se mostraría en pantalla en caso de que algún usuario quisiese ejecutar el script caducado.
Ahora que tenemos las bases de este programa, podemos aplicarlos a la práctica. Supongamos que tenemos un programa llamado bashtest.sh con el siguiente código:


  1. #!/bin/bash
  2. cadena="hola esto es una prueba de shc"

Un código simple y perfectamente legible... Ahora es el turno de ofuscar el contenido de éste para que nadie pueda leerlo... Por ejemplo, vamos a hacer que el script bashtest.sh esté ofuscado hasta el día 17 de Julio del 2016 y que cuando caduque muestre el mensaje "Script caducado" a todo aquel que intente ejecutarlo:

  1. shc -e 17/07/2016 -m "Script caducado" -f bashtest.sh

Simple y sencillo... A los pocos tiempo de su ejecución (el tiempo varía dependiendo del tamaño del script) el proceso finalizará y creará dos archivos. Uno con la extensión .x y otro con la extensión .x.c.  El primero de estos dos contiene el código ofuscado, el cual puede ser ejecutado sin problemas, si bien es recomendable eliminarle la extensión .x con el fin de no dar información innecesaria al usuario final... El segundo es un fichero en escrito en c que hace referencia al fichero ofuscado; Dicho fichero no nos es útil y puede ser eliminado sin problema alguno...

En caso de consultar el contenido de nuestro nuevo fichero, veríamos un galimatías parecido a éste:

bash-ofuscado

Como veis las virtudes que ofrece esta herramienta no son nada desdeñables y puede ser un recurso muy a tener en cuenta en determinadas ocasiones.

Saludos.

martes, 14 de julio de 2015

Firefox bloquea Flash player.

Flash, ese gran complemento tan amado y odiado por muchos, lleva una temporada considerable recibiendo un golpe tras otro por parte de las grandes empresas.... Bien justificados son dichos golpes a sabiendas que un dicha herramienta está plagada de vulnerabilidades aún sin resolver, vulnerabilidades críticas que han creado una enorme catástrofe para la compañía Hacking Team, que ha supuesto el robo de 400GB de información sensible de dicha compañía. Vulnerabilidad que ha supuesto la gota que colma el vaso para muchos individuos.

icono_flash

Tal es la cantidad de agujeros de seguridad encontrados, que Facebook se ha pronunciado al respecto, criticando duramente a este complemento y preguntando su fecha de "muerte"... Como si el las criticas de esta compañía no fuesen suficientes, Firefox también se ha visto obligada propinar otro golpe a Flash con el fin de proteger a todos aquellos usuarios que usan Firefox. Ya llevaban tiempo anunciando su desconfianza en este complemento, pero este incidente les ha obligado a tomar medidas drásticas que ya han sido aplicadas desde ayer día 13 de Julio. Medidas que podéis apreciar en el siguiente listado de addons bloqueados:

https://addons.mozilla.org/es/firefox/blocked/

Además de dicho listado publicado ayer, los propios responsables de Firefox han anunciado dicho bloqueo en sus respectivas redes sociales; si bien han aclarado que dicha medida se trata de algo temporal que se han visto obligados a adoptar hasta Flash aplique los parches de seguridad pertinentes. 

Nadie parece que vaya a romper una lanza a favor de Flash y Facebook ha manifestado claramente que esta puede ser la "oportunidad" que la gente necesitaba para migrar finalmente a HTML5, migración que siempre se ha pospuesto debido a que Flash estaba ahí como alternativa tradicional, aún cuando ya se ha demostrado que dicha migración es inevitable... ¿Será éste el preludio a la muerte de Flash? ¿Supondrá este el salto definitivo a HTML5? Mucho se ha esperado para realizar dicho salto... ¿Ttal vez sea éste el empujón que la comunidad necesitaba para realizarlo? 

Lo más probable es que obtengamos dichas respuestas muy pronto.

Saludos.