Tuesday, June 2, 2015

Compromised Server, Me and Few Layers Of Security

Well this is not a theory on the layer wise security. Everyone know the concept of layer wise security. Main gate- main door- rooms doors, this sums up what layer wise security is. It makes bad guys hard to reach your living room. Well, that not all. Few weeks ago I got an opportunity to look into the compromised server. I had to figure out the cause of incident and deliver incident report. Server was in the Amazon cloud and AWS support guys did their job by shutting down compromised server down, not exactly shutdown but they blocked every traffic out of the server. They detected DoS attack being conducted through that compromised server using UDP port 80 on an IP belonging to an enterprise. AWS support guys allowed SSH into the server and there I was checking everything I possibly could in AWS server. Looked into users, passwords, shadows, file permissions, history, netstat, nmap, apache access log, error log, auth log and what not. Must say "the blue team handbook" did come in good use that time.
I found nothing. Yes!! nothing and that kept me wondering for minutes, thinking what attack vectors I have missed and so on. I was not thinking well, because somewhere in my mind I already assumed an attack through Remote code execution, and after not seeing suspicious access log and error log in Apache,
I could not think more. Later after a sip of black coffee, I did malware scan on the server. Rootkit hunter was my first tool to use, then came the clamav antivirus, and Bingo!! there it was rootkit hiding inside /bin/netstat, /bin/ps.

And yes, i was using that netstat and ps command to find information. Felt stupid. But i was still unsure. And this time, host based IDS came into party which I had forgotten that it was already installed in the server. Little bit of log analysis and I found OSSEC HIDS did log and alert rootkit detection on the date when DoS attack was detected. I confirmed more with checking binary hashes and found it was different than the original.
Later I zipped those scripts,downloaded in my pc and did a scan with Avast. I got an alert and it was more detailed.

This incident made me realize the need layer wise security with different angle. Its not always about protecting but also about fighting back. I am not a malware analyst so I did not go through that part but what I'm trying to say is without IDS installed it would have been real difficult to figure out and keep analyze changes in the server.

Saturday, February 1, 2014

Sending Email Alert From Apache ModSecurity

Apache Modsecurity can be configured to provide different passive response, an email alert is one of it. To get this done, we need to have mail service enabled in our host server. Generally an installation of Postfix or similar application will do the task.

Configuration steps

1. Create a emailing script and place it anywhere in the server. There in the following examples we have created a folder "my_test_rules" and placed my custom email script.

# cd /usr/share/modsecurity-crs/my_test_rules
#nano send_simple_email_alert.sh
  #!/bin/sh
  echo "Fake user tried to access the web application" | mail -s "server under attack" your_email@domain.com
  echo Done.

2. Write a custom rule that will execute the email script when triggered like sample rule below:

#nano test_request_headers_and_send_email.conf

  SecRule REQUEST_HEADERS:User-Agent "FAKE-USER" "deny,log,id:'1234123457',exec:/usr/share  /modsecurity-crs/my_test_rules/send_simple_email_alert.sh"

3. Add the Sym link of the custom rule in the activated_rules directory under /usr/share/modsecurity-crs

#cd /usr/share/modsecurity-crs/activated_rules
#ln -s ../my_test_rules/test_request_headers_and_send_email.conf

4. Reload Apache

#service apache2 restart

We can send detail email with the use of variables and directives of the ModSecurity firewall. An example below:

send_detail_email_alert.sh

#!/bin/sh
echo "False user tried to access the web application: Server: \
$SERVER Attacking IP: $REMOTEIP Attacking host: $REMOTEHOST \
Request URI: $REQUESTURI Arguments: $ARGS Unique ID: $UNIQUEID RuleTriggered: $RULE \
Time: `date '+%D %H:%M'`" | mail -s "local server under attack" your_email@domain.com \
echo Done.

test_request_headers_and_send_detail_email.conf

SecRule REQUEST_HEADERS:User-Agent "FALSE-USER" "deny,log,id:'1234123499',setenv:SERVER=%{SERVER_ADDR}, \
setenv:REMOTEIP=%{REMOTE_ADDR},setenv:REQUESTURI=%{REQUEST_URI},setenv:ARGS=%{ARGS}, \
setenv:UNIQUEID=%{UNIQUE_ID},setenv:RULE=%{rule.id}, \
exec:/usr/share/modsecurity-crs/my_test_rules/send_alert_email_false-user.sh"

Monday, January 27, 2014

Integrating ModSecurity with ClamAV Antivirus

ClamAV is free opensource antivirus engine designed for detecting Trojans, viruses, malware and other malicious threats. Here in this article we will look at setting up clamAV in Ubuntu 14.04 LTS server, integrate it with Apache ModSecurity Firewall and scan the uploaded file through a web application.

Install ClamAV

    Install clamav and clamav-daemon from repo

    $ sudo apt-get install clamav clamav-daemon -y

Update clamav malware patterns

    $ sudo freshclam

Start clamav-daemon

    $ sudo /etc/init.d/clamav-daemon start


Add Anti-virus scanning rules in the ModSecurity

    Create a soft link to an Anti-virus rule file. i.e modsecurity_crs_46_av_scanning.conf

    # cd /usr/share/modsecurity-crs/activated_rules
    # ln -s ../optional_rules/modsecurity_crs_46_av_scanning.conf


    Edit configuration in the rule file modsecurity_crs_46_av_scanning.conf
    # nano modsecurity_crs_46_av_scanning.conf

    Here, edit the location of script in the "@inspectfile" operator.

    SecRule FILES_TMPNAMES "@inspectFile /usr/share/modsecurity-crs/util/av-scanning/runav.pl" \
    "phase:2,t:none,block,msg:'Virus found in uploaded    file',id:'950115',tag:'MALICIOUS_SOFTWARE/VIRUS',tag:'PCI/5.1',severity$


    Restart Apache2
    # service apache2 restart

Test the configuration by uploading a test virus file through the upload function of an web application hosted in the server. You can use EICAR test file if you dont want to take risk using real malicious files.
Check modsecurity log if ModSecurity is in DetectionOnly mode, else ModSecurity will do the default action set in the Active Mode. i.e 403 Forbidden error display

Note: File upload service might get little bit sluggish due to scanning task by ClamAV.

Thursday, January 23, 2014

Hiding Sensitive Data in Apache ModSecurity Log

We can hide the sensitive data from the audit log of the ModSecurity by using a "sanitiseArg" variable action for log.
Assuming that you have an application that uses the parameters password, oldPassword, and newPassword to transmit, we can write rule:

SecAction phase:5,nolog,pass,\
  sanitiseArg:password,\
  sanitiseArg:oldPassword,\
  sanitiseArg:newPassword

If you dont know the parameters name in advance then you can do something like this:

SecRule ARGS_NAMES password phase:5,nolog,pass,\
  sanitiseMatched

In the following example, we look for anything that resembles a credit card number and then sanitize it:

SecRule ARGS @verifyCC phase:5,nolog,pass,\
  sanitiseMatched

Here, "@verifyCC" is provided by modsecurity for detecting credit card pattern.

Monday, January 6, 2014

Custom Redirection in Apache ModSecurity WAF

We can redirect the user to a specific page when a specific rule get triggered. We can achieve this by directly modifying the original rule or by writing a custom rule which will update the actions of rules. The better way is to write a custom rule which will update the actions of a rule. A modsecurity directive "SecRuleUpdateActionById" will be used.

Syntax: SecRuleUpdateActionById

Example below:


#nano custom_rule_AV_redirect.conf

SecRuleUpdateActionById 950115 "redirect:http://www.technology.com/"
Here, Rule ID 950115  is an ID of modsecurity_crs_46_av_scanning.conf rule that is active.

We have to make symlink of this custom rule into the activation_rules directory of
 /usr/share/modsecurity-crs/ .

Redirecting all 403 status

If you want to set up the default redirection to all the 403 status coming through modsecurity then you can simple use "ErrorDocument" directive of Apache in the configuration file of your site in /etc/apache2/sites-enabled/

Syntax: ErrorDocument

Example:

ErrorDocument 403 https://www.owasp.org