Building REST APIs for hacking tools

What is this post about?

In this post I will talk about how to create REST APIs for hacking tools in 5 minutes.

What is the real problem?

The problem that I present to you today solves several small problems. I expose them as questions:

  • Had you have problems auditing remote services lacking a proxy machine?
  • Do you need to allow access to only specifics commands in a system?
  • Moreover: do you need to delegate access to these commands, or ONLY to certain parameters of the command?
  • Wouldn’t be great to be able to perform a security analysis by calling curl or wget?

Well, a lot of us had this problems. For this reason in the BBVA-Labs department we have been working on a pretty cool toy.

Check out our BBVA-Labs projects

The idea is very simple:

Given a command line script, you can create a REST API in minutes.

We gave this project the name of Kapow! and my colleagues chose a pretty cool logo 🙂

Although the project is still in beta, you can download and use it. We think that the idea is powerful and exciting (and that’s why I’m writing this post :D)

Download Kapow! from Github

Create an API for nmap in 5 minutes

How does it works in one image

Kapow actually does the magic of creating the REST API, given a command:

Defining the API

For Kapow to know how to create the API it needs to create a .pow file with the instructions. Do not be scared, it’s very simple:

# nmap.pow

kapow route add -X GET '/scan/{ip}' -c 'nmap -sL $(request /matches/ip) | response /body'

Let’s analyze the file. You’ll see it’s very simple:

  1. We create a new API with a path: /scan/{ip}, where IP is the target to analyze established as an input parameter.
  2. -c ‘nmap…’: is the way we tells Kapow! the command to run.
  3. $(request /matches/ip): this is the way we tells Kapow! that from the received request, we want to use the variable “ip”.
  4. response /body: this is the way we tells Kapow! how to return the result of execution as HTTP

Building Kapow!

Since the project is still beta, we will need to build Kapow! ourselves. You scare us. It’s easy.

At first we clone the repository:

> git clone -b develop https://github.com/BBVA/kapow.git
> cd poc/

Be careful when making the clone. The branch to clone is the develop !!

First of all we will need to add a line to the original Dockerfile, which is located in the /poc/Dockerfile directory. We need to add nmap for installation.

The resulting Dockerfile should look like this:

FROM python:3.7-alpine

COPY Pipfile Pipfile.lock /tmp/

COPY bin/* /usr/bin/

WORKDIR /tmp

RUN apk upgrade --update-cache;                 \
    apk add                                     \
        bash                                    \
        curl                                    \
        coreutils                               \
        nmap                                    \
        file;                                   \
                                                \
    pip install pipenv;                         \
                                                \
    pipenv install --system --deploy;

ENTRYPOINT ["/usr/bin/kapow"]

Finally we will build the image of Kapow! with the Dockerfile that we just modified:

> docker build -t kapow .

Running the API

Once we have built our Docker image, we need our nmap.pow file we created earlier and launch Kapow:

> ls
nmap.pow
> docker run -p 8080:8080 -it -v "$(pwd)/":/tmp kapow server /tmp/nmap/nmap.pow
======== Running on http://0.0.0.0:8080 ========
(Press CTRL+C to quit)
Route created GET /list/{ip}
ROUTE_545919aa_9b5e_452c_bc92_002061aa5003
bash-4.4#

What we have done:

  1. Put our service listening at port 8080.
  2. Since the Docker image has not included the nmap.pow file, we need to “mount” it from the host, with the -v command. The first $(pwd) parameter tells Docker mount the current directory in the /tmp directory inside the Docker container.
  3. We run the server with the server command
  4. We indicate Kapow! the definition file which we assembled from outside the Docker container.

Testing the API

Now we’ll try our API. In this case we will use Curl to launch a scan against our loopback: 127.0.0.1

> curl -v http://localhost:8080/scan/127.0.0.1
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 8080 (#0)
> GET /list/127.0.0.1 HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Length: 168
< Content-Type: application/octet-stream
< Date: Fri, 21 Jun 2019 13:35:48 GMT
< Server: Python/3.7 aiohttp/3.5.4
<
Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-21 13:35 UTC
Nmap scan report for localhost (127.0.0.1)
Nmap done: 1 IP address (0 hosts up) scanned in 0.00 seconds
* Connection #0 to host localhost left intact

Conclusions

Although we are aware that the project is at an early stage, the potential it has is enormous.

Imagine performing an entire security audit with a Postman. It sounds great, right?

Finally, I would like to leave you with a question:

What do you think about the idea of Kapow! and what use cases do you think of?

Crear APIs REST para herramientas de hacking

De qué va este post?

En este post hablaré sobre cómo crear APIs REST para herramientas de hacking y cómo lograr hacerlo en 5 minutos.

Pero, cuál es el problema realmente?

El problema que hoy os presento trata de resolver varios pequeños problemas. Os los planteo como preguntas:

  • Nunca habéis tenido que analizar un entorno en el que era muy complicado tener acceso a una máquina de salto?
  • Necesitáis dejar acceso a solamente cierto comandos en un sistema en concreto?
  • Más aún: necesitáis delegar el acceso a un comando, permitiendo SOLO ciertos parámetros del comando?
  • No sería genial poder hacer una auditoría haciendo llamando a curl o wget?

Pues este problema lo hemos tenido muchos. Precisamente por este motivo, en mi departamento de BBVA-Labs hemos estado trabajando en un juguete bastante chulo.

Echa un vistazo a los proyectos de BBVA-Labs

La idea es muy simple:

Dado script de linea de comandos, poder crear una API REST en cuestión de minutos.

A este proyecto le dimos el nombre de Kapow! y mis compañeros escogieron un logo bastante chulo 🙂

Si bien el proyecto todavía está en beta ya es usable. La idea del proyecto siempre me ha parecido muy potente y emocionante (y por eso estoy escribiendo este post :D)

Echa un vistazo al Github de Kapow!

Crear una API para nmap en 5 minutos

Funcionamiento en 1 imagen

Para que quede claro el concepto, los que realmente hace Kapow! es la magia de crear la API REST, dado un comando:

Definir la API

Para que Kapow! sepa cómo tiene que crear la API, tendremos que crear un fichero .pow con las instrucciones. No os asustéis, es muy sencillo:

# nmap.pow

kapow route add -X GET '/scan/{ip}' -c 'nmap -sL $(request /matches/ip) | response /body'

Analicemos el fichero. Veis que es muy sencillo:

  1. Creamos una nueva API con una ruta: /scan/{ip}, dónde IP es el target a analizar, establecido como parámetro de entrada.
  2. -c ‘nmap…’: de esta manera le indicamos a Kapow! el comando a ejecutar.
  3. $(request /matches/ip): así es como le decimos a Kapow! que, de la petición recibida, queremos utilizar la variable “ip” pasada como parámetro en la API.
  4. response /body: así es como le decimos a Kapow! que devuelva el resultado de la ejecución del comando en la respuesta HTTP.

Construcción de Kapow!

Dado que el proyecto todavía está beta, tendremos que construir Kapow! nosotros mismos. Nos os asustéis. Es muy fácil.

En primer lugar clonaremos el repositorio:

> git clone -b develop https://github.com/BBVA/kapow.git
> cd poc/

Cuidado al hacer el clone. La rama a clonar es la develop!!

En primer lugar tendremos que añadir una linea al Dockerfile original, que se encuentra en directorio /poc/Dockerfile. Lo que necesitamos añadir es la instalación del nmap.

El Dockerfile resultante debe de quedarnos así:

FROM python:3.7-alpine

COPY Pipfile Pipfile.lock /tmp/

COPY bin/* /usr/bin/

WORKDIR /tmp

RUN apk upgrade --update-cache;                 \
    apk add                                     \
        bash                                    \
        curl                                    \
        coreutils                               \
        nmap                                    \
        file;                                   \
                                                \
    pip install pipenv;                         \
                                                \
    pipenv install --system --deploy;

ENTRYPOINT ["/usr/bin/kapow"]

Finalmente construiremos la imagen de Kapow! con el Dockerfile que hemos modificado:

> docker build -t kapow .

Ejecutar la API

Una vez construido nuestra imagen Docker, ya solo necesitamos tener a mano el fichero nmap.pow que creamos más arriba y lanzar Kapow:

> ls
nmap.pow
> docker run -p 8080:8080 -it -v "$(pwd)/":/tmp kapow server /tmp/nmap/nmap.pow
======== Running on http://0.0.0.0:8080 ========
(Press CTRL+C to quit)
Route created GET /list/{ip}
ROUTE_545919aa_9b5e_452c_bc92_002061aa5003
bash-4.4#

Qué hemos hecho:

  1. Ponemos a escuchar nuestro servicio en el puerto 8080.
  2. Puesto que la imagen de Docker no tiene incluido dentro el fichero de nmap.pow, lo hemos “montado” desde fuera, con el comando -v. El primer parámetro $(pwd), le indica a Docker que monte el directorio actual en el directorio /tmp de dentro de contenedor de Docker.
  3. Ejecutamos el servidor con el comando server
  4. Le indicamos la ubicación de nuestro fichero de definición de Kapow! que, recordar, lo montamos desde fuera del contenedor de Docker.

Probar la API

Ahora ya solo queda probar nuestra API. En este caso vamos a usar Curl para lanzar un escaneo contra nuestro loopback: 127.0.0.1

> curl -v http://localhost:8080/scan/127.0.0.1
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 8080 (#0)
> GET /list/127.0.0.1 HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Length: 168
< Content-Type: application/octet-stream
< Date: Fri, 21 Jun 2019 13:35:48 GMT
< Server: Python/3.7 aiohttp/3.5.4
<
Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-21 13:35 UTC
Nmap scan report for localhost (127.0.0.1)
Nmap done: 1 IP address (0 hosts up) scanned in 0.00 seconds
* Connection #0 to host localhost left intact

Conclusiones

Aunque somos conscientes de que el proyecto está en una fase temprana, el potencial que tiene es enorme.

Imaginaros poder realizar toda una auditoria con un Postman. No se a vosotros, pero a mi me parece espectacular.

Finalmente, me gustaría dejaros una pregunta abierta:

¿Qué os parece la idea de Kapow! y qué casos de uso se os ocurren?

Hasta la próxima!

Python: Thread, concurrency and advanced tips

De qué va este post?

Explicación sencilla de cómo maneja Python el paralelismo, la concurrencia y los hilos.

Python y su inexistente paralelismo

Supongo que todos sabéis que son los hilos, verdad? Es un concepto multi-lenguaje de programación. Python, como no podía ser menos también nos permite usar hilos… O no?

Pero… Cómo que NO, si Python tiene la librería threading que nos permite crear hilos?

Efectivamente, la librería existe. Pero, es una de las grandes “mentirijillas” de Python 🙂

Por qué Python nos “miente”, qué le he hecho yo?

A modo de culturilla:

Cuando Guido van Rossum (creador de Python) ideó y diseño Python, tenía muy clara una cosa: tenía que ser muy simple. No solo el lenguaje, también el intérprete.

Con esta idea en la cabeza, creó el intérprete sin soporte para hilos. Pero, con los años, los años los programadores reclamaban más y más el soporte de hilos.

Pero claro, la inclusión de hilos suponía complicar el intérprete. Y mucho. Pero… por qué? Porque el paralelismo tiene, ente otros muchos problemas a solucionar:

  • Sincronización
  • Condiciones de carrera
  • Interbloqueos
  • Fugas de memoria

Python y los falsos “hilos”

Pese a todo, los programadores seguían reclamando hilos. Así que lo solucionaron de la siguiente manera:

  • Crearon el GIL (Global Python Interpreter).
  • Crearon una librería que permitía al programador usar un API para la creación y gestión hilos.

Vale… y es esto qué es? 🙂

El GIL

Como ya hemos comentado, la inclusión de hilos supone mucho esfuerzo y complicación del intérprete. El GIL lo que hace es SIMULAR la ejecución de hilos. Es decir:

  • Python crea 1 proceso y 1 hilo por defecto. Cualquier programa que hagamos, se ejecutará en este contexto.
  • Si creamos más hilos Python y el GIL lo que harán será ir cambiando la ejecución de cada hilo en el procesador. De tal manera que SOLO se ejecuta un hilo a la vez. Es decir, que lograremos concurrencia pero NO paralelismo, como nos dice la intuición.

Vaya KK, verdad? 🙂 la verdad es que cuando te enteras de esto la primera vez, te quedas bastante decepcionado. Al menos yo me quedé pensando: pero qué tipo de lenguaje de mi***da es esta?!?! 🙂

Tened cuenta lo que os comentaba más arriba: Python fue creado para ser simple. En todos los aspectos. Esto no tiene que ser necesariamente malo, todo depende de lo que necesitemos. Por ejemplo, no se me ocurrirá escribir un sistema operativo o sistema el control de un misil en Python 🙂

A pesar del GIL, en general, con Python podremos hacer la mayor parte de cosas que se nos pasen por la cabeza, no preocuparse 🙂

Sobreviviendo al GIL

 

Python: hilos, concurrencia y algunos temas avanzados

De qué va este post?

Explicación sencilla de cómo maneja Python el paralelismo, la concurrencia y los hilos.

Python y su inexistente paralelismo

Supongo que todos sabéis que son los hilos, verdad? Es un concepto multi-lenguaje de programación. Python, como no podía ser menos también nos permite usar hilos… O no?

Pero… Cómo que NO, si Python tiene la librería threading que nos permite crear hilos?

Efectivamente, la librería existe. Pero, es una de las grandes “mentirijillas” de Python 🙂

Por qué Python nos “miente”, qué le he hecho yo?

A modo de culturilla:

Cuando Guido van Rossum (creador de Python) ideó y diseño Python, tenía muy clara una cosa: tenía que ser muy simple. No solo el lenguaje, también el intérprete.

Con esta idea en la cabeza, creó el intérprete sin soporte para hilos. Pero, con los años, los años los programadores reclamaban más y más el soporte de hilos.

Pero claro, la inclusión de hilos suponía complicar el intérprete. Y mucho. Pero… por qué? Porque el paralelismo tiene, ente otros muchos problemas a solucionar:

  • Sincronización
  • Condiciones de carrera
  • Interbloqueos
  • Fugas de memoria

Python y los falsos “hilos”

Pese a todo, los programadores seguían reclamando hilos. Así que lo solucionaron de la siguiente manera:

  • Crearon el GIL (Global Python Interpreter).
  • Crearon una librería que permitía al programador usar un API para la creación y gestión hilos.

Vale… y es esto qué es? 🙂

El GIL

Como ya hemos comentado, la inclusión de hilos supone mucho esfuerzo y complicación del intérprete. El GIL lo que hace es SIMULAR la ejecución de hilos. Es decir:

  • Python crea 1 proceso y 1 hilo por defecto. Cualquier programa que hagamos, se ejecutará en este contexto.
  • Si creamos más hilos Python y el GIL lo que harán será ir cambiando la ejecución de cada hilo en el procesador. De tal manera que SOLO se ejecuta un hilo a la vez. Es decir, que lograremos concurrencia pero NO paralelismo, como nos dice la intuición.

Vaya KK, verdad? 🙂 la verdad es que cuando te enteras de esto la primera vez, te quedas bastante decepcionado. Al menos yo me quedé pensando: pero qué tipo de lenguaje de mi***da es esta?!?! 🙂

Tened cuenta lo que os comentaba más arriba: Python fue creado para ser simple. En todos los aspectos. Esto no tiene que ser necesariamente malo, todo depende de lo que necesitemos. Por ejemplo, no se me ocurrirá escribir un sistema operativo o sistema el control de un misil en Python 🙂

A pesar del GIL, en general, con Python podremos hacer la mayor parte de cosas que se nos pasen por la cabeza, no preocuparse 🙂

Sobreviviendo al GIL

 

Confundiendo a los malos

De qué va este post?

En este post vamos a ver cómo cambiando 3 líneas de nuestro servidor web podemos confundir a un atacante.

Por qué puedo querer confundir a un atacante?

Bueno, tal vez estéis muy orgullos de vuestro Apache, Tomcat, Nginx o cualquier otro, pero… No deja de ser un software. Y por definición, el software puede tener fallos.

A pesar, incluso, de tener parcheado y bien configurado vuestro servidor, **es imposible conocer todos los ataques, y más aquellos que no son públicos** y que a los que podríamos ser vulnerables.

Ante esta situación no podemos hacer nada, tan solo tratar de mitigar o prevenir. Por eso os propongo una idea algo diferente: Engañemos a aquellos que nos traten de atacar.

Cómo engañamos a un atacante?

Existen muchísimas formas de hacerlo, pero hoy vamos a ver solo una pincelada. Nuestro objetivo es es el siguiente:
Cuando una atacante se conecte a nuestro servidor web, le haremos pensar que es un servidor diferente al que realmente tenemos instalado

Es decir: cambiaremos el banner de nuestro servidor web por otro.

¿Qué tonto verdad? Sí, lo es, pero veréis que efectivo resulta.

Cómo lo hacemos?

En el caso que nos aplica lo vamos a ver con el **servidor web Nginx**, por ser mi preferido, pero podéis trasladar el concepto a cualquier otro. Manos a la obra!

En primer lugar instalamos el paquete *nginx-extras*:

> sudo apt-get install nginx-extras

Añadimos al fichero de configuración del nginx lo siguiente:

http {
...
server_tokens off;
server_name_in_redirect off;
more_set_headers 'Server: Microsoft-IIS/8.5';
...

Qué hemos hecho?

He hemos dicho al servidor web que nos sustituya la cabecera HTTP que devuelve al usuario, por la que le hemos indicado.

Ahora un matiz muy importante: ¿qué valor deberíamos de poner ahí?

No hay nada exacto, pero mi recomendación es que si queréis engañar a un “malo” creéis una mentira plausible. Es decir: que cuando éste analice vuestro servidor, la mentira sea creíble.

Y ¿cómo la hacemos creíble? Fácil!

Probablemente cualquier atacante lo primero que use para identificar nuestros sistemas sea el nmap, verdad? Luego, si logramos engañar a nmap, es bastante probable que engañemos al “malo”.

Cómo nos identifica nmap?

Contrariamente a lo que pueda parecer, es muy fácil engañar al nmap.

Si bien es cierto que la parte de red es algo más compleja, no es así en la identificación de los servicios que hay abiertos detrás de cada puerto, donde la identificación la hace, en su mayoría, con unas simples REGEX (expresiones regulares).

Nmap tiene una base de datos con dichas expresiones. Lo único que tendremos que hacer será que nuestro banner haga válida una de dichas expresiones en el puerto 80 o 443, verdad? A que ahora parece más fácil? 🙂

Si os fijáis bien, el banner que elegí arriba coincide con una de las expresiones de la base de datos del nmap:

(5070) match http m|^HTTP/1\.1 400 .*\r\nServer: Microsoft-IIS/(\d[-.\w]+)\r\n| p/Microso ft IIS httpd/ v/$1/ o/Windows/ cpe:/a:microsoft:iis:$1/ cpe:/o:microsoft:windows/a

En la versión 7.01 del Nmap, esta expresión está en la linea 5070.

Podéis encontrar el fichero en:

  • MAC: /opt/local/share/nmap/nmap-service-probes
  • Kali Linux: /opt/share/nmap/nmap-service-probes

Demostración

No se vosotros, pero yo no me creo nada que no pueda comprobar 🙂 y, en este caso, comprobarlo es muy sencillo. Un simple nmap al puerto de nuestro server y…

Conclusiones

Como ultimas palabras comentar varias cosas:

  • Este tipo de técnicas se llaman técnicas anti-fingerprinting.
  • Aunque en este ejemplo hemos usado nmap, os invito a que uséis Nessus, OpenVas o similares. Veréis como las pruebas las orienta al servidor que habéis indicado, por lo que las prueba no obtendrán resultados coherentes.

Os iré contando más técnicas sencillas de anti-fingerprinting. Veréis como no es tan complicado engañar a los malos 🙂

Chau!

Confusing the bad guys

De qué va este post?

En este post vamos a ver cómo cambiando 3 líneas de nuestro servidor web podemos confundir a un atacante.

Por qué puedo querer confundir a un atacante?

Bueno, tal vez estéis muy orgullos de vuestro Apache, Tomcat, Nginx o cualquier otro, pero… No deja de ser un software. Y por definición, el software puede tener fallos.

A pesar, incluso, de tener parcheado y bien configurado vuestro servidor, **es imposible conocer todos los ataques, y más aquellos que no son públicos** y que a los que podríamos ser vulnerables.

Ante esta situación no podemos hacer nada, tan solo tratar de mitigar o prevenir. Por eso os propongo una idea algo diferente: Engañemos a aquellos que nos traten de atacar.

Cómo engañamos a un atacante?

Existen muchísimas formas de hacerlo, pero hoy vamos a ver solo una pincelada. Nuestro objetivo es es el siguiente:
Cuando una atacante se conecte a nuestro servidor web, le haremos pensar que es un servidor diferente al que realmente tenemos instalado

Es decir: cambiaremos el banner de nuestro servidor web por otro.

¿Qué tonto verdad? Sí, lo es, pero veréis que efectivo resulta.

Cómo lo hacemos?

En el caso que nos aplica lo vamos a ver con el **servidor web Nginx**, por ser mi preferido, pero podéis trasladar el concepto a cualquier otro. Manos a la obra!

En primer lugar instalamos el paquete *nginx-extras*:

> sudo apt-get install nginx-extras

Añadimos al fichero de configuración del nginx lo siguiente:

http {
...
server_tokens off;
server_name_in_redirect off;
more_set_headers 'Server: Microsoft-IIS/8.5';
...

Qué hemos hecho?

He hemos dicho al servidor web que nos sustituya la cabecera HTTP que devuelve al usuario, por la que le hemos indicado.

Ahora un matiz muy importante: ¿qué valor deberíamos de poner ahí?

No hay nada exacto, pero mi recomendación es que si queréis engañar a un “malo” creéis una mentira plausible. Es decir: que cuando éste analice vuestro servidor, la mentira sea creíble.

Y ¿cómo la hacemos creíble? Fácil!

Probablemente cualquier atacante lo primero que use para identificar nuestros sistemas sea el nmap, verdad? Luego, si logramos engañar a nmap, es bastante probable que engañemos al “malo”.

Cómo nos identifica nmap?

Contrariamente a lo que pueda parecer, es muy fácil engañar al nmap.

Si bien es cierto que la parte de red es algo más compleja, no es así en la identificación de los servicios que hay abiertos detrás de cada puerto, donde la identificación la hace, en su mayoría, con unas simples REGEX (expresiones regulares).

Nmap tiene una base de datos con dichas expresiones. Lo único que tendremos que hacer será que nuestro banner haga válida una de dichas expresiones en el puerto 80 o 443, verdad? A que ahora parece más fácil? 🙂

Si os fijáis bien, el banner que elegí arriba coincide con una de las expresiones de la base de datos del nmap:

(5070) match http m|^HTTP/1\.1 400 .*\r\nServer: Microsoft-IIS/(\d[-.\w]+)\r\n| p/Microso ft IIS httpd/ v/$1/ o/Windows/ cpe:/a:microsoft:iis:$1/ cpe:/o:microsoft:windows/a

En la versión 7.01 del Nmap, esta expresión está en la linea 5070.

Podéis encontrar el fichero en:

  • MAC: /opt/local/share/nmap/nmap-service-probes
  • Kali Linux: /opt/share/nmap/nmap-service-probes

Demostración

No se vosotros, pero yo no me creo nada que no pueda comprobar 🙂 y, en este caso, comprobarlo es muy sencillo. Un simple nmap al puerto de nuestro server y…

Conclusiones

Como ultimas palabras comentar varias cosas:

  • Este tipo de técnicas se llaman técnicas anti-fingerprinting.
  • Aunque en este ejemplo hemos usado nmap, os invito a que uséis Nessus, OpenVas o similares. Veréis como las pruebas las orienta al servidor que habéis indicado, por lo que las prueba no obtendrán resultados coherentes.

Os iré contando más técnicas sencillas de anti-fingerprinting. Veréis como no es tan complicado engañar a los malos 🙂

Chau!

Applied social engineering – Summary rules Dale Carnegie

Hoy he vuelto a impartir la charla “Ingeniería social aplicada – Mucho más fácil de lo que parece” en Google Campus Madrid.

Tras dar esta charla varias veces me ha llama la atención el que haya suscitado más interés que otras charlas anteriores mucho más técnicas y con mucho más trabajo técnico a sus espaldas. Bueno, supongo que la conclusión es sencilla: es un tema fácilmente entendible por todos y muy vistoso.

Quería usar este post para dejar una referencia a la presentación, Que podéis encontrar aquí, y daros el listado completo del resumen que me hice en su día del libro de Dale Carnigie del que hablo en la charla.

Tal y como he comentado, estas reglas hay que tomarlas con cuidado y no usarlas al pie de la letra, ya que muchas de ellas son de dudosa ética, rozando incluso el maltrato psicológico (o, al menos, así lo veo yo).

Resumen de las reglas de Dale Carnigie

Técnicas fundamentales para tratar con el prójimo

  • REGLA 1: No critique, no condene, ni se queje.
  • REGLA 2: Demuestre aprecio honrado y sincero.
  • REGLA 3: Despierte en los demás un deseo vehemente.

Seis maneras de agradar a los demás

  • REGLA 4: Interésese sinceramente por los demás.
  • REGLA 5: Sonría.
  • REGLA 6: Recuerde que para toda persona, su nombre es el sonido más dulce e importante en cualquier idioma.
  • REGLA 7: Sea un buen oyente. Anime a los demás a que hablen de sí mismos.
  • REGLA 8: Hable siempre de lo que interese a los demás.
  • REGLA 9: Haga que la otra persona se sienta importante y hágalo sinceramente.

Logre que los demás piensen como usted

  • REGLA 10: La única forma de salir ganando en una discusión es evitándola.
  • REGLA 11: Demuestre respeto por las opiniones ajenas. Jamás diga a una persona que está equivocada.
  • REGLA 12: Si usted está equivocado, admítalo rápida y enfáticamente.
  • REGLA 13: Empiece en forma amigable.
  • REGLA 14: Consiga que la otra persona diga “Sí, sí”, inmediatamente.
  • REGLA 15: Permita que la otra persona sea quien hable más.
  • REGLA 16: Permita que la otra persona sienta que la idea es de ella.
  • REGLA 17: Trate honradamente de ver las cosas desde el punto de vista de la otra persona. REGLA 9: Muestre simpatía por las ideas y deseos de la otra persona.
  • REGLA 18: Apele a los motivos más nobles.
  • REGLA 19: Dramatice sus ideas.
  • REGLA 20: Lance, con tacto, un reto amable.

Sea un líder

  • REGLA 21: Empiece con elogio y aprecio sincero.
  • REGLA 22: Llame la atención sobre los errores de los demás indirectamente.
  • REGLA 23: Hable de sus propios errores antes de criticar los de los demás.
  • REGLA 24: Haga preguntas en vez de dar órdenes.
  • REGLA 25: Permita que la otra persona salve su propio prestigio.
  • REGLA 26: Elogie el más pequeño progreso y, además, cada progreso. Sea “caluroso en su aprobación y generoso en sus elogios”.
  • REGLA 27: Atribuya a la otra persona una buena reputación para que se interese en mantenerla.
  • REGLA 28: Aliente a la otra persona. Haga que los errores parezcan fáciles de corregir. REGLA 9: Procure que la otra persona se sienta satisfecha de hacer lo que usted sugiere.
  • REGLA 29: Procure que la otra persona se sienta satisfecha de hacer lo que usted sugiere.

Ingeniería social aplicada – Resumen reglas Dale Carnegie

Hoy he vuelto a impartir la charla “Ingeniería social aplicada – Mucho más fácil de lo que parece” en Google Campus Madrid.

Tras dar esta charla varias veces me ha llama la atención el que haya suscitado más interés que otras charlas anteriores mucho más técnicas y con mucho más trabajo técnico a sus espaldas. Bueno, supongo que la conclusión es sencilla: es un tema fácilmente entendible por todos y muy vistoso.

Quería usar este post para dejar una referencia a la presentación, Que podéis encontrar aquí, y daros el listado completo del resumen que me hice en su día del libro de Dale Carnigie del que hablo en la charla.

Tal y como he comentado, estas reglas hay que tomarlas con cuidado y no usarlas al pie de la letra, ya que muchas de ellas son de dudosa ética, rozando incluso el maltrato psicológico (o, al menos, así lo veo yo).

Resumen de las reglas de Dale Carnigie

Técnicas fundamentales para tratar con el prójimo

  • REGLA 1: No critique, no condene, ni se queje.
  • REGLA 2: Demuestre aprecio honrado y sincero.
  • REGLA 3: Despierte en los demás un deseo vehemente.

Seis maneras de agradar a los demás

  • REGLA 4: Interésese sinceramente por los demás.
  • REGLA 5: Sonría.
  • REGLA 6: Recuerde que para toda persona, su nombre es el sonido más dulce e importante en cualquier idioma.
  • REGLA 7: Sea un buen oyente. Anime a los demás a que hablen de sí mismos.
  • REGLA 8: Hable siempre de lo que interese a los demás.
  • REGLA 9: Haga que la otra persona se sienta importante y hágalo sinceramente.

Logre que los demás piensen como usted

  • REGLA 10: La única forma de salir ganando en una discusión es evitándola.
  • REGLA 11: Demuestre respeto por las opiniones ajenas. Jamás diga a una persona que está equivocada.
  • REGLA 12: Si usted está equivocado, admítalo rápida y enfáticamente.
  • REGLA 13: Empiece en forma amigable.
  • REGLA 14: Consiga que la otra persona diga “Sí, sí”, inmediatamente.
  • REGLA 15: Permita que la otra persona sea quien hable más.
  • REGLA 16: Permita que la otra persona sienta que la idea es de ella.
  • REGLA 17: Trate honradamente de ver las cosas desde el punto de vista de la otra persona. REGLA 9: Muestre simpatía por las ideas y deseos de la otra persona.
  • REGLA 18: Apele a los motivos más nobles.
  • REGLA 19: Dramatice sus ideas.
  • REGLA 20: Lance, con tacto, un reto amable.

Sea un líder

  • REGLA 21: Empiece con elogio y aprecio sincero.
  • REGLA 22: Llame la atención sobre los errores de los demás indirectamente.
  • REGLA 23: Hable de sus propios errores antes de criticar los de los demás.
  • REGLA 24: Haga preguntas en vez de dar órdenes.
  • REGLA 25: Permita que la otra persona salve su propio prestigio.
  • REGLA 26: Elogie el más pequeño progreso y, además, cada progreso. Sea “caluroso en su aprobación y generoso en sus elogios”.
  • REGLA 27: Atribuya a la otra persona una buena reputación para que se interese en mantenerla.
  • REGLA 28: Aliente a la otra persona. Haga que los errores parezcan fáciles de corregir. REGLA 9: Procure que la otra persona se sienta satisfecha de hacer lo que usted sugiere.
  • REGLA 29: Procure que la otra persona se sienta satisfecha de hacer lo que usted sugiere.