LATEST ARTICLES

noviembre 29th 2017

Qué significa realmente ‘hacker’

Número de lecturas: 340
{lang: 'es-419'}

El arte de ser hacker

Uno de los libros que más me han llamado la atención sobre este tema es sin lugar a dudas Hacking: The Art of Exploitation, de Jon Erickson. Es una joya para todo aquel que quiera sumergirse en este mundo de los verdaderos hackers. Y tal como está en el libro, me permitiré tomar la primer pregunta que explotó mi mente al momento de leerlo.  

La esencia de un hacker

Usando cada uno de los siguientes números 1,3,4 y 6 exactamente una vez con cualquiera de las operaciones básicas (sumar,restar,multiplicar,dividir) conseguir un total de 24. Cada número debe ser usado solo una vez y el orden depende de ustedes. Por ejemplo:

3 * ( 4 + 6 ) + 1 = 31

Correcto en sintaxis, pero incorrecto en resultado.

Debo admitir que yo no pude resolver el problema hasta que terminé de leer el libro y vi la solución en la última página. Pero básicamente esta es la esencia de un hacker, poder ver lo que otros no ven.

Los primeros hackers

Un grupo de estudiantes del MIT (Massachusetts Institute of Technology), cerca de los años 50, recibió un donativo de equipos telefónicos, con estas piezas, ellos desarrollaron un sistema que permitía gestionar la línea de comunicación a distancia por medio de llamadas especiales. Ellos hicieron un descubrimiento usando la tecnología que ya existía, pero usándola de formas que pocos o nadie habían visto hasta entonces. Estos fueron los primeros hackers.

Una comunidad de respaldo

Hoy en día existen muchos exámenes de “certificación” para convertirse en “hacker”, pero la realidad es que uno no llegará a ser un verdadero hacker hasta que un miembro de la comunidad que ya lo sea esté de acuerdo en llamarnos por ese calificativo. Uno de los caminos para esto es poder aportar algo útil a la comunidad. Muchos hackers son en última instancia programadores de bajo nivel, puesto que conocen de manera profunda cómo funcionan los equipos, a nivel de memoria y sistema operativo; bits en última instancia.

Este conocimiento les permite encontrar vulnerabilidades

Esto es como cuando aprendemos por primera vez matemáticas, cuando eramos niños, necesitabamos de alguien que nos explique y enseñe los símbolos y las formas, y esto sucede en cierta manera con los programadores también, un verdadero hacker es aquel que conoce estos símbolos y formas, y nos señala cuando ve que hemos fallado al usarlos (una vulnerabilidad). Y como el mismo Linus Torvalds (otro gran hacker, en el sentido real de la palabra) las “vulnerabilidades” son solamente bugs. Con esto refiriéndose a que no son más que errores de programación, aunque tal vez con otro tipo de consecuencias a los bugs más comunes.

Los hackers NO necesariamente son delincuentes

Esto es cierto hasta cierto punto, vamos a pensarlo por un momento. Cuando un verdadero hacker desea conocer algo, este pone a prueba hasta el más mínimo detalle del sistema, con todos sus conocimientos le es posible esquivar, o evitar controles de acceso, o modificar órdenes para realizar otras tareas, o incluso convertir el programa en otra cosa. Pero ¿de dónde nace esto?

Motivaciones de un hacker

Estas pueden ir en un gran abanico de posibilidades, algunos (la mayoría de los verdaderos hackers) descubren lo que descubren por un mero placer intelectual, disfrutan el desafío de encontrar estos ‘vacíos’. Otros lo hacen por ego, puesto que desean poder decir que son los mejores en algo. Pero es innegable que alguno o muchos de ellos también estarán ahí por el dinero, puesto que controlar cosas que son incontrolables para la mayoría de personas es ciertamente una herramienta que puede producir mucho dinero. Es este el motivo por el que podemos decir que los hackers no necesariamente son malos, pero ojo con el necesariamente.

Otro motivo importante es que los hackers reales desconfían de la tecnología que usamos todos. Esto es así porque en su conocimiento profundo de sistemas, conocen las limitaciones y vacíos o vulnerabilidades. Es este conocimiento en última instancia el que les permite “sobrepasar” sistemas para poder cumplir con alguna de sus otras motivaciones (intelectual,económica,etc).

3 tipos de hacker hoy en día

Hoy por hoy podemos encontrar 3 conocidos grupos de hackers, distinguidos de manera curiosa por el tipo de sombrero que usan: white, black grey hat. En pocas palabras y con una analogía que ya hemos tocado con anterioridad, encontramos que los blancos son los buenos, los negros son los malos y los grises están en un punto medio en el que usan sus habilidades para ser o buenos o malos, dependiendo de la situación. Pero hay un último término, mucho más utilizado en círculos de hackers reales.

Script-kiddie

¿Qué es un script-kiddie? Como su nombre lo dice, es un “niño” a la vista de los verdaderos hackers que solo usa scripts para su beneficio. Y aquí hay que hacer una distinción muy grande,

Estar certificado en seguridad informática NO te hace necesariamente un hacker.

Y este es un punto de vista personal, así como un hacker  puede no tener certificaciones y seguir siendo un gran hacker. Pero vamos a ver por qué digo esto. Muchos exámenes de certificación/cursos/etc te enseñan los pasos de un pentesting exitoso, te enseñan la teoría de tipos de vulnerabilidad, te introducen en el mundo de la seguridad informática como si fueras versado en el tema. Pero la realidad es que hasta que no hagas un aporte sustancial a la comunidad hacker, esto quiere decir, hasta que no crees una herramienta que demuestre ser útil para los hackers, no eres uno. Así de simple y sencillo.

No importa qué tan bien puedas usar nmap, o zen, o incluso metasploit, mientras no seas capaz de aportar un exploit real, o una herramienta de reconocimiento real, NO eres un hacker, solo un script-kiddie, y no importa que tengas N certificaciones en seguridad, eso no lo va a cambiar.

Los hackers hacen de este un mundo mejor

Gracias a ellos es que tenemos tecnología en continuo movimiento. El kernel es un gran ejemplo de esto, son cientos de mentes muy versadas en el tema, que crean código que sirve no solo a la comunidad hacker, sino a todo el mundo. Pero no solo esto, si no fuera por ellos, la tecnología se estancaría en puntos donde la gente no querría seguir desarrollando, esto porque al encontrar vulnerabilidades, los hackers ayudan a motivar a los desarrolladores a escribir mejor código, y a su vez, este mejor código motiva a los hackers a demostrar que son aún mejores, generando un círculo virtuoso en el medio.

Reflexión final

Bueno, ya voy a cortar, así sin más, porque he visto que me estoy extendiendo y aunque me gustaría explicar un poco sobre cómo encontrar un exploit, eso tendrá que ser para otra ocasión. Yo personalmente me considero un ‘script-kiddie’ todavía, puesto que si bien he encontrado una que otra vulnerabilidad por ahí e incluso he podido asignar CVEs a estas, todavía no he creado mi propio exploit o herramienta para poner a disposición de la comunidad, pero espero que eso cambie en poco tiempo ? Sin más que agregar, muchas gracias por su tiempo, saludos.

Fuente:

blog.desdelinux.net

noviembre 27th 2017

Renombrar varios archivos a la vez, en lote, desde consola (linux)

Número de lecturas: 435
{lang: 'es-419'}

Muchas veces tenemos un montón de ficheros y queremos modificar en lote su nombre de archivo por alguna circunstancia, añadir texto, suprimir texto, reemplazar algún carácter por otro… y nos llevaría mucho tiempo ir editando uno a uno cuando lo que queremos es hacer la misma edición para todos. Para ello podemos renombrar todos los archivos en lote, todos a la vez, usando desde una consola Linux el comando rename (*ver pie) con expresiones regulares que nos permitan reemplazar lo que necesitemos. Mostraremos características, algunos ejemplos y la explicación de expresiones regulares para usar con rename:

Características:

Parámetros del comando rename:
-v (Verbose: modo detallado, nos saca en pantalla lo que se va haciendo en el proceso)
-n (No Action: no realiza la acción, solo nos muestra lo que haría, es importante poner este parámetro junto con -v la primera vez que ejecutamos para comprobar que el resultado que vamos a obtener es el que queremos)
-f (Force: sobrescribe los ficheros existentes)
*.* para que trate todos los archivos con extensión del directorio
\ Localiza caracteres especiales tipo [ , {, (, -, _, “.”, …

 

Ejemplos:

1) Añadir algo tras una parte del nombre del archivo que es común en todos los ficheros.
Ejemplo:
imagenXXXX.jpg por imagen_NEW_XXXX.jpg

# rename 's/imagen/imagen_NEW_/' *.jpg -v-n

2) Renombrar un grupo de imágenes con nombres diferentes. Si tenemos un grupo de imágenes (por ejemplo PNG) a las que les queremos añadir una información en la parte final del nombre de la imagen antes de la extensión.
Ejemplo:
nombreimagen.png por nombreimagen_150x150.png

# rename 's/\.png/\_150x150.png/' *.png -v -n

3) Vamos a suponer que queremos reemplazar los guiones bajos por guiones medios (“_” por “-“) en los nombres de nuestros archivos de un directorio determinado.

# rename 's/_/-/' *.jpg -v -n

Podemos ejecutar repetidamente por si hay varios guiones bajos en el nombre del archivo o utilizar expresiones regulares de repetición tipo {m} {n}… * Ver más abajo la referencia de expresiones regulares

4) Añadir texto al inicio del nombre del fichero. Con el carácter ^ le indicamos al comando rename que se sitúe en el comienzo del nombre del fichero y ahí inserte o ejecute la segunda parte.
Ejemplo:
leccion 1.doc,
leccion 2.doc
por
tema – leccion 1.doc,
tema – leccion 2.doc …

# rename 's/^/tema – /' *.doc -v -n

5) Si queremos eliminar varios caracteres antes de un punto de corte determinado.
Ejemplo:
texto1_abc_001_small.jpg,
texto2_abc_002_small.jpg,
texto3_abc_003_small.jpg
por
texto1_small.jpg,
texto2_small.jpg,
texto3_small.jpg

Utilizamos para el corte la cadena “_small” y le decimos que nos elimine los 8 caracteres (\w) anteriores, o los reemplace por lo que indiquemos en la segunda parte del comando rename.

# rename 's/\w{8}\_small/_small/' *.jpg -v -n

5b) Si queremos reemplazar desde un punto determinado de corte, pero respetando un número concreto de caracteres numéricos antes de la parte donde se produce el corte. Para este caso usamos el elemento “$1” en la cadena de la parte derecha, para que nos coja esa variable obtenida de la parte izquierda.  Viendo el ejemplo se entenderá mejor.
Ejemplo:
texto1_uno001_small.jpg,
texto2_otro002_small.jpg,
texto3_cualquiera003_small.jpg …
por
texto1_uno_ADD-001_small.jpg,
texto2_otro_ADD-002_small.jpg,
texto3_cualquiera_ADD-003_small.jpg …

Utilizamos para el corte la cadena “_small” y le decimos que nos guarde los 3 caracteres numéricos (\d) anteriores (001, 002, 003…) utilizando el $1 en la segunda parte del comando (la expresión de la derecha) Nos añadirá o modificara lo indicado en la segunda parte del comando rename justo antes de esos 3 caracteres reservados antes del corte.

# rename 's/(\w{3})\_small/_ADD–$1_small/' *.jpg -v -n

6) Cambiar mayúsculas y minúsculas.
Ejemplo:
mi_fichero.txt por MI_FICHERO.TXT

# rename 'y/a-z/A-Z/' *.txt -v -n

7) Eliminar del nombre del fichero caracteres especiales que no están entre la letra a y la z (a-z) . Dejando en el nombre del fichero solo caracteres alfanuméricos.
Ejemplo:
mi-fichero.txt por mifichero.txt

# rename 'v/[^a-z]//' *.* -v -n

Para cambiar varios caracteres lo ejecutamos varias veces:
Ejemplo:
mi-fichero-con-varios-caracteres.txt por mificheroconvarioscaracteres.txt
Lo ejecutaremos 4 veces.

 

Expresiones regulares:

A continuación dejo un listado explicando (en inglés) las expresiones regulares que se pueden utilizar con este comando rename:

^ matches the beginning of the line
$ matches the end of the line
. Matches any single character
(character)* match arbitrarily many occurences of (character)
(character)? Match 0 or 1 instance of (character)
[abcdef] Match any character enclosed in [] (in this instance, a b c d e or f) ranges of characters such as [a-z] are permitted. The behaviour of this deserves more description.
[^abcdef] Match any character NOT enclosed in [] (in this instance, any character other than a b c d e or f)
(character){m,n} Match m-n repetitions of (character)
(character){m,} Match m or more repetitions of (character)
(character){,n} Match n or less (possibly 0) repetitions of (character)
(character){n} Match exactly n repetitions of (character)
(expression) Group operator.
\n Backreference – matches nth group
expression1|expression2 Matches expression1 or expression 2. Works with GNU sed, but this feature might not work with other forms of sed.
\w matches any single character classified as a “word” character (alphanumeric or “_”)
\W matches any non-“word” character
\s matches any whitespace character (space, tab, newline)
\S matches any non-whitespace character
\d matches any digit character, equiv. to [0-9]
\D matches any non-digit character

 

* Please note that the rename command is part of the util-linux package and can be installed on a Debian or Ubuntu Linux, using the following syntax:

$ sudo apt-get install renameutils

Fuente:
bonaval.com

noviembre 24th 2017

¿Qué es y para que sirve un sandbox en la informática?

Número de lecturas: 162
{lang: 'es-419'}

A continuación veremos una explicación simple para que todo el mundo pueda comprender lo que es un sandbox en el mundo de la informática.

¿QUÉ ES UN SANDBOX?

Un sandbox es un mecanismo de seguridad para disponer de un entorno aislado del resto del sistema operativo.

Todos los programas que se ejecutan dentro de un sandbox lo hacen de forma controlada mediante los siguientes aspectos:

  1. Se les asigna un espacio en disco. Estos programas no podrán acceder a ningún espacio del disco que no les haya sido asignado previamente.
  2. Podemos hacer que nuestros programas se ejecuten en un sistema de archivos temporal (tmpfs) para aislarlos del resto del sistema operativo.
  3. También se les asigna un espacio en memoria. Los programas no podrán acceder a otras partes de la memoria que no les hayan sido asignadas.
  4. Les podemos dar o restringir la capacidad para acceder y consultar dispositivos de almacenamiento externos.
  5. Les restringimos la capacidad para que puedan inspeccionar la máquina anfitrión.
  6. Podemos restringir el acceso de los programas a la red, al servidor de las X, al servidor de sonido, etc.
  7. Podemos limitar el ancho de banda que usa un determinado programa.
  8. Etc.

Consecuentemente podemos afirmar que los programas se ejecutan en un entorno controlado y separado del sistema operativo. Por lo tanto el hecho de ejecutar un programa en un sandbox es un ejemplo específico de virtualización.

¿QUÉ UTILIDAD TIENE UN SANDBOX?

Nos podemos hacer la idea que su principal utilidad es ejecutar programas de forma segura y sin peligro de comprometer el resto del sistema operativo.

Algunos ejemplos de los casos en que podemos utilizar un sandbox son los siguientes:

  1. Instalar y usar de forma segura programas que no son fiables y/o pueden contener virus y/o código malicioso.
  2. Usar programas que tienen el potencial de comprometer la seguridad de nuestro sistema operativo como por ejemplo un navegador web, Skype, un lector de pdf, un keygen descargado de Internet, etc.
  3. Crear un entorno de pruebas para ejecutar programas o un código que acabamos de crear.
  4. Para descargar Torrents.
  5. Etc.

Por lo tanto podemos ver que un sandbox no es de uso exclusivo para programadores o expertos informáticos. También es útil para todo tipo de usuarios.

Algunos de los navegadores web que usamos disponen de su propio sandbox. No obstante no es mala idea usar dos capas de protección porque los navegadores web son altamente susceptibles de sufrir problemas de seguridad.

¿CÓMO PODEMOS USAR UN SANDBOX?

En función del sistema operativo que usemos existen diferentes software que nos permitirán ejecutar programas dentro de un sandbox. Algunos ejemplos son los siguientes:

  1. GNU-Linux: Firejail, Glimpse.
  2. Windows: Sandboxie, Shadow Defender.

Fuente:

geekland.eu

 

noviembre 19th 2017

Manejo de ramas de desarrollo con git

Número de lecturas: 242
{lang: 'es-419'}

Git es un sistema de control de revisiones distribuido amparado por la GPLv2 que enfatiza sobre todo la velocidad. Fue diseñado y desarrollado inicialmente por Linus Torvalds, creador de Linux como proyecto para mantener repositorios del kernel de Linux.

Cada directorio de trabajo git es un repositorio completamente funcional y con total capacidad independientemente de si existe acceso a la red y de un servidor centralizado, lo cual lo convierte en una poderosa herramienta tanto para el desarrollo de grupos de trabajo como para el desarrollo individual.

Git dispone de muchas características pero hoy voy a hablaros del manejo de ramas de desarrollo con git. Si estáis familiarizados con Github sabréis que la base de dicha red social de desarrollo es el “fork“ de ramas de desarrollo y su posterior “merge“. Git es treméndamente eficiente en ese aspecto.

Git Branching

El manejo de ramas o branching es la parte más atractiva y divertida de trabajar con Git. Cuando inicializamos o clonamos un repositorio, siempre obtenemos una rama principal por defecto llamada master a no ser que especifiquemos lo contrario.

Cambiando de rama

Supongamos que estamos trabajando en un proyecto y queremos añadir nueva funcionalidad al mismo. La forma adecuada de hacerlo con Git es crear una nueva rama con el nombre de la nueva funcionalidad donde añadiremos nuestros cambios y después cambiaremos a ella (git branch switching).

$ git branch nuevafuncionalidad
$ git checkout nuevafuncionalidad

Existe un atajo para crear una rama que aún no existe usando directamente el comando checkout que consiste en pasar el parámetro -b en la llamada.

$ git checkout -b nuevafuncionalidad

Una vez creada nuestra nueva rama de desarrollo, podemos comprobar en que rama nos encontramos utilizando el comando git branch

$ git branch
master
* nuevafuncionalidad

En el ejemplo anterior podemos ver como nos encontramos en la rama nuevafuncionalidad. Esto significa que si modificamos, borramos o añadimos archivos, ésta incluirá esos cambios pero no así la rama master. Supongamos que hemos añadido la nueva funcionalidad y hemos modificado un par de archivos. Vamos a hacer un commit.

$ git commit -a -m 'añadida nueva funcionalidad chula chula de la ostia'
Created commit: a6b18c4: añadida nueva funcionalidad chula chula de la ostia
  2 files changed, 6 insertions(+), 0 deletions (-)

Ahora tenemos que hacer un cambio en un archivo de la rama master para arreglar un bug que nos han reportado la gente que está testeando esa rama y debemos corregirlo de manera inmediata para que puedan seguir con su trabajo. Podemos volver a la rama master y añadir allí los cambios sin preocuparnos de posibles inconsistencias con nuestra nueva rama nuevafuncionalidad

$ git checkout master
$ git commit -a -m 'arreglado el bug #00002345'
Created commit b89ae56: arreglado el bug #00002345
 1 files changed, 1 insertions(+), 1 deletions(-)

Ahora podemos ver las diferencias entre nuestras dos ramas usando el comando diff.

git diff --stat master nuevafuncionalidad
deliverance.py                      |      4 ++--
lib/nuevafuncionalidad.py           |      4 ++++
lib/test/test_nuevafuncionalidad.py |      4 ++++
3 files changed, 7 insertions(+), 2 deletions(-)

Además podemos crear un parche para aplicar uno al otro pero lo que realmente querremos hacer es mezclar ambas ramas, lo que se conoce como un branch merging

Mezclando Ramas

Hemos testeado profundamente nuestra nueva funcionalidad y estamos listos para moverla de la rama nuevafuncionalidad a la rama principal master. Dicha acción requiere que mezclemos el contenido de una de las ramas dentro de la otra, esto es lo que en Github llaman “Solicitud de Pull“ (realmente en Github lo que se hace es un git rebase pero esa funcionalidad la trataremos otro día).

Para realizar la mezcla de la rama nuevafuncionalidad dentro de master vamos a situarnos en la rama mater y a mezclar ambas:

$ git checkout master
$ git merge nuevafuncionalidad

Como veis esto es cualquier cosa menos traumática, realmente es muy sencillo mezclar ramas en Git. Una vez hemos mezclado nuestras ramas, y en caso de que no haya conflictos, podemos eliminar la rama nuevafuncionalidad por que no vamos a necesitarla más.

$ git branch -d nuevafuncionalidad

Resolviendo conflictos

¿Qué pasa si editamos el mismo archivo en ambas ramas y sobre las mismas líneas?. Pues que se generará un conflicto que tendremos que resolver a mano por que Git aunque es útil y potente, no tiene la capacidad de decidir que versión del código en conflicto es la correcta.

Imagina que hemos modificado el archivo deliverance.py en ambas ramas en las mismas líneas. Git generará un conflicto a la hora de la mezcla y siguiendo su política de no intrusión nos solicitará resolver el conflicto de manera manual.

$ git merge otrarama
Auto-merged deliverance.py
CONFLICT (content): Merge conflict in deliverance.py
Automatic merge failed; fix conflcits and then commit the result.

Como se puede apreciar, Git nos ofrece toda la información relevante para solucionar el conflicto y realizar un nuevo commit. El archivo problemático en este caso es deliverance.py.

    def send_delivery_request(request):
        self._server.request = request
< <<<<<< HEAD:deliverance.py
        self._rtime = 6000
===
        self._rtime = get_time_to_live(request)
>>>>>>> otrarama:deliverance.py
        # Send the request to the service
        self._server.send(self._rtime)

Podemos ver como hay un conflicto entre una y otra versión, mientras que en la rama principal se utiliza un valor hardcoded como tiempo máximo de respuesta, en el código de la rama otrarama se utiliza una función que devuelve un valor en base al request. Debemos de solucionar el problema y realizar un nuevo commit.

    def send_delivery_request(request):
        self._server.request = request
        self._rtime = get_time_to_live(request)
        # Send the request to the service
        self._server.send(self._rtime)
$ git add deliverance.py
$ git commit -m 'solucionando conflictos'
Created commit 17c688a: solucionando conflicto

Deshacer un Merge

En ocasiones veo muertos… no en serio. En ocasiones, querremos deshacer un merge por que la habremos cagado nosotros o otra gente de nuestro equipo de mala manera y encontraremos muchos conflictos a la hora de intentar seguir mezclando ramas o de trabajar normalmente. En esas ocasiones querremos deshacer de forma total el entuerto.

Git viene al rescate con el comando reset. Para hacer un reset de nuestro directorio de trabajo y volver atrás hasta antes de intentar mezclar las ramas, solamente debemos de ejecutar a nuestro buen amigo git reset.

$ git reset --hard HEAD

El parámetro --hard se asegura de que tanto nuestro índice de archivos como el directorio de trabajo cambien para que coincidan con lo que era antes del merge. Por defecto solo se restablece el índice, dejando los archivos parcialmente mezclados en el directorio de trabajo.

Si por casualidad has hecho un cambio y después de hacer un commit has decidido que era un error por que tus tests unitarios han empezado a romperse en mil pedazos (por ejemplo), aun puedes ir atrás y deshacer ese commit usando también reset.

$ git reset --head ORIG_HEAD

Esto es solo útil si lo que quieres es deshacer solo el último cambio. Si lo que quieres es deshacer un commit anterior a ese, entonces debes utilizar la herramienta revert que es un poco peligrosa y se aleja bastante del cometido de este post.

Conclusión

Git nos ofrece una forma sencilla de trabajar con ramas de desarrollo en nuestros proyectos. Y esto es solo la punta del Iceberg, Git nos ofrece otras funcionalidades como el stashing o el rebase de las que hablaremos en próximos artículos. Hasta entonces, ¡saludos y buen code merging!

Más Información | git revert, git rebase

Fuente:

genbeta.com