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

SAP HANA for RedHat 8.4 – Bypass installer compatibility

Red hat provides a playbook that can be used for SAP HANA configuration on RHEL. This ansible script sets environment variables and kernel values in order to optimize the environment for SAP workloads.

https://www.redhat.com/en/blog/getting-started-your-sap-hana-journey-rhel-8-sap-solutions

However you may encounter errors during the installation procedure. This article explains how to bypass them in order to run it on a RHEL 8.4 environment.

The first error you will notice is the sap_domain. This occurs if you have not set a value for this variable on vars.

In order to resolve this issue run the playbook using sap_domain variable.

ansible-playbook site.yml --extra-vars sap_domain=yourdomain

The second issue you will notice is that RHEL 8.4 does not belong to the supported distributions.

The compatibility is stored on the ansible collection vars section and you should edit that.

vi /usr/share/ansible/roles/sap-hana-preconfigure/vars/RedHat_8.yml

Add 8.3 or 8.4 version and save the file.

The last error you may notice would be about required packages.

Add the below repositories:

subscription-manager repos --enable=rhel-8-for-x86_64-appstream-rpms \
--enable=rhel-8-for-x86_64-baseos-rpms \
--enable=rhel-8-for-x86_64-sap-solutions-rpms \
--enable=ansible-2-for-rhel-8-x86_64-rpms

Rerun the ansible playbook.

Verify the changed states of various tasks and check active tuned profile

Posted on Leave a comment

Extend swap size on Redhat – Installer up to 128GB

If you try to allocate more than 128GB on swap partition for a Redhat installation you will notice that is not possible through installer. This is a known bug on Redhat bugzilla that is mentioned as resolved. However I tried to allocate 256GB swap with a RedHat 8.2 installer and I got the maximum size which is 128GB. In this article you will learn how to increase swap size manually.

First validate that there is available space on the volume group. (140g available on my case)

Then extend the swap logical volume

Deactivate swap file

format swap

Reactivate swap partition.

You can verify swap space with

free -g
Posted on Leave a comment

Log commands for all users on Linux – Redhat auditd

As security is one of the most important things on your infrastructure, you should enable logging for all commands and actions that a user performs (logins included).

In this article I will explain the procedure using auditd which comes preinstalled with many Linux distributions.

First things first, check if auditd is already installed and started on your system.

Then go to the rules file and open it with your favorite editor.

vi /etc/audit/rules.d/audit.rules

Add the below two rules to the end of the file.

-a exit,always -F arch=b32 -S execve -k auditcmd
-a exit,always -F arch=b64 -S execve -k auditcmd

Then execute on terminal:

augenrules 

You should then restart the service. Trying to do so with systemctl you may encounter the below error:

Execute auditd stop and start using the below commands:

service auditd stop
service auditd start

Verify existing rules:

auditctl -l

You are now ready and you can test the logging functionality. Perform a sudo action with a non root user.

Locate the action from logs.