BackTrack Linux

BackTrack is the most top rated linux live distribution focused on penetration testing. With no installation whatsoever, the analysis platform is started directly from the CD-Rom and is fully accessible within minutes.

It's evolved from the merge of the two wide spread distributions - Whax and Auditor Security Collection. By joining forces and replacing these distributions, BackTrack has gained massive popularity and was voted in 2006 as the #1 Security Live Distribution by insecure.org. Security professionals as well as new-comers are using BackTrack as their favorite toolset all over the globe.

BackTrack has a long history and was based on many different linux distributions until it is now based on a Slackware linux distribution and the corresponding live-CD scripts by Tomas M. (www.slax.org) . Every package, kernel configuration and script is optimized to be used by security penetration testers. Patches and automation have been added, applied or developed to provide a neat and ready-to-go environment.

After coming into a stable development procedure during the last releases and consolidating feedbacks and addition, the team was focused to support more and newer hardware as well as provide more flexibility and modularity by restructuring the build and maintenance processes. With the current version, most applications are built as individual modules which help to speed up the maintenance releases and fixes.

Because Metasploit is one of the key tools for most analysts it is tightly integrated into BackTrack and both projects collaborate together to always provide an on-the-edge implementation of Metasploit within the BackTrack CD-Rom images or the upcoming remote-exploit.org distributed and maintained virtualization images (like VMWare images appliances).

Being superior while staying easy to use is key to a good security live cd. We took things a step further and aligned BackTrack to penetration testing methodologies and assessment frameworks (ISSAF and OSSTMM). This will help our professional users during their daily reporting nightmares.

Currently BackTrack consists of more than 300 different up-to-date tools which are logically structured according to the work flow of security professionals. This structure allows even newcomers to find the related tools to a certain task to be accomplished. New technologies and testing techniques are merged into BackTrack as soon as possible to keep it up-to-date.

Execute Disable Bit

The challenge

Malicious buffer overflow attacks pose a significant security threat to businesses, increasing IT resource demands, and in some cases destroying digital assets. In a typical attack, a malicious worm creates a flood of code that overwhelms the processor, allowing the worm to propagate itself to the network, and to other computers. These attacks cost businesses precious productivity time, which can equal significant financial loss.

The solution

Intel's Execute Disable Bit¹ functionality can help prevent certain classes of malicious buffer overflow attacks when combined with a supporting operating system.

Execute Disable Bit allows the processor to classify areas in memory by where application code can execute and where it cannot. When a malicious worm attempts to insert code in the buffer, the processor disables code execution, preventing damage and worm propagation.

Replacing older computers with Execute Disable Bit-enabled systems can halt worm attacks, reducing the need for virus-related repairs. In addition, Execute Disable Bit may eliminate the need for software patches aimed at buffer overflow attacks. By combining Execute Disable Bit with anti-virus, firewall, spyware removal, e-mail filtering software, and other network security measures, IT managers can free IT resources for other initiatives.

Passwords and More Authentication Fun

Often, while my students are working on a lab, I’ll take this time to search for more class demos. It seems that many of the demos we discuss in class soon get fixed. I’m not sure how or why, but this is often the case. Parameter manipulation — they’re all fixed within a few weeks of discussing them in class. The list goes on, but this is so frequent that I stopped tracking them. Regardless of the reasons, these vulnerabilities get fixed, and I’m glad they do. And I really don’t mind doing some basic research into finding more. So here’s today’s example, as it applies to password policy and authentication fun.

I’ll start off by listing some common authentication-related vulnerabilities I often see and then discuss some error messages I recently found on a popular travel site. I’ll also add some “malicious” ideas, just for fun–to get you thinking.

Common authentication-related vulnerabilities:

• Password policy is weak
• Password policy is strong, but not enforced
• No account lock out (or worse, account lockout tracked at the client side)
• Login error messages let me know whether the username is valid
• Password hints!

Related error messages from a recent find at a travel site:

• “A password must be 5-12 characters long and have no spaces.”–when registering an account.
• “The e-mail and password you have entered do not match. Please try again.”–when attempting to log in with an invalid username or password.
• “That e-mail address is not on file. Please try again.”–when attempting to display the password hint for an invalid account.
• Note: the password hint is happily displayed if you enter a valid username.

Some initial thoughts

• How easy is it to harvest emails or buy a few million email addresses?
• Could a quick script cycle through a list of email addresses and capture password hints?
• How difficult would it be to guess a few password hints based on several hundred or thousand captured password hints?
• This site allows you to save a credit card on file and use it to book travel/hotels/more without verifying anything.
• I wonder if I could book travel on someone else’s account without them knowing. All I need to do is suppress the email confirmation or point their registered email to a different one. By the time the con has been exposed, the postcards I sent from Mexico will have been received.

Do you see where this is going? The main culprit wasn’t the password policy itself. If I had to write the equation, it would look a lot like this (seriously):

Mediocre password policy + password hints + stored credit card info + having a lot of users + nongeneric error messages + not verifying anything on checkout = free trip to Mexico.

Now, let’s go cliff diving in Acapulco!

Microsoft Internet Information Services Vulnerability Gives Complete Server Control

Microsoft has confirmed a vulnerability in its Internet Information Services webserver and spelled out the conditions under which it can be exploited to give an attacker complete control of the server on which it runs.

Remote execution of malicious code can be triggered only in limited cases, and even then, it’s relatively easy to change settings that close that possibility. Even then, exploits can still touch off denial-of-service attacks that completely shut down file transfer protocol.

Proof-of-concept code exploiting the vulnerability was released Monday. Microsoft said it will release a fix as soon as it’s ready.

The vulnerability can be exploited only if IIS is configured to allow FTP and untrusted users have the ability to create their own directories. Users of IIS on Windows 2000 and Windows Small Business Server 2003 face the biggest threat because FTP is enabled by default, but even then, users aren’t given write access unless settings have been changed.

In that case, or in cases where users of version 5.1 have turned on FTP and write access, attackers can gain complete control over servers by listing directories with specially manipulated names that trigger a buffer overflow in the application.

Users of IIS6 also face the possibility of DoS attacks, but because the application was built using a compiler setting that automatically terminates applications that have been attacked, remote execution is a much more remote possibility, Microsoft said. IIS7, because it runs on the more secure Vista and Server 2008 versions of Windows, is not vulnerable.

For those at risk, Microsoft recommends the following workarounds until a patch is released:

Turn off FTP if it’s not needed

Disable the creation of new directories

Disable the ability for anonymous users to write using IIS settings

Microsoft said its working with providers of intrusion prevention systems so they can identify attacks. Meanwhile, admins can detect attacks by reviewing log files.

Hardening the TCP/IP stack to SYN attacks-part 1

Most people know how problematic protection against SYN denial of service attacks can be. Several methods, more or less effective, are usually used. In almost every case proper filtering of packets is a viable solution. In addition to creating packet filters, the modification of the TCP/IP stack of a given operating system can be performed by an administrator. This method, the tuning of the TCP/IP stack in various operating systems, will be described in depth in this article.

While SYN attacks may not be entirely preventable, tuning the TCP/IP stack will help reduce the impact of SYN attacks while still allowing legitimate client traffic through. It should be noted that some SYN attacks do not always attempt to upset servers, but instead try to consume all of the bandwidth of your Internet connection. This kind of flood is outside the scope of scope of this article, as is the filtering of packets which has been discussed elsewhere.

What can an administrator do when his servers are under a classic, non-bandwidth flooding SYN attack? One of most important steps is to enable the operating system's built-in protection mechanisms like SYN cookies or SynAttackProtect. Additionally, in some cases it is worth tuning parameters of the TCP/IP stack. Changing the default values of stack variables can be another layer of protection and help better secure your hosts. In this paper I will concentrate on:

.Increasing the queue of half-open connections (in the SYN RECEIVED state).
.Decreasing the time period of keeping a pending connection in the SYN RECEIVED state in the queue. This method is accomplished by decreasing the time of the first packet retransmission and by either decreasing the number of packet retransmissions or by turning off packet retransmissions entirely. The process of packet retransmissions is performed by a server when it doesn't receive an ACK packet from a client. A Packet with the ACK flag finalizes the process of the three-way handshake.

Note that an attacker can simply send more packets with the SYN flag set and then the above tasks will not solve the problem. However, we can still increase the likelihood of creating a full connection with legitimate clients by performing the above operations.

We should remember that our modification of variables will change the behavior of the TCP/IP stack. In some cases the values can be too strict. So, after the modification we have to make sure that our server can properly communicate with other hosts. For example, the disabling of packet retransmissions in some environments with low bandwidth can cause a legitimate request to fail. In this article you will find a description of the TCP/IP variables for the fallowing operating systems: Microsoft Windows 2000, RedHat Linux 7.3, Sun Solaris 8 and HP-UX 11.00. These variables are similar or the same in current releases.

Definitions: SYN flooding and SYN spoofing

A SYN flood is a type of Denial of Service attack. We can say that a victim host is under a SYN flooding attack when an attacker tries to create a huge amount of connections in the SYN RECEIVED state until the backlog queue has overflowed. The SYN RECEIVED state is created when the victim host receives a connection request (a packet with SYN flag set) and allocates for it some memory resources. A SYN flood attack creates so many half-open connections that the system becomes overwhelmed and cannot handle incoming requests any more.

To increase an effectiveness of a SYN flood attack, an attacker spoofs source IP addresses of SYN packets. In this case the victim host cannot finish the initialization process in a short time because the source IP address can be unreachable. This malicious operation is called a SYN spoofing attack.

We need to know that the process of creating a full connection takes some time. Initially, after receiving a connection request (a packet with SYN flag set), a victim host puts this half-open connection to the backlog queue and sends out the first response (a packet with SYN and ACK flags set). When the victim does not receive a response from a remote host, it tries to retransmit this SYN+ACK packet until it times out, and then finally removes this half-open connection from the backlog queue. In some operating systems this process for a single SYN request can take about 3 minutes! In this document you will learn how to change this behavior. The other important information you need to know is that the operating system can handle only a defined amount of half-open connections in the backlog queue. This amount is controlled by the size of the backlog queue. For instance, the default backlog size is 256 for RedHat 7.3 and 100 for Windows 2000 Professional. When this size is reached, the system will no longer accept incoming connection requests.

How to detect a SYN attackIt is very simple to detect SYN attacks. The netstat command shows us how many connections are currently in the half-open state. The half-open state is described as SYN_RECEIVED in Windows and as SYN_RECV in Unix systems.

# netstat -n -p TCP

tcp 0 0 10.100.0.200:21 237.177.154.8:25882 SYN_RECV -
tcp 0 0 10.100.0.200:21 236.15.133.204:2577 SYN_RECV -
tcp 0 0 10.100.0.200:21 127.160.6.129:51748 SYN_RECV -
tcp 0 0 10.100.0.200:21 230.220.13.25:47393 SYN_RECV -
tcp 0 0 10.100.0.200:21 227.200.204.182:60427 SYN_RECV -
tcp 0 0 10.100.0.200:21 232.115.18.38:278 SYN_RECV -
tcp 0 0 10.100.0.200:21 229.116.95.96:5122 SYN_RECV -
tcp 0 0 10.100.0.200:21 236.219.139.207:49162 SYN_RECV -
tcp 0 0 10.100.0.200:21 238.100.72.228:37899 SYN_RECV -
...
We can also count how many half-open connections are in the backlog queue at the moment. In the example below, 769 connections (for TELNET) in the SYN RECEIVED state are kept in the backlog queue.

# netstat -n -p TCP grep SYN_RECV grep :23 wc -l
769

The other method for detecting SYN attacks is to print TCP statistics and look at the TCP parameters which count dropped connection requests. While under attack, the values of these parameters grow rapidly.

In this example we watch the value of the TcpHalfOpenDrop parameter on a Sun Solaris machine.

# netstat -s -P tcp grep tcpHalfOpenDrop
tcpHalfOpenDrop = 473

It is important to note that every TCP port has its own backlog queue, but only one variable of the TCP/IP stack controls the size of backlog queues for all ports.

The backlog queueThe backlog queue is a large memory structure used to handle incoming packets with the SYN flag set until the moment the three-way handshake process is completed. An operating system allocates part of the system memory for every incoming connection. We know that every TCP port can handle a defined number of incoming requests. The backlog queue controls how many half-open connections can be handled by the operating system at the same time. When a maximum number of incoming connections is reached, subsequent requests are silently dropped by the operating system.

As mentioned before, when we detect a lot of connections in the SYN RECEIVED state, host is probably under a SYN flooding attack. Moreover, the source IP addresses of these incoming packets can be spoofed. To limit the effects of SYN attacks we should enable some built-in protection mechanisms. Additionally, we can sometimes use techniques such as increasing the backlog queue size and minimizing the total time where a pending connection in kept in allocated memory (in the backlog queue).

Worldsecure VPN Account Registration

Do you need a vpn connection to your company or internet !?
Do you need to download via fast internet connection?!
Do you need a secure connection to buy your products with credit or debit card !?

For registration please contact with worldsecure@hotmail.com.uk .

Server Virtualization

What is virtualization and why use it

Virtualization is a method of running multiple independent virtual operating systems on a single physical computer. It is a way of maximizing physical resources to maximize the investment in hardware. Since Moore's law has accurately predicted the exponential growth of computing power and hardware requirements for the most part have not changed to accomplish the same computing tasks, it is now feasible to turn a very inexpensive 1U dual-socket dual-core commodity server into eight or even 16 virtual servers that run 16 virtual operating systems. Virtualization technology is a way of achieving higher server density. However, it does not actually increase total computing power; it decreases it slightly because of overhead. But since a modern $3,000 2-socket 4-core server is more powerful than a $30,000 8-socket 8-core server was four years ago, we can exploit this newly found hardware power by increasing the number of logical operating systems it hosts. This slashes the majority of hardware acquisition and maintenance costs that can result in significant savings for any company or organization.

When to use virtualization

Virtualization is the perfect solution for applications that are meant for small- to medium-scale usage. Virtualization should not be used for high-performance applications where one or more servers need to be clustered together to meet performance requirements of a single application because the added overhead and complexity would only reduce performance. We're essentially taking a 12 GHz server (four cores times three GHz) and chopping it up into 16 750 MHz servers. But if eight of those servers are in off-peak or idle mode, the remaining eight servers will have nearly 1.5 GHz available to them.
While some in the virtualization industry like to tout high CPU utilization numbers as an indication of optimum hardware usage, this advice should not be taken to the extreme where application responsiveness gets excessive. A simple rule of thumb is to never let a server exceed 50% CPU utilization during peak loads; and more importantly, never let the application response times exceed a reasonable SLA (Service Level Agreement). Most modern servers being used for in-house server duties are utilized from 1 to 5% CPU. Running eight operating systems on a single physical server would elevate the peak CPU utilization to around 50%, but it would average much lower since the peaks and valleys of the virtual operating systems will tend to cancel each other out more or less.
While CPU overhead in most of the virtualization solutions available today are minimal, I/O (Input/Output) overhead for storage and networking throughput is another story. For servers with extremely high storage or hardware I/O requirements, it would be wise to run them on bare metal even if their CPU requirements can be met inside a Virtual environment. Both XenSource and Virtual Iron (which will soon be Xen Hypervisor based) promise to minimize I/O overhead, yet they're both in beta at this point, so there haven't been any major independent benchmarks to verify this.

How to avoid the "all your eggs in one basket" syndrome

One of the big concerns with virtualization is the "all your eggs in one basket" syndrome. Is it really wise to put all of your critical servers into a single physical server? The answer is absolutely not! The easiest way to avoid this liability is to make sure that a single service isn't only residing on a single server. Let's take for example the following server types:
HTTP
FTP
DNS
DHCP
RADIUS
LDAP
File Services using Fiber Channel or iSCSI storage
Active Directory services
We can put each of these types of servers on at least two physical servers and gain complete redundancy. These types of services are relatively easy to cluster because they're easy to switch over when a single server fails. When a single physical server fails or needs servicing, the other virtual server on the other physical server would automatically pick up the slack. By straddling multiple physical servers, these critical services never need to be down because of a single hardware failure.
For more complex services such as an Exchange Server, Microsoft SQL, MySQL, or Oracle, clustering technologies could be used to synchronize two logical servers hosted across two physical servers; this method would generally cause some downtime during the transition, which could take up to five minutes. This isn't due to virtualization but rather the complexity of clustering which tends to require time for transitioning. An alternate method for handling these complex services is to migrate the virtual server from the primary physical server to the secondary physical server. In order for this to work, something has to constantly synchronize memory from one physical server to the other so that a failover could be done in milliseconds while all services can remain functional.

Physical to virtual server migration

Any respectable virtualization solution will offer some kind of P2V (Physical to Virtual) migration tool. The P2V tool will take an existing physical server and make a virtual hard drive image of that server with the necessary modifications to the driver stack so that the server will boot up and run as a virtual server. The benefit of this is that you don't need to rebuild your servers and manually reconfigure them as a virtual server—you simply suck them in with the entire server configuration intact!
So if you have a data center full of aging servers running on sub-GHz servers, these are the perfect candidates for P2V migration. You don't even need to worry about license acquisition costs because the licenses are already paid for. You could literally take a room with 128 sub-GHz legacy servers and put them into eight 1U dual-socket quad-core servers with dual-Gigabit Ethernet and two independent iSCSI storage arrays all connected via a Gigabit Ethernet switch. The annual hardware maintenance costs alone on the old server hardware would be enough to pay for all of the new hardware! Just imagine how clean your server room would look after such a migration. It would all fit inside of one rack and give you lots of room to grow.
As an added bonus of virtualization, you get a disaster recovery plan because the virtualized images can be used to instantly recover all your servers. Ask yourself what would happen now if your legacy server died. Do you even remember how to rebuild and reconfigure all of your servers from scratch? (I'm guessing you're cringing right about now.) With virtualization, you can recover that Active Directory and Exchange Server in less than an hour by rebuilding the virtual server from the P2V image.

Patch management for virtualized servers

Patch management of virtualized servers isn't all that different with regular servers because each virtual operating system is its own independent virtual hard drive. You still need a patch management system that patches all of your servers, but there may be interesting developments in the future where you may be able to patch multiple operating systems at the same time if they share some common operating system or application binaries. Ideally, you would be able to assign a patch level to an individual or a group of similar servers. For now, you will need to patch virtual operating systems as you would any other system, but there will be some innovations in the virtualization sector that you won't be able to do with physical servers.

Licensing and support considerations

A big concern with virtualization is software licensing. The last thing anyone wants to do is pay for 16 copies of a license for 16 virtual sessions running on a single computer. Software licensing often dwarfs hardware costs, so it would be foolish to run a $20,000 software license on a machine on a shared piece of hardware. In this situation, it's best to run that license on the fastest physical server possible without any virtualization layer adding overhead.
For something like Windows Server 2003 Standard Edition, you would need to pay for each virtual session running on a physical box. The exception to this rule is if you have the Enterprise Edition of Windows Server 2003, which allows you to run four virtual copies of Windows Server 2003 on a single machine with only one license. This Microsoft licensing policy applies to any type of virtualization technology that is hosting the Windows Server 2003 guest operating systems.
If you're running open source software, you don't have to worry about licensing because that's always free—what you do need to be concerned about is the support contracts. If you're considering virtualizing open source operating systems or open source software, make sure you calculate the support costs. If the support costs are substantial for each virtual instance of the software you're going to run, it's best to squeeze the most out of your software costs by putting it on its own dedicated server. It's important to remember that hardware is often dwarfed by software licensing and/or support costs. The trick is to find the right ratio of hardware to licensing/support costs. When calculating hardware costs, be sure to calculate the costs of hardware maintenance, power usage, cooling, and rack space.