Posted on Leave a comment

Email spoofing using Postfix – How I hacked my own email for testing purposes

It was a nice morning when I woke up and started surfing before going to work. Little did I know for what will happen that day. Outlook sent me a notification email, the one you can see below. At first I got shocked. I understood immediately that it was a spam email asking for money through crypto payments, but how did the sent it from my email address? The sender was me and the recipient was also me.

If you check carefully the email originator is the same email as the recipient. Did I got hacked? I instantly went to change my passwords and enable MFA option (yes you should do that before you get p0wned).

After contacting my host provider for logs (I wanted to make sure that the mail server was not affected) I started investigating the email. At first it seems like a normal one. By investigating further, I checked the headers.

Oups something seems strange here. The received from headers point an unknown host, the one that tried to trick me. Mister I could send you back the same email from your own address.

Return-Path: <support@brightdirectories.com>
X-Original-To: webmaster@geralexgr.com
Delivered-To: webmaster@geralexgr.com
Received: from cloudvpsserver.host.brightdirectories.com (unknown [64.91.244.139])

spf=pass (sender IP is 64.91.244.139) smtp.mailfrom=support@brightdirectories.com smtp.helo=cloudvpsserver.host.brightdirectories.com

This method of attack is called spoofing and you can read more details from the below article.

https://www.proofpoint.com/us/threat-reference/email-spoofing

Lets try to implement the same attack now, to understand how difficult this could be. The only thing that you will need is a linux machine running postfix and sendmail package. As simple as that and you become a spoofing hacker.

First things first, install and start postfix service.

yum install postfix sendmail; systemctl start postfix

Edit postfix configuration to allow all inet_interfaces.

vi /etc/postfix/main.cf

Then we will try the first spoofing attempt.

[root@centos-lab ~]# sendmail -v webmaster@blablabla.com < mail.txt

The attempt failed. What happened though? By checking the logs, I could find that mail server blocks some incoming messages based on spamhaus service.

Is that hard to bypass? Totally not. You have to go on spamhaus link and whitelist your IP address. The next time the service is updated, your email will be received from the mail server. I have to say that more advanced mail services like google, outlook provide much more sophisticated services to block spam than spamhaus.

By trying to send again my email, I successfully spammed my own mailbox. Lets try a google account this time. I will try to send an email from my personal domain account email to my gmail account. However this would be a spam email as the origin will be a local postfix service that tries to impersonate the real owner.

sendmail -v my_Gmail < mail.txt

You can find my mail.txt contents below.

From: webmaster@blablabla.com
Subject: spoofing email attack this email was sent from an unknown sender using postfix 

Voila. I received a spam email from a sender that is not the original one.

If you check more carefully, google adds a question mark and informs you that it could not verify the owner of the email. However the spam went directly to my mailbox and did not arrive on spam.

If you check the headers again, you will verify that the originator is fake

Original Message
Message ID	<202111202159.1AKLxI8x016745@geralexgr.com>
Created at:	Sat, Nov 20, 2021 at 11:59 PM (Delivered after 2 seconds)
From:	webmaster@blablabla.com
To:	
Subject:	spoofing email attack this email was sent from an unknown sender using postfix
SPF:	FAIL with IP 2.84.53.88 Learn more


Download Original
Copy to clipboard

Delivered-To: 
Received: by 2
Received: from geralexgr.com (IP_address. 
Received-SPF: fail (google.com: domain of root@geralexgr.com does not designate IP as permitted sender) client-ip=xxxxxx;
Authentication-Results: mx.google.com;
       spf=fail (google.com: domain of root@geralexgr.com does not designate 2.84.53.88 as permitted sender) smtp.mailfrom=root@geralexgr.com
Received: from geralexgr.com (localhost [127.0.0.1]) by geralexgr.com (Postfix) with ESMTPS id 88E031099F6B for <xxxxxx>; Sat, 20 Nov 2021 23:59:18 +0200 (EET)
Received: (from root@localhost) by geralexgr.com (8.15.2/8.15.2/Submit) Sat, 20 Nov 2021 23:59:18 +0200
Date: Sat, 20 Nov 2021 23:59:18 +0200
Message-Id: <202111202159.1AKLxI8x016745@geralexgr.com>
From: webmaster@geralexgr.com
Subject: spoofing email attack this email was sent from an unknown sender using postfix

As you can see from headers, the real sender is root@localhost and not the sender that is shown on gmail. You can also locate the incoming IP address.

To conclude we examined how one could spoof your email account and impersonate your self. Be very careful on the emails you receive and double check the originator. It is very easy to get hacked with this technique.

Posted on Leave a comment

Users with superuser privileges – sudo and su on RHEL 8

Sudo and su are two powerful utilities on linux operating system that enables one to manipulate who is performing actions on the filesystem and with which privileges .

The main difference between those two tools is that if administrator uses su - username then he should provide the user password in order to switch to the end user rights. On the other hand with sudo command the administrator should use its own password in order to validate with the system that he wants to run as a superuser the command su - .

As a result by using sudo su - x you dont have to specify the end user password but your own password.

Another way you can authorize your self as superuser is with sudo -i so you do not have to provide the password of root in the system.

The sudo command is very powerful and useful in the linux systems because for security purposes many times you could find root user deactivated and each user has its own credentials and rights. Also actions performed with sudo commands are logged in the operating system.

The most important prerequisite in order to use sudo command in Red Hat or Centos Linux is to be a member of the wheel group. You can give a specific user sudo rights with the following:

Create a new file under /etc/sudoers.d/USERNAME

touch /etc/sudoers.d/operator

and then vi the operator file and add the following line:

operator ALL=(ALL) ALL

using sudo with a user that does not have admin rights.
using sudo after creating the necessary file under sudoers.d
Posted on 1 Comment

The ultimate Guide of Security – Infrastructure Web application Hardening

This guide is written in order to help the IT Security Administrators secure their Infrastructure (VM in the cloud or something equivalent) that host web applications. It encloses knowledge that has been gained from multiple penetrations test from different vendors in projects that I have participated. It cannot protect you 100% but is a good and detailed way to start your security hardening.

Table of contents:

  • OS patching
  • Strong passwords and permissions
  • SSL Certificate
  • Install fail2ban
  • Set up firewall
  • Limit ssh access
  • PHP Hardening
  • Apache Hardening

OS patching:
Keep always your OS ( Red Hat Linux or equivalent) up to date with the latest security updates and patches. As a result before starting your installations perform an OS update. It is very important also to keep your Apache and PHP packages patched.

Strong passwords and permissions:
Create strong passwords for your users and add users with separate directories and permissions. Each user should have its own directory to manipulate files and should not have root access. For example if user X should be the application owner, then he should have permissions only to write/upload files in /var/www/application folder and no root permissions.

SSL Certificate:
Install a valid SSL Certificate and redirect all http traffic to https. You can view my blog post on how to install your apache SSL certificate from here. Redirection can be implemented by adding the appropriate rule in your .htaccess file.

Install fail2ban:
Fail2Ban scans log files like /var/log/auth.log and bans IP addresses conducting too many failed login attempts. You can find it from Github and configure it appropriately.

Set up firewall:
You should consider enabling a firewall for your infrastructure like Cloudflare that enables WAF/DDOS protection actions. You could also enable the build in Linux firewall and set up rules through iptables.

Limit ssh access:
Limit IP addresses that could access your infrastructure server. You could do that by disabling all from /etc/hosts.deny and allow only the IP addresses that you will use in /etc/hosts.allow . As a result you should

/etc/hosts.deny:
sshd : ALL

/etc/hosts.allow:
sshd : YOUR_IPS/24

PHP Hardening:
open_basedir, if set, limits all file operations to the defined directory and below. When a script tries to access the filesystem for example using fsockopen() the location of the file is checked. If the file is outside the defined directory PHP will refuse access.
Set openbasedir to your site directory. For example if your web application is a drupal installed in the directory /var/www/drupal then your openbasedir should be set to include your app directory and every other directory that you want (see below example).

open_basedir = "/home/X/:/var/www/drupal/:/tmp/"

Also you should consider disabling some php functions for security reasons like the below.

disable_functions = phpinfo,exec,shell_exec,passthru,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source,proc_close,symlink,apache_getenv,apache_get_modules,apache_get_version,apache_lookup_uri,apache_note,apache_request_headers,apache_reset_timeout,apache_response_headers,apache_setenv,closelog,curl_exec,curl_multi_exec,debugger_off,debugger_on,define_syslog_var,define_syslog_variables,diskfreespace,disk_free_space,dl,escapeshellarg,escapeshellcmd,exec,ftok,ftp_connect,ftp_exec,ftp_get,ftp_login,ftp_nb_fput,ftp_put,ftp_raw,ftp_rawlist,getmypid,getmyuid,highlight_file,ignore_user_abord,ini_alter,ini_get_all,ini_restore,leak,limit,link,listen,mysql_list_dbs,openlog,parse_ini_file,passthru,pclose,pcntl_exec,pg_host,php_uname,popen,posix_access,posix_ctermid,posix_getcwd,posix_getegid,posix_geteuid,posix_getgid,posix_getgrgid,posix_getgrnam,posix_getgroups,posix_getlogin,posix_getpgid,posix_getpgrp,posix_getpid,posix_getpwnam,posix_getpwuid,posix_getrlimit,posix_getsid,posix_getuid,posix_isatty,posix_kill,posix_mkfifo,posix_mknod,posix_setegid,posix_seteuid,posix_setgid,posix_setp,posix_setpgid,posix_setsid,posix_setuid,posix_times,posix_ttyname,posix_uname,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,readfile,readlink,safe_dir,satty,scandir,set_time,set_time_limit,shell_exec,show_source,socket_accept,socket_bind,socket_clear_error,socket_close,socket_connect,source,symlink,syslog,system,tmpfile,virtual

Disable allow_url_include and allow_url_fopen

allow_url_fopen=Off
allow_url_include=Off

The previous described actions should be applied on /etc/php.ini file.

Some of them may disable your web application behavior so you should check if you need them.

Apache Hardening:


Disable content or MIME sniffing:

Header set X-Content-Type-Options: "nosniff"

Defense from Clickjacking attack:

Header set X-Frame-Options: "sameorigin"

Set Strict-Transport-Security header settings configured for a timespan of 2 years:

Header set Strict-Transport-Security "max-age=63072000; includeSubDomains;"

Add X-XSS-Protection header to prevent some level of XSS:

Header set X-XSS-Protection "1; mode=block"

Add Referrer-Policy header to your webserver:

Header always set Referrer-Policy "same-origin"

Deny TRACE/TRACK requests:

RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]

Hide Apache Information:

ServerSignature Off
ServerTokens Prod

Of course there are a lot more things that could be applied for your infrastructure hardening per case. The system Administrator should always be up to date with the security standards and discoveries in order to eliminate risks from malicious unauthorized access.