Mensajes

y eso en que pieza física se almacenaría por curiosidad es que nunca había oído hablar de uno así

Saludos

En la partición MBR dentro del disco duro donde resida tu sistema operativo. La partición MBR almacena los sectores donde se situa el arranque del sistema operativo. En UEFI esta tabla se llama GPT y es parecidísima, con la expcepción de que se verifica la firma digital del bootloader.

Saludos.

[LetsEncrypt]

Muy buenas a todos, sé que hace tiempo que no entro al foro pero sigo leyendo todo cada día desde modo invitado.

Hoy os traigo lo mejor de lo mejor, hace algo más de una semana, LetsEncrypt, una iniciativa de la EFF (Electronic Frontier Foundation), anunció su nueva herramienta la cual promueve el uso e instalación de certificados de forma gratuita. Bueno, ya en las charlas de mi git hablé de ello, pero todavía estaban en pañales y bueno ahora está en beta.

Haré una breve introducción del porque es una gran iniciativa que realmente está orientando el control de internet hacia nosotros, los usuarios, ya que la privacidad ahora está de nuestra parte.

INTRODUCCIÓN:

HTTPS se basa en la utilización de PKI + SSL/TLS. A través de estos estándares podemos garantizar la integridad, confiabilidad y la autenticidad de la conexión pertinente, gracias a la criptografía de clave pública y a los certificados X509v3. No os quiero aburrir con tecnicismos, podeís pedirme si quereis un tutorial extendido sobre criptografía asimétrica, TLS, PKI y certificados.

Cuando uno se conecta a una Web mediante HTTPS se realiza una negociación de claves para establecer una conexión segura, uno de los pasos de esta negociación tiene que ver con el certificado. Éste sólo es válido si ha sido firmado por una entidad certificadora (CA), y estas entidades obviamente cobran por certificado emitido, y sí, son cantidad muchas veces desorbitadas.

Gracias a la iniciativa LetsEncrypt podemos obtener un certificado de manera gratuita. ¿Pero, el certificado ya será válido? Sí, al 100%, puesto que el mismo es firmado por una CA de confianza (IdenTrust CA). ¿Y no pierden dinero las otras CA (competencia)? Sí, pero dar este paso era fundamental para retomar el control sobre nuestra privacidad.

Resumiendo, lo que quiero que entendaís es que podeís proteger el tráfico de vuestras Webs personales de ataques Man-In-The-Middle (MITM) sin gastar vuestro dinero en certificados costosos que para colmo hay que pagar por cada renovación del mismo. Esto supone una gran patada al gran hermano amigos.

INSTALACIÓN

Primero, remarcar que la herramienta sólo es empleable por ahora en GNU/Linux, preveen portarla pronto a Windows, pero como bien dije todavía están en Beta.

Para los interesados estoy utilizando CentOs. Abrid vuestra terminal, situaros en el directorio que queraís, descargadla mediante el cliente de git de la siguiente forma y acto seguido corred el cliente letsencrypt-auto para que instale las dependencias auxiliares necesarias (OJO: necesitareís permisos de root):

$ git clone https://github.com/letsencrypt/letsencrypt
$ cd letsencrypt
$ ./letsencrypt-auto

Si no podeis correr el cliente letsencrypt-auto probad a ejecutarlo de la siguiente forma:

$ ./letsencrypt-auto --debug (esto sucede con versiones de Python obsoletas/antiguas.)

USO DE LA HERRAMIENTA

Aquí os explicare el método manual, el cual consiste en generar un par de claves pública/privada además del CSR. El CSR (Certificate Signing Request) es el archivo que contiene la información de nuestra entidad, dominios a proteger, algoritmos de firma digital y nuestra clave pública, que será enviado mediante el cliente de LetsEncrypt a su entidad certificadora (CA) para que nos lo firme y nos devuelva un certificado SSL/TLS.

Existen métodos automatizados que facilitan la obtención del certificado sin tanto rodeo, interesados -> https://letsencrypt.org/howitworks/

Os aviso de antemano que encontrareís MUY POCA info del método manual, todo lo que os voy a explicar a continuación es una recopilación de mi esfuerzo y horas invertidas en este proceso.

Primero generamos nuestro par de claves pública/privada junto al CSR, todo a la vez. En este comando incluiremos la información personal del sitio así como los dominios a proteger:

openssl req -new -newkey rsa:2048 -sha256 -nodes -keyout privkey.pem -out signreq.der -subj "/C=SP/ST=BI/O=NoLucro,S.A./CN=dominio.com" -outform der -reqexts SAN -config <(cat /etc/pki/tls/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:dominio.com,DNS:www.dominio.com,DNS:subdominio.com,DNS:www.subdominio.com"))

Os explico los parámetros:

-newkey: Genera un par de claves, en este caso RSA 2048 bit. También soporta 4096 bit.
-sha256: Algoritmo empleado para la verificación de la firma digital del certificado. Recordad, SHA-1 se considerá inseguro.
-nodes: La clave privada no será cifrada mediante criptografía simétrica.
-keyout: Archivo donde se guardará la clave privada, su contenedor es del tipo .pem.
-out: Archivo donde se guardará el CSR, IMPORTANTÍSIMO que sea .der pues LetsEncrypt no soporta .pem para el CSR.
-subj: Información personal del dueño de nuestra Web (nosotros). "C" es Country (país, 2 letras, SP=España), ST (ciudad, ¿2 letras?, BI=Bilbao), O (organicación), CN (dominio de la web).
-outform der: Como ya he dicho, este comando es fundamental para convertir el CSR en formado .der para que sea reconocible por LetsEncrypt.
-reqexts: Nos permite espicificar más de un dominio para el certificado, así un mismo certificado sirve para varios dominios/subdominios.
SAN: Subject Alter Name, campo del CSR donde podemos especificar más de un dominio, como ya he dicho previamente. Importante incluir los dominios sin www y con www, además de incluir el dominio del campo "CN".

Si todo va bien obtendreís el siguiente output al ejecutar el comando:

Generating a 2048 bit RSA private key
.........................................................................................+++
....................................................+++
writing new private key to 'privkey.pem'
-----

Ahora que tenemos el CSR, necesitamos que la entidad certificadora (CA) de LetsEncrypt nos lo firme con su clave privada, bueno, realmente firma el SHA256 de nuestro certificado y lo incluye en un nuevo campo, y ese resultado es lo que conocemos por certificado x509v3 o certificado SSL/TLS.

Para ello ejecutamos el cliente de LetsEncrypt de la siguiente forma:

./letsencrypt-auto certonly --authenticator manual --email vuestro@email.com --csr signreq.der --text --debug

Bueno no os preocupeis de la cascada de datos que se muestra en pantalla. Llegará un punto en el que el cliente se detenga y os pregunte si le dais consentimiento para almacenar vuestra IP, por seguridad, aceptaís y estareís en la siguiente fase, donde tendremos que provar a LetsEncrypt que somos los dueños de los dominios pertenecientes al CSR. Obtendreís algo como:

Make sure your web server displays the following content at
http://www.dominio.com/.well-known/acme-challenge/XU61P5E-sEefZB5vjllHeQWRpkDs2G_AvlxitI6hOIQ before continuing:

XU61P5E-sEefZB5vjllHeQWRpkDs2G_AvlxitI6hOIQ.BON7JEeVn9miBfADQ34eQIcUTsSTVsHRQqCeXuVUGVs

Simplemente nos dicen que creemos el directorio .well-known/acme-challenge en el directorio raíz de nuestro servidor. Una vez creado, en este ejemplo, crearemos el archivo XU61P5E-sEefZB5vjllHeQWRpkDs2G_AvlxitI6hOIQ con la siguiente cadena dentro XU61P5E-sEefZB5vjllHeQWRpkDs2G_AvlxitI6hOIQ.BON7JEeVn9miBfADQ34eQIcUTsSTVsHRQqCeXuVUGVs. Cuando hayais terminado visitad la URL en vuestro navegador para cercioraros de que la cadena es visible. Una vez completado el proceso presionad ENTER en la terminal donde estaís ejecutando el cliente LetsEncrypt.

Daros cuenta que las cadenas de arriba son un ejemplo, además tendreís que repetir este proceso por cada dominio especificado en el apartado SAN del CSR, ya que por cada dominio tendreís que probar a LetsEncrypt que sois vosotros sus respectivos dueños.

Si la verificación del challenge ha sido satisfactoria obtendreís un mensaje como este:

IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at
   /home/kub0x/letsencrypt/0001_chain.pem. Your cert will expire on
   2016-03-10. To obtain a new version of the certificate in the
   future, simply run Let's Encrypt again.

Felicidades, ya teneis vuestro propio certificado gratuito firmado por una entidad de confianza, por lo que vuestro certificado es válido en cualquier plataforma, navegador etc. El siguiente paso os lo dejo a vosotros. Si teneis apache simplemente modificad vuestra configuración de VirtualHosts e indicar donde está la clave privada, el certificado que habeís obtenido y la certificate chain, pues sin esta última es imposible verificar que el certificado fue emitido por LetsEncrypt.

PROS:

- Certificado válido bajo cualquier plataforma y firmado por una entidad de confianza (CA), ya que LetsEncrypt delega en IdenTrust, CA (trust-anchor) confiada por todo tipo de plataformas. + info sobre la CA en: https://letsencrypt.org/certificates/
- Renovación del certificado gratuita.
- Dentro de poco implementarán la emisión de certificados mediante la prueba de DNS, junto a la previamente expuesta basada en HTTP.

CONTRAS:

- Se encuentra en fase Beta, por lo que requiere de un conocimiento avanzado (según el modo de instalación) y no está para nada libre de bugs.
- Los certificados tienen que ser renovados cada cierto tiempo, es una política de seguridad para evitar que estén activos largos periodos de tiempo.
- En algunos hostings gratuitos o administrados es necesario deshabilitar el módulo de apache mod_security puesto que obtendremos un error "403 forbidden". En nginx ni idea.
- No se puede obtener un certificado de tipo WildCard, es decir, no emiten certificados del tipo *.dominio.com. por lo que debemos especificar en el campo SAN del CSR todos los dominios a proteger.
- Por ahora no tiene soporte en Windows.

Estaré encantado en responder cualquier cuestión relacionada con el tema. Si me animais a hacer un tutorial sobre certificados, HTTPS, SSL/TLS, RSA e incluso la matemática interna, pues obviamente, lo realizaré muy agusto, pues ahora mi entretenimiento es la criptografía al 100%.

Saludos!

[Julius 0.4]

En efecto Julius 0.4 la información que brindas bloquea gran parte de los servicios espía y las respectivas actualizaciones.

Personalmente he migrado a GNU/Linux, concretamente a Fedora 23, estoy harto de ver como cada dos semanas tengo que revisar 30 actualizaciones a mano (los bulletins de MS you know), estoy ¡HAAAARTOOOO!

Os dejo más opciones para combatir al enemigo:

https://github.com/FreeJaus/gea-PRISM/tree/master/Programming/WinUpdate%20Removal (Herramienta hecha por mí)
https://github.com/WindowsLies/BlockWindows (Muy buenos resultados)
http://www.majorgeeks.com/files/details/destroy_windows_10_spying.html
https://github.com/10se1ucgo/DisableWinTracking
http://pxc-coding.com/de/portfolio/donotspy10/
https://wiiare.in/windows-10-privacy-fixer/
http://pastebin.com/K8Ww4j8z (script en .bat)

Un gran saludo, y sí, este post merece chincheta, solo vean las visitas y la actividad que tiene.

Un mínimo de conocimiento por favor, siempre veo noticias sensacionalistas y te pintan que este malware es de lo más, cuando es una técnica más vieja que el propio sol.

Un bootkit infecta el sector de arranque donde se almacena el cargador de arranque (BootLoader). En sistemas con BIOS un bootkit es letal ya que infecta el BootLoader pudiendo deshabilitar o parchear la política de carga de drivers, pudiendo cargar en el inicio o en cualquier momento un rootkit (driver malicioso), y éstos son difícilmente detectados por AntiVirus ya que residen en el Kernel del sistema.

En el caso de los nuevos sistemas con UEFI, existe una proteción llamada "Secure Boot" la cual utiliza criptografía de clave pública para verificar en el arranque el BootLoader del sistema operativo. Si un bootkit infecta un sistema con Secure Boot activo, aunque cambie solo un BIT el sistema no arrancará ya que la verificación de la firma digital fallará. Basicamente sólo es bypasseable si existe un exploit contra UEFI (se han dado casos, interesados checkead los vídeos de la conferencia DefCon).

La única forma de protegerse contra estos ataques es utilizar Secure Boot y una copia legítima del sistema operativo (licencia original).

Saludos!

He buscado las actualizaciones y no me salen.

Voy a

configuración>actualización y seguridad>windows update>opciones avanzadas>ver el historial de actualizaciones

Lo tengo puesto en "Notificar para programar reinicio".
Utilizo windows 10 pro.

Me parece raro que a vosotros os salga y a mi no, hago algo mal? Se pueden visualizar desde otro sitio?

Buenas. El historial de actualizaciones solo sirve para ver el estado de la actualizaciones y la correspondientr fecha.

Si deseas ver o desinstalar las actualizaciones instaladas en el sistema debes de ir al panel de "Actualizaciones Instaladas" dentro de Windows Update. Ojo, esto en Win7 y 8/8.1, supongo que en el 10 será igual.

Saludos!

Para los preocupados por su privacidad sabed que contaís con la ayuda de mi herramienta de código libre.

Visitad el post -> https://foro.elhacker.net/windows/aporte_herramienta_para_eliminar_actualizaciones_espia-t440843.0.html;topicseen

Me gustaría que el mod le diera chincheta a esta post puesto que en el primer post he recopilado todas las actualizaciones espía que he ido recopilando, quizá no lo hayaís notado puesto que al editar el post no sale en "nuevas respuestas".

Gracias por la info kubox, pero cual es la info que se lleva Microsoft?


PD: En la web dicen que no recogen ni nombre ni num. de teléfono, ya es algo..

Indagando por mi sistema encontré listados gigantes en .XML simplemente es un mapeado de todas las aplicaciones instaladas en tu PC, así como la configuración de las mismas, fecha de instalación, uso regular, actualizaciones llevadas a cabo, reportes de fallos sobre corrupciones o mal funcionamiento etc Vale que lo hagan con sus productos, pero aquí también lo hacen sobre productos de terceros, seguramente los que usen cuentas Live o Outlook sus información o credenciales puede que estén expuestas (aunque digan M$ diga que no).

Saludos!

[repositorio]

Buenas noches,

Como todos sabemos, en mayo postee sobre las actualizaciones espía de Windows. Hace poco los medios han empezado a informar sobre esta tendencia por parte de Microsoft, ya que Windows 10 sigue en la línea.

Es por ello por lo que he desarrollado una tool para la eliminación de estas updates. Es totalmente gratuita, código abierto y libre de virus.

Para los interesados el código lo podeís encontrar en mi repositorio-> https://github.com/FreeJaus/gea-PRISM/tree/master/Programming/WinUpdate%20Removal/WinUpdate%20Removal

Si no sabeís como funciona github o bien os da pereza os dejo el source con los ejecutables (código + .exe) -> https://mega.nz/#!a04UFKbJ!UvjjUr6FxBFtTnkCu8hUsEsShMA2i_5KrUdnoFP8eqs

En la carpeta "executables" encontrareis los .exe para 32 y 64 bits. Ejecutad el correspondiente a vuestra plataforma, sino el desinstalador no funcionará correctamente.

Os explico el funcionamiento:

Esta herramienta codeada en C++ lista vuestras actualizaciones e identifica las actualizaciones espía instaladas en vuestro sistema. Una vez identificadas trata de desinstalarlas.

Captura (las updates que aparecen son legítimas, las puse de ejemplo que conste):



Si sabeís de alguna actualización espía adicional no dudeís en contribuir en el siguiente post -> https://foro.elhacker.net/windows/actualizacion_espia_oficial_de_windows_update-t435355.0.html

Ahí encontrareís todas las actualizaciones espía que he ido identificando.

Saludos y no dejeís que invadan vuestra privacidad sin vuestro consentimiento.

Vale ya se me ocurre, y seguramente sea eso. El socket que intentas abrir ya está reservado por el sistema, fíjate si no existe otro proceso escuchando en el puerto 80.

Si fuese el caso y necesitarás dicho proceso, podrías aplicar la técnica de TCP port stealing la cual permite bindear/asociarse al mismo puerto que otra aplicación, aunque creo que había que especificar una flag para reutilizar el socket.

No tiene que ver con el fallo en cuestión, pero en el code de tu server después de hacer Listen intentas conectar, cosa que arrojará una excepción ya que el socket está siendo utilizado para la escucha. Para eso tienes el cliente, que será otro .exe u otro hilo/subproceso dentro del mismo proceso.

Ya tienes para probar.. Y recuerda, si el server escucha, no conectes desde el mismo.

Saludos.

Buenas de nuevo.

En ese code antes del Listen de falta bindear el socket al EndPoint que has instanciado justo una linea arriba.

Recuerda:

El server primero instancia el endpoint, se bindea o se liga o se asocia (sinónimos de bindear) al endpoint y luego se hace el listen.

Una vez que el listen veas que funciona se corre el cliente y el server debería aceptarlo.

Saludos!

¿Por que en el server haces un connect antes que el listen? El server bindea y escucha nada más, el cliente sólo conecta.

Primero ejecuta el server, déjalo en segundo plano corriendo y acto seguido ejecuta el cliente, dos .exe independientes como bien dices. Debería funcionar.

Si no sigues los pasos descritos seguirá teniendo problemas. Suerte y nos cuentas

Saludos.