Security – IndianGNU.org

Shellshock ‘Deadly serious’ new tech bug found!

By Ravi Bhure | September 26, 2014 | Comments 0 Comment

This issue affects all products which use the Bash shell and parse values of environment variables. This issue is especially dangerous as there are many possible ways Bash can be called by an application. Quite often if an application executes another binary, Bash is invoked to accomplish this. Because of the pervasive use of the Bash shell, this issue is quite serious and should be treated as such.

All versions prior to those listed as updates for this issue are vulnerable to some degree.

My infected OS version is CentOS-6 and bash version 4.1.2

[root@host75 ~]# lsb_release -a lsb_release -a LSB Version: :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch Distributor ID: CentOS Description: CentOS release 6.4 (Final) Release: 6.4 Codename: Final

[root@host75 ~]# bash --version bash --version GNU bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later

This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.

Diagnostic Steps:

To test if your version of Bash is vulnerable to this issue, run the following command:

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

If the output of the above command looks as follows:

vulnerable this is a test

hmm, I got infected!

[root@host75 ~]# env x='() { :;}; echo vulnerable' bash -c "echo this is a test" vulnerable this is a test

You are using a vulnerable version of Bash. The patch used to fix this issue ensures that no code is allowed after the end of a Bash function. Thus, if you run the above example with the patched version of Bash, you should get an output similar to:

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test" bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x' this is a test

If your system is vulnerable, update to the most recent version of the Bash package by running the following command:

$yum update bash

This fix my bash ??????

[root@host75 ~]# yum update bash Loaded plugins: fastestmirror, security, tmprepo Loading mirror speeds from cached hostfile epel/metalink | 15 kB 00:00 * base: centos.eecs.wsu.edu * epel: mirrors.kernel.org * extras: centos.chi.host-engine.com * updates: mirror.raystedman.net base | 3.7 kB 00:00 epel | 4.4 kB 00:00 epel/primary_db | 6.3 MB 00:05 extras | 3.3 kB 00:00 updates | 3.4 kB 00:00 updates/primary_db | 5.3 MB 00:04 Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package bash.x86_64 0:4.1.2-14.el6 will be updated ---> Package bash.x86_64 0:4.1.2-15.el6_5.1 will be an update --> Finished Dependency Resolution


Dependencies Resolved
================================================================================================================================================

 Package                       Arch                            Version                                   Repository                        Size

================================================================================================================================================

Updating:

 bash                          x86_64                          4.1.2-15.el6_5.1                          updates                          905 k
Transaction Summary

================================================================================================================================================

Upgrade       1 Package(s)
Total download size: 905 k

Is this ok [y/N]: y

Downloading Packages:

bash-4.1.2-15.el6_5.1.x86_64.rpm                                                                                         | 905 kB     00:00

Running rpm_check_debug

Running Transaction Test

Transaction Test Succeeded

Running Transaction

  Updating   : bash-4.1.2-15.el6_5.1.x86_64                                                                                                 1/2

  Cleanup    : bash-4.1.2-14.el6.x86_64                                                                                                     2/2

  Verifying  : bash-4.1.2-15.el6_5.1.x86_64                                                                                                 1/2

  Verifying  : bash-4.1.2-14.el6.x86_64                                                                                                     2/2
Updated:

  bash.x86_64 0:4.1.2-15.el6_5.1

Complete!

Test if update fixed to patch your bash

[root@host75 ~]# env x='() { :;}; echo vulnerable' bash -c "echo this is a test" bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x' this is a test

How does this impact systems:
This issue affects all products which use the Bash shell and parse values of environment variables. This issue is especially dangerous as there are many possible ways Bash can be called by an application. Quite often if an application executes another binary, Bash is invoked to accomplish this. Because of the pervasive use of the Bash shell, this issue is quite serious and should be treated as such.

All versions prior to those listed as updates for this issue are vulnerable to some degree.

See the appropriate remediation article for specifics.

Functions written in Bash itself do not need to be changed, even if they are exported with “export -f”. Bash will transparently apply the appropriate naming when exporting, and reverse the process when importing function definitions.

Ref:
http://www.bbc.com/news/technology-29361794
https://www.us-cert.gov/ncas/current-activity/2014/09/24/Bourne-Again-Shell-Bash-Remote-Code-Execution-Vulnerability
https://access.redhat.com/articles/1200223
https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/
http://lists.gnu.org/archive/html/bug-bash/2014-09/threads.html
https://rhn.redhat.com/errata/RHSA-2014-1306.html

How to use TCP Wrappers for system security

By Manoj Chauhan | February 22, 2010 | Comments 0 Comment

Introduction:-

Access control to services compiled with TCP wrappers support is implemented by the /etc/hosts.allow and /etc/hosts.deny files. When a connection attempt is made, the hosts.allow file is checked. If a line is matched, the connection is allowed. Then the hosts.deny file is consulted, if a line is matched, the connection is denied. If no matches have occurred in either file, the connection is allowed.

Create Authorized Use Only Banners–

If configured as described below, TCP wrappers will display a warning banner to any user attempting to connect to a service it monitors. The following set of commands generate the directory /etc/banners, and the files therein contain warning banner text for each service. In this example, the banner text is “Use of this system is restricted to authorized users.” Note that exact wording of a warning banner is site specific; however, it should at least emphasize that the use of the system is restricted to authorized persons and that consent to monitor activities is implied by logging in to the system.

[root@localhost]# /bin/mkdir -p /etc/banners
[root@localhost]# /bin/echo “Use of this system is restricted to authorized users” > /etc/banners/
prototype
[root@localhost]# cd /etc/banners ; /usr/bin/make -f /usr/share/doc/tcp_wrappers-7.6/Banners.Makefile

Deny Everything Except What is Explicitly Allowed–

In order to implement the security best practice stance of deny everything except what is explicitly allowed, issue the following command.
[root@localhost]# echo ‘ALL: ALL: spawn (/bin/echo -e ‘/bin/date'”\n%c attempted connection to %s
and was denied” \
> | /bin/mail -s “Connection attempt to %s” root) &’ > /etc/hosts.deny

Any connection attempt not listed in the hosts.allow file will be denied, a message will be logged to the syslog auth facility, and an email will be sent to root.
Allow Access to Those Who Require It

Edit the hosts.allow file and add a line for each service to which access should be allowed. A few examples are shown below (See the man pages for hosts.allow for more detail).

ALL: LOCAL : banners /etc/banners # All services from local clients (hostnames with no “.”)
sshd: 10.1.1.0/255.255.254.0 : banners /etc/banners # SSH connections from host IP addresses between 10.1.1.0 and 10.1.2.0

Thanks
Manoj Chauhan

Good practices for apache & php

By Manoj Chauhan | February 19, 2010 | Comments 1 comment

Introduction –

To conclude the discussion about session management, here are some best practices to demonstrate that a robust scheme requires serious thinking:
•   Create a session token upon first visit.
•   When performing authentication, destroy the old session and create a new one.
•   Limit session lifetime to a short period (a few hours).
•   Destroy inactive sessions regularly.
•   Destroy sessions after users log out.
•   Ask users to re-authenticate before an important task is performed (e.g., an order is placed).
•   Do not use the same session for a non-SSL part of the site as for the SSL part of the site because non-SSL traffic can be intercepted and the session token obtained from it. Treat them as two different servers.
•   If cookies are used to transport session tokens in an SSL application, they should be marked “secure.” Secure cookies are never sent over a non-SSL connection.
•   Regenerate session tokens from time to time.
•   Monitor client parameters (IP address, the User-Agent request header) and send warnings to the error log when they change. Some information (e.g., the contents of the User-Agent header) should not change for the lifetime of a session. Invalidate the session if it does.
•   If you know where your users are coming from, attach each session to a single IP address, and do not allow the address to change.
•   If you can, do not accept users coming through web proxies. This will be difficult to do for most public sites but easier for internal applications.
•   If you can, do not accept users coming through open web proxies. Open proxies are used when users want to stay anonymous or otherwise hide their tracks. You can detect which proxies are open by extracting the IP address of the proxy from each proxied request and having a script automatically test whether the proxy is open or not.
•   If you do allow web proxies, consider using Java applets or Flash movies (probably a better choice since such movies can pretend to be regular animations) to detect the users’ real IP addresses. It’s a long shot but may work in some cases.
•   Web users can upload only jpeg, gif, png files not php extension
•   We can place a blank index page in each directory in question and users can not execute php etc scripts from the image folders or image/document upload folders.
•   Upgrade apache current version (2.0) to newer version (2.2)

Thanks
Manoj Chauhan

Installing and configuring SSHD Filter

By Suhail Thakur | January 16, 2008 | Comments 2 comments

Introduction – SSHDFilter is open source tool by which we can manage SSH service effectively and we can secure our system from brute force attack. This tools will block brute force attack by using IPtables.

You can downaload the sshdfilter from the following location http://www.csc.liv.ac.uk/~greg/sshdfilter/ and then untar the tar.gz file…

#wget -c http://www.csc.liv.ac.uk/~greg/sshdfilter-1.5.5.tar.gz
#tar xvzf sshdfilter-1.5.5.tar.gz
#cd sshdfilter-1.5.5

1] Decide which linux distribution .partconf file you need to use –

rh7390 – RedHat 7.3, RedHat 9.0, Fedora Core 2.0 or CentOS 4.3
rhFC30 – RedHat Fedora Core 3.0, Fedora Core 4.0, Red Hat Enterprise Linux ES release 4, or CentOS 3.x
deb31 – Debian 3.1 (sarge) or Debian (sid, but see README.debian)
su10rc1 – SuSe 10.0 RC 1, Gentoo and Slackware
dbear – Dropbear, a light weight sshd daemon

(Our distribution was Fedora 5 so we selected rhFC30)

#cat etc/sshdfilterrc patterns/rhFC30.partconf > /etc/sshdfilterrc

2] Edit /etc/sshdfilterrc to suit your needs –

make sure that below two rules are uncommented, These are the blocking and unblocking rules.

#vi /etc/sshdfilterrc

firewalladd=’iptables -A $chain -p tcp -s $ip –dport 22 -j DROP’
firewalldel=’iptables -D $chain -p tcp -s $ip –dport 22 -j DROP’

Set the CHAIN –
chain=’SSHD’
If you would like to set a mailer you can set it from here:
#mail=’mail -s \”sshdfilter event for $ip, $event\” greg\@abatis.flint’
Set the sshd path, from where the sshd daemon is or will be running :-
sshdpath=’/usr/sbin/sshd’
Now comes the main part of setting the user Policy : this will define the number of attempts that should be allowed and what is to be done after the number of failures, These are the policies through which we can block the unwanted ssh attacks –

(At present we have set the following policies )
4,3d=INVALID
2,5d=’^root$’
4,3d=’^magnet$’
0,8d=NOID
The First Policy “4,3d=INVALID” defines , if any person trying to ssh to the server with an invalid username, after 4 attempts , his name will get inserted into the iptables SSHD chain and he will get blocked for 3 days.
The Second Policy ” 9,3d=’^root$’ ” defines, if any peroson tries to ssh the server with root as the user, after 2 unsuccessfull attempts, his name will get inserted into iptables and he will be blocked for 5 days.
The Third Policy ” 4,3d=’^magnet$’ ” is similiar to the second one, If any person, trying to ssh the server with magnet as the user, after 4 unsuccessfull attempts, his name will get inserted into iptables and he will be blocked for 3 days. Please note, Here magnet is one of the users on the server, You can mention the users of your server.
The Fourth Policy ” 0,8d=NOID ” defines, Catch and block all No ssh id events, instant block for 8 days.

You can add more policies to the policy section, the specifications are mentioned in the file.
Once the policies and settings have been done, save and exit the file.

3] Add the SSHD chain to your iptables firewall setup –

#iptables -N SSHD

#/etc/init.d/iptables save

4] Add a jump to SSHD rule with something like –

# iptables -A INPUT -p tcp -m tcp –dport 22 -j SSHD

copy sshdfilter.pl to /usr/sbin/sshdfilter, or maybe /usr/local/sbin/sshdfilter –

#cp source/sshdfilter.pl /usr/sbin/sshdfilter

Copy the man pages sshdfilter.1 and sshdfilterrc.5 to /usr/share/man/man{1,5} respectively –

#cp man/sshdfilter.1 /usr/share/man/man1/
#cp man/sshdfilterrc.5 /usr/share/man/man5/

Then copy the sshdfilter and sshd file to /etc/init.d/sshdfilter and start services…
(Before doing the above step, Please ensure to take a backupof the original sshd file)

#cp etc/init.d/sshdfilter /etc/init.d/
#cp etc/init.d/sshd.rhFC30 /etc/init.d/sshd
#/etc/init.d/sshdfilter start
#/etc/init.d/sshd restart

5] To confirm that sshdfilter is running –

# ps -aux | grep ssh
/usr/bin/perl /usr/sbin/sshdfilter
/usr/sbin/sshd -e -D

You should be seeing some output like the above one, that is the sshdfilter process and the sshd should be running with the -e and -D options.

If you see the above outputs, the installation is complete and you are done with SSHD, you can now try doing some ssh attacks to your server.

6] You can check the logs in –

#tail -f /var/log/secure OR
#tail -f /var/log/messages

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Hope this tutorial was helpful to you, we would like to have some feedbacks from you.
Please feel free to mail.

Thank You,
Magnet Systems Team

Denial of Service (DoS)

By Arun Bagul | December 31, 2007 | Comments 0 Comment

Introduction –

Denial of Service (DoS) attack is an attack in which one user takes up so much or maximum resources that none of the resources is left for other users. Denial of services (DOS) attack compromise the availability of resources. Those resources can be processes, disk space, % of CPU, Printer paper, modems or time of a harried system administration. UNIX can limit users to allow maximum number of files and processes.

There are two types of DoS-

Attack attempts to damage or destroy resources
Attack which overloads some system services or exhausts some recourses

Network Denial of services attacks –

Network DoS prevents legitimate users from using network. There three comon network DoS.

Service Overloading
Message flooding
Single Grounding

1) Service Overloading –
Occurs when floods of network request are made to a server daemon on a single computer. So that the machine is busy servicing interrupt requests and network packets that is unable to process regular tasks in a timely fashion.

2) Message flooding –

Program that answers network request in the server’s place for eq. client/user program which issue his own replies for network request.

3) Single Grounding –

The grounding the signal on network cable, introducing some other signal or removing an ethernet terminator all have the effect of preventing client from transmitting or receiving messages until the problem fixed.

Thank you,

Arun Bagul

Automation using Macro tools

By Santhosh Tirunahari | January 16, 2007 | Comments 0 Comment

Introduction – Automation means making the manual work fully automatic. Any (repeating) manual work on computer applications can be automated using some software. Now I am going to explain the usage of macro tools to perform automation….

I found many automation tools are available to write the automation scripts and run to perform the repeated task. On them I found Imacro Player is one of the best automation tool. Imacro tools can help you for easy web automation in effective manner.
This is used for web applications automation. And will not work for windows based application. For windows based Automation Anywhere is the powerful software, which will create macro on windows. It will run fast and accuratly. Automation Anywhere got many features so that macro can work in network too…

** One of the good advantage is we can use imacro with different programming languages with out any problem. Automation anywhere supporst VB, VC++.

imacro

Thank you,
Santhosh Tirunahari