A Tip A Day [:: ATAD ::]

Malicious code that was recently classified as a worm, surfaced in October 2008 and exploits  MS08-067 vulnerability in the Microsoft Windows family Operating System (surprise surprise !!). The worm is known by various names Downup, Downadup,  Kido, and the most popular being Conficker.

Conflicker has gone through various stages of development that make it harder to understand; credits to the use of P2P mechanism encrypting the traffic using the latest and greatest MIT MD6 algorithm. A noteworthy mention about the client on an infected machine is that, it uses an intelligent algorithm that creates a daily list of 250 random domain names to communicate with its mother ship that advertises different domain names each day. Guess what, it gets even better, the newer variant Conflicker. C just upped that number from 250 to 50,000.

What makes this one extra special is that no one seems to still know what its gonna do on “D day”. Experts guess that April 1 could probably be that D day, but we never know…

Let the guessing games continue; in the meantime, if you don’t have the habit of installing Microsoft Windows security fixes or keep you Windows auto update OFF, it’d be a good idea to get to the Symantec website and attempt a removal of a possible infection.

Cheers, and have a SAFE April 1.

__tipped__

[ also on vinaydeep.com via TechRepublic ]
-vinaydeep

The login program is used when signing onto a system. It can also be used to switch from one user to another at any time (most modern shells have support for this feature built into them, however).

If an argument is not given, login prompts for the username.

If the user is not root, and if /etc/nologin exists, the contents of this file are printed to the screen, and the login is terminated. This is typically used to prevent logins when the system is being taken down.

If special access restrictions are specified for the user in /etc/usertty, these must be met, or the log in attempt will be denied and a syslog message will be generated.

If the user is root, then the login must be occurring on a tty listed in /etc/securetty. Failures will be logged with the syslog facility. If the file does not exist, root is allowed to log in on any tty.

After these conditions have been checked, the password will be requested and checked (if a password is required for this username). Ten attempts are allowed before login dies, but after the first three, the response starts to get very slow. Login failures are reported via the syslog facility. This facility is also used to report any successful root logins.

If the file .hushlogin exists, then a “quiet” login is performed (this disables the checking of mail and the printing of the last login time and message of the day). Otherwise, if /var/log/lastlog exists, the last login time is printed (and the current login is recorded).

Random administrative things, such as setting the UID and GID of the tty are performed. The TERM environment variable is preserved, if it exists (other environment variables are preserved if the -p option is used). Then the HOME, PATH, SHELL, TERM, MAIL, and LOGNAME environment variables are set. PATH defaults to /usr/local/bin:/bin:/usr/bin for normal users, and to /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin for root. Last, if this is not a “quiet” login, the message of the day is printed and the file with the user’s name in /var/spool/mail will be checked, and a message printed if it has non-zero length.

The user’s shell is then started. If no shell is specified for the user in /etc/passwd, then /bin/sh is used. If there is no directory specified in /etc/passwd, then / is used (the home directory is checked for the .hushlogin file described above).

Further Reading: nologin, /etc/passwd, /etc/shadow, PAM Pluggable Authentication Modules

__tipped__

DNS exploits broadly fall in the category of cache poisoning (DNS spoofing where incorrect information is introduced in the DNS cache), client flooding (attacker floods false responses pretending to be a nameserver), dynamic update vulnerability (exploits weak authentication during zone updates between distributed nameservers), information leakage (attacker can extract internal information during zone transfers), and compromise of the DNS server’s authoritative database (attacker obtains administrative previlidges).

The most recent of the DNS expliots whose code can be found here, implements an intelligent cache poisoning algorithm.

The following topics could be of interest while considering DNS security

1. Carefully written named.conf
   - have DNS keys in a separate file and use the include statement to reference it.
   - backup your named.conf
   - use view and the match-clients statements to restrict information to limited clients.
2. Better designed zone updates
   - Use of TSIG (Transaction SIGnatures) or TKEY which allows a transfer from master to slave only after verifying that a shared secret key exists on both nameservers.
   - Use of Access Control Lists (ACLs) provided by BIND which allow simple IP address protection.
3. Cryptographically Signed Zones
   - Use of DNSSEC which allows for zones to be cryptographically signed with a zone key.This way, the information about a specific zone can be verified as coming from a nameserver that has signed it with a particular private key, as long as the recipient has that nameserver’s public key. This indeed would add considerable overhead but would prevent cache poisoning exploits.

If there is way to secure a system, some smart guy will invariably come up with a way to exploit an undiscovered vulnerability. These exploits, if not prevented, can atleast be curtailed by good system administration practices, regular system monitoring and updates.

Furthur Reading: DNS Security Extensions, DNS and BIND

__tipped__

Managing access to networking services on the system would be an important step in managing the system’s security. If you do not need to provide a network service, its best to turn it off. These services are usually managed by xinetd which offers a more secure extension to inetd

xinetd the eXtended InterNET Daemon is an open source daemon that is started on system bootup, and listens on ports designated in /etc/xinetd.conf for incoming network connections. When a new connection is made, xinetd starts up the corresponding network service.

Both the services managed by xinetd and the services in the /etc/rc.d/ directories (also known as SysV services) can be configured to start or stop using the following tools.

On Fedora

1. chkconfig

This is a command line utility that allows you to turn services on and off for the different runlevels. Non-xinetd services can not be started, stopped, or restarted using this utility (use service program instead).

2. Services Configuration Tool

This is a graphical application that displays a description of each service, displays whether each service is started at boot time (for runlevels 3, 4, and 5), and allows services to be started, stopped, and restarted.

3. ntsysv

This is a text-based application that allows you to configure which services are started at boot time for each runlevel. Non-xinetd services can not be started, stopped, or restarted using this program (use service program instead). ntsysv can also be used to configure runlevels.

On Debian

4. update-rc.d

update-rc.d automatically updates the System V style init script links under /etc/rcrunlevel.d/

5. rcconf

Text based GUI Runlevel configuration tool to add or remove services
Note: It would be prudent to modify firewall settings and policies while enabling/disabling services.

Furthur Reading: hosts_access, runlevels

Sources: [RedHat deployment guide, Wikipedia]

__tipped__

File permissions on linux are traditionally Read (r), Write (w), and Execute (x) permissions associated with users and groups. Providing appropriate permissions, especially as an ordinary user, is more often complicated than we think.

Let me illustrate this with an example. User “tom” creates a file named “hoohaha” and wants to give “dick” and “harry” permissions to read and execute it. Ofc this is fairly simple if dick and harry were exclusively part on one group. What if that group dosent exist? tom will have to ask the “already overloaded” system administrator to create a group consisting of just dick and harry. This, like you can see dosent sound too good.

To overcome this limitation, Linux has implemented support for Access Control Lists (ACLs). ACLs serve as an extension to traditional Unix permissions, giving end-users the ability to specify special access rights to a file and provide desired users and groups with appropriate permissions. To use ACLs you should have at least kernel version 2.6.x (some manual steps are required with older kernel versions), a filesystem that supports ACL, and additional user tools to create, view and modify ACLs. ext3 filesystems natively support ACLs, and support can be added to ext2 filesystem by performing some additional steps. ACL support is native on RHEL5, Fedora 9, Ubuntu Fiesty and SuSE 8.1 (there would be more).

The setfacl utility sets ACLs for files and directories, and getfacl can be used to determine the existing ACLs for a file or directory. The cp and mv commands do preserve the ACLs. tar and dump dont, so use star instead.

tom $ getfacl hoohaha
# file: hoohaha
# owner: tom
# group: tom
user::rwx
group::r–
other::r–

The requirement is realized when tom sets ACLs for the file hoohaha
tom $ setfacl -m user:dick:rx hoohaha
tom $ setfacl -m user:harry:rx hoohaha

__tipped__