Setting up Free VPN in Linux

July 13, 2021

Setting up Free VPN in Linux

Internet security enthusiasts and penetration testers all know how critical security protocols and privacy tools are. If you browse the Internet without them, your data could easily be intercepted by governmental institutions or common hackers. The good news is that the modern miracle of encryption technologies makes it possible to protect your data, and allows you to browse the web with the peace of mind that there isn’t anyone snooping through your data. This is even better when it is a free vpn product on linux. But there are a couple problems with common VPN services, as we’ll discuss next.

Shortfalls of Commercial VPN Services

The VPN industry is actually very competitive. In fact, there are at least tens of VPN service providers, if not hundreds. And they are a great solution for end users who just want to unlock geo-restricted content or ensure that the government isn’t tracking their online activities. Furthermore, they cheap, dirt cheap. I saw one service advertising their pricing for as little as $2.08 per month. Because they’re so affordable, secure, and convenient, a lot of people are tempted to sign up for their service. But there’s a few drawbacks, as we’ll soon discover.

First of all, a user doesn’t have any control over the service. Sure, some VPN providers allow users to select which VPN algorithm or protocol at their own discretion, but some providers only allow PPTP connections (especially the free services). The problem with PPTP is that it only offers weak security, and it has been proven to be crackable. Furthermore, the end users don’t have any visibility into the VPN service providers network, and they don’t know what goes on behind the scenes. While it is pretty common for these types of providers to have no-logging policies, but even with these policies in place, many providers still make provisions in the privacy policy to reserve the right to log metadata, IP addresses, and which servers a user connects to. Also, how do we truly know that they aren’t logging any of our data?

Secondly, you also need to take great caution when selecting a VPN provider, because many of them are based in the United States. Ever since Edward Snowden blew the whistle, most people are rightfully distrustful of US-based digital services because the NSA was found to be wiretapping legitimate corporations such as Microsoft, Apple, Google, and many others in their PRISM program. Now people just don’t want to risk their data ending up on a governmental database if their VPN service is coerced into forfeiting information by the federal government.

Thirdly, you need to understand that a commercial VPN service does nothing to protect data that your are hosting at your home. For example, a lot of us geeks like to setup our own mini-networks, complete with services like a file server, NAS device, and other local services. It’s great hosting your own file server because you don’t run the risk of a data leak, infringement of privacy, or data loss. The problem is that you can’t access your home file server securely when using a commercial VPN service.

After your data reaches the VPN server, it is decrypted and sent on to your home network. This leaves data vulnerable for an entire leg of the data’s path, and when it’s unencrypted, there’s no telling who might be able to snoop through your data. The good news is that you can easily create your own VPN server using Linux…for free! If you want to, you can even route your Internet data through your home’s VPN server when your on an unsecure network, such as the Wi-Fi at an airport or coffee shop.

Prerequisites

In order to setup your own home brewed VPN server, you’re going to need a few things. First of all, you’re going to need hardware capable of running Linux. Ideally, you’d like to have a desktop computer that you can leave running for long periods of time to provide round the clock access, but you could use a desktop or other device. Secondly, you’re going to need the latest version of Ubuntu, and you’ll also need a router (but most home networks already have a SOHO wireless router). Once you’ve gathered all the resources necessary, you can proceed to use the following guide to setup up your very own VPN server. Naturally, you will want to be the root user when running through this guide.

Step 1: Setting up OpenVPN

The first thing you’ll need to do is setup OpenVPN on your Ubuntu machine. But before we do, we’ll first need to update the repository data. Start by running the following command:

apt-get update

Next, we’ll want to go ahead and install Easy-RSA and OpenVPN with the following command:

apt-get install openvpn easy-rsa

Let’s go ahead and extract the example VPN server configuration file to /etc/openvpn using the following command:

gunzip -c /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz > /etc/openvpn/server.conf

After the data has been extracted, you’re going to need to open up the server.conf file in your text editor of choice. I’m partial to vim, but you can use any editor you wish. Use the following command:

```
vim /etc/openvpn/server.conf
```

We’re gong to make a few changes to this file. First, we’re going to double the RSA length to increase security. Look for the line with the text “dh1024.pem” and change it to say “dh2048.pem” and then look for the line that says “ redirect-gateway def1 bypass-dhcp.” Simply uncomment this line of text. Now we need to uncomment the following two lines of code:

```
push "dhcp-option DNS 208.67.222.222"
```
```
push "dhcp-option DNS 208.67.220.220"
```

Basically, this will help prevent DNS leaks. If you want, you can use DNS servers that aren’t the OpenVPN resources. Last but not least, uncomment the lines that say “user nobody” and “group nobody.” You see, OpenVPN defaults to using the root account, but we’ll want to restrict it to the user ‘nobody’ and the group ‘nogroup.’ Be sure to save your changes as you exit vim.

Setting Up Packet Forwarding

Now we’re going to edit a sysctl setting the changes IP forwarding rules. Enable packet forwarding with the following commands:

```
echo 1 > /proc/sys/net/ipv4/ip_forward
```
```
vim /etc/sysctl.conf
```

Now we simply need to remove the number sign to uncomment another line of code. Uncomment the line that says “net.ipv4.ip_forward=1.” Yet again, save your configurations and exit the text editor.
Firewall Configuration
First things first, let’s go ahead and make ufw use SSH for better security with the following commands:

```
ufw allow ssh
```
```
ufw allow 1194/udp
```
```
vim /etc/default/ufw 
```

Now find the line that is labeled DEFAULT FORWARD POLICY. It should already be set to DROP, but we need to change it to ACCEPT. Save your changes and exit, and edit the following file:

```
vim /etc/ufw/before.rules
```

Make sure the top of your file looks the same as the following lines of code:

#   ufw-before-input
#   ufw-before-output
#   ufw-before-forward

# START OPENVPN RULES
# NAT table rules
*nat
:POSTROUTING ACCEPT [0:0] 
# Allow traffic from OpenVPN client to eth0
-A POSTROUTING -s 10.8.0.0/8 -o eth0 -j MASQUERADE
COMMIT
# END OPENVPN RULES

# Don't delete these required lines, otherwise there will be errors

Now, simply enable the firewall with the following command:

ufw enable

It will ask if you want to continue, so enter a ‘y’ into the terminal. It should give you confirmation that the firewall is active and running.

Step 2: Creating the Keys and Certificate

Now we need to setup the keys and CA certificate. Start by copying the Easy-RSA keys as follows:

```
cp -r /usr/share/easy-rsa/ /etc/openvpn
```
```
mkdir /etc/openvpn/easy-rsa/keys
```
```
vim /etc/openvpn/easy-rsa/vars
```

You’ll want to edit this file and enter in credentials between the quotations as they pertain to you. The file should contain the following information.

export KEY_COUNTRY="___"
export KEY_PROVINCE="___"

export KEY_CITY="___"
export KEY_ORG="___"
export KEY_EMAIL="___"
export KEY_OU="___"

Also make sure that you name the key, but for the sake of keeping things simple, we’ll just call it ‘server.’

export KEY_NAME="server"
Now run the following commands:

openssl dhparam -out /etc/openvpn/dh2048.pem 2048

```
cd /etc/openvpn/easy-rsa
```
```
. ./vars
```
```
./clean-all
```
```
./build-ca
```

Creating the Server’s Certificate
Make sure that your current working directory is still /etc/openvpn/easy-rsa, and issue the following command:

```
./build-key-server server
```

If you named your key something different than ‘server,’ you’ll need to change the command appropriately. Keep pressing enter through the prompt and make sure you leave the challenge password blank. However, near the end, it will ask if you want to sign the certificate and commit the changes. Make sure you enter ‘y’ for both prompts. Next, we’ll copy the keys into the correct directory:

cp /etc/openvpn/easy-rsa/keys/[server.crt, server.key, ca.crt] /etc/openvpn

And now it’s finally time to start the OpenVPN service. Also, you’ll want to verify that it’s actually running with the second command:

```
service openvpn start
```
```
service openvpn status
```

Step 3: Making Keys for the Clients
By now your OpenVPN server should be up and running and our server should have its own CA certificate. But now we’ll need to build and copy the keys for the clients. The files we create will need to be installed on each device that wants to connect to the VPN tunnel. Also understand that you’ll need to reiterate these steps for each additional host you connect to the VPN. You should still be in the /etc/openvpn/easy-rsa directory, so run the following command

```
./build-key client1
```

Yet again, make sure you sign the certificate and commit the changes. Now we’re going to copy the RSA template and rename it. It was originally called client.conf, but we’ll give it a name of client.ovpn.

cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf /etc/openvpn/easy-rsa/keys/client.ovpn

Note that you will need to copy both the certificate and the key contained in the /etc/openvpn/easy-rsa/keys/ directory to each client device. Also, copy over the following two files:

/etc/openvpn/easy-rsa/keys/client.ovpn
/etc/openvpn/ca.crt

In summary, each client that wants to connect to the VPN needs the following four files:

client1.crt
client1.key
client.ovpn
ca.crt

Step 4: Creating a Global OpenVPN Profile

The next thing we should do is to edit the client.ovpn template to add the CA certificate as well as they key. That way only a single, unified client.ovpn profile will need to be added to the client’s OpenVPN installation. You can name it anything you want, but the name does need to be changed. Henceforth, we’ll refer to our file as example.ovpn. The first thing we need to edit within the file is near the top, and simply substitute the IP address of your VPN server in the field in bold.

# The hostname/IP and port of the server.
# You can have multiple remote entries
# to load balance between the servers.
remote [IP ADDRESS OF YOUR VPN SERVER] 1194
Yet again, find the lines that say ‘user nobody’ and ‘group nogroup,’ and be sure that are uncommented. Conversely, make sure the following three lines of code are commented out:
#ca ca.crt
#cert client.crt
#key client.key

Now make sure that the xml at the end of the file reads as follows, remembering to insert the names of your certificates and keys:

<ca>
(put ca.crt here)
</ca>
<cert>
(put client1.crt here)
</cert>
<key>
(put client1.key here)
</key>

Save the changes you have made and exit your editor. Congratulations, your client profile has now been configured.

Step 5: Installing the Client Profile

All that remains is to install the client profile on your operating system of choice, but this can vary greatly between different operating systems like OS X, Windows, iOS, or Android. Fortunately, OpenVPN has very detailed documentation that will show you how to install client profiles on just about any operating system you can imagine. We won’t get into the details of how to setup a client profile for every single operating system, however, since it’s a bit outside the scope of our tutorial. However, after downloading your free vpn product on linux and following the instructions on the OpenVPN site, you should be able to connect securely to your home’s VPN tunnel.

SSH for Penetration Testing

SSH stands for Secure shell and works on Port 22 . As penetration testers we are aware of the uses and power of SSH on remote access of systems . During Penetration testing SSH might come handy as a powerful tool .

This post will explain some of the techniques that can be used during a penetration test .

Local Forwarding using SSH

Sometimes we come across scenarios where we need the services on the remote host accessible to the host via Local Network . Root is required .

ssh -L 127.0.0.1:10521:127.0.0.1:1521 user@192.168.1.10

~/.ssh/config:

LocalForward 127.0.0.1:10521 127.0.0.1:1521

Remote Forwarding using SSH

Well this technique is complete opposite of the previous one . Remote forwarding on using SSH comes to rescue in those penetration testing scenarios where we need the services on a local machine / Local Network accessible to remote host via a remote listener . This might sound odd … why would I want my machine accessible on a remote host , but lets face it , we all need to expose a service that lets us download our penetration testing tools.

For the practical information here is an example :

The SSH server will be able to access TCP port 80 on SSH client by connecting to 127.0.0.1:8000 on the SSH Server .

ssh -R 127.0.0.1:8000:127.0.0.1:80 192.168.1.10

~/.ssh/config:

RemoteForward 127.0.0.1:8000 127.0.0.1:80

SOCKS Proxy using SSH

Here we set up a SOCKS Proxy on 127.0.0.1:8000 that lets you pivot through the Remote Host 192.168.1.10

 ssh -D 127.0.0.1:8000 192.168.1.10

~/.ssh/config:

Host 192.168.1.10
DynamicForward 127.0.0.1:8000

X11 Forwarding using SSH

If your SSH client is also an X-Server then you can launch X-clients (e.g. Firefox) inside your SSH session and display them on your X-Server. This works well with from Linux X-Servers and from cygwin‘s X-server on Windows.

SSH -X 10.0.0.1
SSH -Y 10.0.0.1 # less secure alternative - but faster

~/.ssh/config:

ForwardX11 yes
ForwardX11Trusted yes # less secure alternative - but faster

SSH Authorized Keys :

SSH stands for Secure Shell … well to be secure , its always advisable to use Keys for encrypting the SSH communication . This helps to avoid unwanted hosts to take advantage of the penetration test and keep the penetration testing secure .

That being said , it is a good practice to add an authorized_keys file that will allow you to log in using an SSH key .

Authorized_keys File : This file is present in the User’s Home Directory on the SSH server . This file basically holds the public keys of the users allowed to login into that user account of SSH Server .

For this the first step is to Generate PUBLIC KEY / PRIVATE KEY pairs .

sh-keygen -f mysshkey
cat mykey.pub # to copy this to authorized_keys

To connect to the Remote host using the authorized key :

ssh -i mykey user@10.0.0.1

Some Cool SSH Configuration Tweeks

Finally here are some cool modifications you can do to your SSH Client system , this will make it easier to use other penetration testing tools that are using SSH .

Host 10.0.0.1
Port 2222
User ptm
ForwardX11 yes
DynamicForward 127.0.0.1:1080
RemoteForward 80 127.0.0.1:8000
LocalForward 1521 10.0.0.99:1521

#Please Share and Comment if you like this Post .

What are Rainbow Tables?

Do you know what’s a Rainbow table. Well if you are an amateur hacker like i once was, a rainbow table is a huge pre-computed list of hash values for every possible combination of characters. A password hash is a password that has gone through a mathematical algorithm that transformed it into something absolutely foreign and when i mean foreign i mean it looks like some hieroglyphics stuff that you would see on those egyptian pyramids, well that was when i just started out but don’t worry if you’re a amateur you will pass that stage soon. A hash is a one way encryption so once a password is hashed there is no way to get the original string from the hashed string. A very common hashing algorithm used as security to store passwords in website databases is MD5.

If you are confused like i once was couple years ago well here is a scenario, Let’s say you are registering for a website which I did couple weeks ago. You put in a username and password. Now when you submit, your password goes through the MD5 algorithm and the outcome hash is stored in a database. Now since you can’t get the password from the hash, you may be wondering how they know if your password is right when you login. Well when you login and submit your username and password, a script takes your password and runs it through the md5 algorithm. The outcome hash is compared to the hash stored in the database. If they are the same, you are admitted plain and simple.

If I were to run the word “cheese” through the md5 algorithm, the outcome would be (fea0f1f6fede90bd0a925b4194deac11) yep that’s what called those weird looking stuff. Having huge tables of every possible character combination hashed is a much better alternative to brute-force cracking. Once the rainbow tables are created, cracking the password is a hundred times faster than brute-forcing it. You can avoid rainbow table cracking by simply making your password extremely long. Creating tables for passwords that are long takes a very long time and a lot of resources. That is why there aren’t many of these tables available.

Constructing a rainbow table requires two things, a hashing function and a reduction function. The hashing function for a given set of Rainbow Table must match the hashed password you want to recover if it don’t well you already the drill. The reduction function must transform a hash into something usable as a password. A simple reduction function is to Base64 encode the hash, then truncate it to a certain number of characters.

Rainbow tables are constructed of “chains” of a certain length: 100,000 for example. To construct the chain, pick a random seed value. Then apply the hashing and reduction functions to this seed, and its output, and continue iterating 100,000 times. Only the seed and final value are stored. Repeat this process to create as many chains as desired.

To recover a password using Rainbow Tables, the password undergoes the above process for the same length: in this case 100,000 but each link in the chain is retained. Each link in the chain is compared with the final value of each chain. If there is a match, well the chain can be reconstructed, keeping both the output of each hashing function and the output of each reduction function. That reconstructed chain will contain the hash of the password in question as well as the password that produced it.

Rainbow Tables have the benefit, the person constructing those tables can choose how much storage is required by selecting the number of links in each chain. The more links between the seed and the final value, the more passwords are captured. One weakness is that the person building the chains doesn’t choose the passwords they capture so Rainbow Tables can’t be optimized for common passwords. Also, password recovery involves computing long chains of hashes, making recovery an expensive operation. The longer the chains, the more passwords are captured in them, but more time is required to find a password inside.So there you have it i hope you learnt something valuable.

Secure Sockets Layer Tutorial | What is SSL | SSL Hackers Guide

Secure Sockets Layer or SSL Hackers Guide : You might have heard some times that not to give your password or credit card information or any other sensitive information on public computers or on Facebook, yahoo etc chats.The reason why you might have heard that the Hackers have some ways to you would have probably heard that hackers have a way to steal your your credit card numbers , passwords etc.

Secure Sockets Lock Tutorial | What is SSL | SSL Hackers Guide

A hacker can use different types of attacks such as Packet sniffing or ARP Poisoning to steal your sensitive information.

Secure Sockets Layer (SSL) is the most widely used technology for creating a secure communication between the web client and the web server. You must be familiar with http:// protocol and https:// protocol, You might be wondering what they mean. HTTP protocol is used for standard communication between the Web server and the client. HTTPS is used for a secure communication.

Cryptography

If two users want to have a secure communication they can also use cryptography to accomplish it

For example:

TFDVSF=Encrypted Text

SECURE= Decrypted Text

You might be wondering how i Decrypted it, Here i have used Algorithm=+ for the communication and the key is “1“, What comes after S is T so as you can see that S is converted into T, What comes After E is F to letter E from the word secure if converted into F and so on, To help you understand this more better I am adding a Video –

So If the hacker starts sniffing from between he will get Encrypted text and as the Hacker does not know the keys so he cant decrypt it, but if the attacker or hacker is sniffing from the starting point so he will get the key and can easily Decrypt the data.

Standard Communication VS Secure communication

Suppose there exists two communication parties A (client) and B (server)

Standard communication(HTTP)

When A will send information to B it will be in unencrypted manner, this is acceptable if A is not sharing Confidential information, but if A is sending sensitive information say “Password” it will also be in unencrypted form, If a hacker starts sniffing the communication so he will get the password.

This scenario is illustrated using the following figure –

Standard Communications HTTP

Secure communication(HTTPS)

In a secure communication i.e. HTTPS the conversation between A and B happens to be in a safe tunnel, The information which a user A sends to B will be in encrypted form so even if a hacker gets unauthorized access to the conversion he will receive the encrypted password (“xz54p6kd“) and not the original password.
This scenario is illustrated using the following figure –

Secure communication(HTTPS)

How is HTTPS implemented?

A HTTPS protocol can be implemented by using Secure Sockets Layer (SSL), A website can implement HTTPS by purchasing SSL certificate.

Which websites need SSL Certificate?

The websites where a private conversation is occurred, Websites related to online transactions or other sensitive information needs to be protected needs to SSL Certificate.

How to identify a Secure Connection?

In Internet Explorer and google chrome, you will see a lock icon in the Security Status bar. The Security Status bar is located on the right side of the Address bar. You can click the lock to view the identity of the website.
If you are making an online transaction through Credit card or any other means you should check if https:// secured communication is enabled.

Shellshock Bash Bug Complete List of Vulnerabilities by Hackingloops

Shellshock aka Bash Bug vulnerability was discovered just one week back and its growing day by day. Most of security researchers are aware of just two vulnerabilities related to shellshock or bash bug i.e. CVE-2014-6271 and CVE-2014-7169. But my friends there are lot more vulnerabilities that come under the scope of Shellshock bash bug. Today i will share complete list of vulnerabilities which are related to Shellshock bash bug. In our previous two articles, we have learned about basics of shellshock i.e. bash vulnerability and how to patch those. Today we will learn how to test all vulnerabilities related to Shellshock aka bash bug.

Shellshock Bash Bug Complete List of Vulnerabilities and Test String

Complete list of Shellshock bash bug vulnerabilities and how to test that you are vulnerable to them:

CVE-2014-6271:

Overview: GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution, aka “ShellShock.” NOTE: the original fix for this issue was incorrect; CVE-2014-7169 has been assigned to cover the vulnerability that is still present after the incorrect fix.

Testing CVE-2014-6271 that you are vulnerable or not. Open bash prompt and run the below command:

env X='() { :; }; echo “CVE-2014-6271 vulnerable”‘ bash -c id

If you get “CVE-2014-6271 vulnerable” then it means you are vulnerable, if you get bash error that means your version of bash is not vulnerable.

Impact: Network exploitable, no authentication required for running the exploit, allows unauthorized disclosure of information, allows unauthorized modification and even allows Distributed DOS attack.

Complete details of CVE-2014-6271 vulnerability : NIST

CVE-2014-7169 :

Overview: GNU Bash through 4.3 bash43-025 processes trailing strings after certain malformed function definitions in the values of environment variables, which allows remote attackers to write to files or possibly have unknown other impact via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution. NOTE: this vulnerability exists because of an incomplete fix for CVE-2014-6271.

Testing CVE-2014-7169 that you are vulnerable or not. Open bash prompt and run the below command:

env X='() { (a)=>’ bash -c “echo date”; cat echo

If you are vulnerable to CVE-2014-7169, then it will create a file named echo in cwd with date in it.

Impact: Network exploitable, no authentication required for running the exploit, allows unauthorized disclosure of information, allows unauthorized modification and even allows Distributed DOS attack.

Complete details of CVE-2014-7169 vulnerability : NIST

CVE-2014-6277 :

Overview: GNU Bash through 4.3 bash43-026 does not properly parse function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code or cause a denial of service (uninitialized memory access, and untrusted-pointer read and write operations) via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution. NOTE: this vulnerability exists because of an incomplete fix for CVE-2014-6271 and CVE-2014-7169.

How to test you are vulnerable to CVE-2014-6277 or not. Just test the following code in shell:

foo='() { echo CVE-2014-6277 Vulnerable; }’ bash -c foo

If you get “CVE-2014-6277 Vulnerable” then it means you are vulnerable.

This vulnerability causes an attempt to access uninitialized memory leading to reads from, and then subsequent writes to, a pointer that is fully within attacker’s control. Basically untrusted pointer use issue leading to remote code execution.

Complete details of CVE-2014-6277 vulnerability : NIST

CVE-2014-6278 :

Overview: GNU Bash through 4.3 bash43-026 does not properly parse function definitions in the values of environment variables, which allows remote attackers to execute arbitrary commands via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution. NOTE: this vulnerability exists because of an incomplete fix for CVE-2014-6271, CVE-2014-7169, and CVE-2014-6277.

Red Hat believes that changes introduced via updates RHSA-2014:1306, RHSA-2014:1311, and RHSA-2014:1312 that prevent Bash from defining new functions based on arbitrary environment variables sufficiently mitigate this issue.

The underlying parser flaw has not yet been disclosed and might still exist in latest released bash packages. However Florian Weimer’s variables-affix.patch patch applied in Debian prevents exploitation of this issue by making bash only use environment variables with specific names (BASH_FUNC_*()) to define functions from its environment.

How to test you are vulnerable to CVE-2014-6277 or not. Just test the following code in shell:

foo='() { echo CVE-2014-6278 Vulnerable; }’ bash -c foo

If you get “CVE-2014-6278 Vulnerable” then it means you are vulnerable. In order to patch this Florian patch is available online.

Complete details of CVE-2014-6278 vulneraiblity : NIST

CVE-2014-7186 :

Overview: The redirection implementation in parse.y in GNU Bash through 4.3 bash43-026 allows remote attackers to cause a denial of service (out-of-bounds array access and application crash) or possibly have unspecified other impact via crafted use of here documents, aka the “redir_stack” issue.

How to test you are vulnerable to CVE-2014-7186 or not. Just test by running below string in shell:

bash -c ‘true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF’ || echo “CVE-2014-7186 vulnerable, redir_stack”

If you get “CCVE-2014-7186 Vulnerable” then you are vulnerable to this.

Complete details of CVE-2014-7286 vulnerability : NIST

CVE-2014-7187 :

Overview: Off-by-one error in the read_token_word function in parse.y in GNU Bash through 4.3 bash43-026 allows remote attackers to cause a denial of service (out-of-bounds array access and application crash) or possibly have unspecified other impact via deeply nested for loops, aka the “word_lineno” issue.

How to test you are vulnerable to CVE-2014-7186 or not. Just test by running below string in shell:

(for x in {1..200} ; do echo “for x$x in ; do :”; done; for x in {1..200} ; do echo done ; done) | bash || echo “CVE-2014-7187 vulnerable, word_lineno”

If you get “CVE-2014-7187 Vulnerable” then it means you are vulnerable to this bug.

Complete details of CVE-2014-7286 vulnerability : NIST

Recommended Articles related to Bash Bug or Shellshock vulnerability:

1. SHELLSHOCK BASH BUG IN LINUX, UNIX, MAC OS X TUTORIAL AND PATCH

2. HOW TO FIX SHELLSHOCK BASH VULNERABILITY TUTORIAL

That’s all for today. In my later articles we learn more about Proof of concept of all vulnerabilities related to Shellshock Bash bug. So keep connected and keep learning.

Crypters tutorial for Hackers by Hackingloops

Crypters are computer applications which are solely used to bypass the antivirus detection of malwares. Hackers use crypters to hide viruses, Trojans, RATS, keyloggers and other hack tools into a new executable, whose sole purpose is to bypass the detection of the same from antivirus. Crypters are basically dead programs which does not affect the actual functionality of the program, they just spoof the actual program behind their encryption and make antivirus fool. Most antivirus detects viruses on basis of heuristics and normal string based detection. Since we have spoofed the original program, so antivirus stand lame and does not detect it as virus.

Crypter tutorial : only for hackers

Common terms related to crypters:

For understanding and designing crypters, hackers must be aware of certain terms, most of you already know these terms, but as i am writing this tutorial starting from novice level and take it to elite level at the end. So if you know these terms just read them one more time, as that might help you to clear some of your doubts.

1. FUD or UD : Fully undetectable(FUD) means that your virus is not detected by any of the existing antiviruses while undetectable(UD) means detectable by few antiviruses. FUD is our only goal and elite hackers always rely on that.

Note: Crypter will remain FUD until you have openly shared on internet. Public crypters remains FUD up to maximum 2 to 3 days then they become UD. So if you want to use crypter for long time so never publish and share that on internet. Use it anonymously.

2. STUB : A stub is a small piece of code which contains certain basic functionality which is used again and again. It is similar to package in Java or simply like header files in C ( which already has certain standard functions defined in it). A stub basically simulates the functionality of existing codes similarly like procedures on remote machines or simply PC’s. In crypters, client side server is validated using stubs, so never delete stub file from your crypter. Stubs adds portability to crypter code, so that it can be used on any machine without requiring much procedures and resources on other machines.

Let me explain with small example:

Suppose you are writing a code that converts bytes to bits, so we know formula or method for converting bytes to bits will remain same and it will be independent of machine. So our stub (or method stub or procedure) will contain something like this:

BEGIN
totalBits = calculateBits(inputBytes)
Compute totalBits = inputBytes * 8
END

Now what we will pass is only number of bytes to this stub. And it will return the resulting bits. Similarly, we include some common machine independent checks and functions in our stub, and in main code we only passes linkage and inputs to these stubs, which in return provides suitable results.

Note: Most of times it happens, suppose you downloaded some keylogger and you complain to provider its not working, only reason for that is stub. Also always kept in your mind, if you are downloading any keylogger or crypter always check stub is present in it. If not, don’t download it, its just a piece of waste and for sure hacker is spreading his virus using that. I recommend that never download any hacking tool on your real machine, always use virtual machine or sandbox to test hack tools.

3. USV: Unique stub version or simply USV is a part of crypter that generates a unique version of stub which differentiates it from its previous stub, thus makes it more undetectable against antiviruses. For detecting this antivirus companies has to reverse engineer your crypter stub, that is not that easy to do, so it will remain undetectable for long time. This consist of one most important component USG ( unique stub generation) which is the actual part of crypter that encrypts and decrypts the original file means its the heart of your algorithm and i will recommend never write this part in stub, rather include this part in main code. Why i am saying this, stub is part of code which is shared with victim, so it will become public and hence your Crypter will not remain FUD for much long time.

Different types of crypters:

1. External Stub based crypters : This category consists of public crypters (those you have downloaded till date :P (noobish one’s) and you complains to provider that its detectable by antiviruses. That really foolish complaint, if crypter is public then it can never remain FUD. So don’t ever complain to me also after my next article for such noobish things. Ahahah.. i got deviated for real thing.

External Stub based crypters are those crypters in which most of the functionality of the crypter depends of external stub, if your delete that stub file, your crypter is useless. :P Most antivirus only do that. These type of crypters contains two files one is client.exe and other is stub.exe . Stub contains the main procedures and client contains the global functions that call those procedures.

2. Internal or Inbuilt stub based crypters: The crypters that contains only one exe file (i.e client) fall under this category. This client file has inbuilt stub in it. You can separate stub and client part here too using RCE (reverse code engineering) but it is not recommended.

Note: External or Internal stub doesn’t make much difference as antivirus detects files on the basis of strings related to offsets. Whenever you reverse engineer any application or program, the program execution flow will gonna remain the same but offsets may change. USV will come into picture at this point. If you include your encryption algorithm separately then it will be more harder for antivirus to detect your crypter.

3. Run time crypters: Run time crypters are those crypters which remain undetected in memory during their execution. We are looking for these type of crypters only. :P These can any of the two above.

4. Scan time crypters: Those crypters which will remain undetected while encrypting the files but will become detectable when resultant file is generated. :P Fking one’s that wastes all effort we have put. This really annoys everything is working fine and at last you get your file being detected by noob antiviruses.

So friends, this is for today, i will share more about crypters like how to make internal and external stubs based crypters, how to make stubs absolutely FUD by using packers and obfuscators. So remain connected..

If you have any queries, ask me in form of comments. A comment of appreciation is always heartily accepted.

Secure Sockets Layer (SSL): Complete Tutorial Of SSL

Secure Sockets Layer (SSL) is the most widely used technology for providing a secure communication between a web client and web server. Most of us are familiar with sites such as Gmail and Yahoo using https protocol in their login pages. When we see this, we may wonder about the difference between http and https. Simply put, HTTP protocol is used for standard communication between a web server and client, while HTTPS is used for a SECURE communication.

What exactly is Secure Communication ?

Suppose there exists two communication parties, A (client) and B (server).

The Workings of HTTP

When A sends a message to B, the message is sent as a plain text in an unencrypted manner. This is acceptable in normal situations where the messages exchanged are not confidential. But imagine a situation where A sends a PASSWORD to B. In this case, the password is also sent as a plain text. This poses a serious security problem; if an intruder (hacker) can gain unauthorized access to the ongoing communication between A and B , he can see the PASSWORDS, as they remain unencrypted. This scenario is illustrated using the following figure

The Workings of HTTPS

When A sends a PASSWORD (say “mypass“) to B, the message is sent in an encrypted format. The encrypted message is decrypted on B’s side. So even if the Hacker gains unauthorized access to the ongoing communication between A and B, he gets only the encrypted password (”xz54p6kd“) and not the original password. This is shown below

How is HTTPS implemented?

HTTPS is implemented using Secure Sockets Layer (SSL). A website can implement HTTPS by purchasing an SSL Certificate. Secure Sockets Layer (SSL) technology protects a website and allows visitors to trust the site with their personal information. It has the following uses:

An SSL Certificate enables encryption of sensitive information during online transactions.

Each SSL Certificate contains unique, authenticated information about the certificate owner.
A Certificate Authority verifies the identity of the certificate owner when it is issued.

How Encryption Works

Each SSL Certificate consists of a Public key and a Private key. The public key is used to encrypt the information and the private key is used to decrypt it. When your browser connects to a secure domain, the server sends a public key to the browser to perform the encryption. The public key is made available to everyone, but the private key (used for decryption) is kept secret. During a secure communication, the browser encrypts the message using the public key and sends it to the server. The message is decrypted on the server side using the private key.

How to identify a secure connection

In Internet Explorer, you will see a lock icon in the Security Status bar. The Security Status bar is located on the right side of the address bar. You can click the lock to view the identity of the website.

In high-security browsers, the authenticated organization name is prominently displayed and the address bar turns GREEN when an Extended Validation SSL Certificate is detected. If the information does not match or the certificate has expired, the browser displays an error message or warning and the status bar may turn RED.

So the bottom line is, whenever you perform an online transaction such as credit card payment, bank login, or email login always ensure that you have a secure communication. A secure communication is a must in these situations to avoid phishing.

Search This Blog

INDIAN CYBER