A practical application of evolutionary biology in information security is found looking specifically at the evolution of a common Internet attack. Selection pressures were previously examined here at a high level, but SSH brute force attacks provide a more practical example of directional selection pressures. Directional selection pressures act to move a character or strategy in a specific direction.
SSH attacks are simply result of taking a list of accounts with common passwords and trying all of the username/password combinations to see if any of them allow access into a system. Early attempts simply tried to supply all of the combinations as fast as possible to determine if there was a valid combination present. Applications such as denyhosts, fail2ban, and sshguard exist to detect brute force attempts and ban those IP addresses from trying to access the server.
At a high level the counter strategy employed to prevent successful brute force attempts on a system implements a rule similar to the following: If a number of unsuccessful login attempts are detected within a short period of time; block all connection attempts from that address for an extended period. This rule acts as a directional selection pressure in that it forces attackers that are using the brute force strategy in a specific direction by controlling the login attempt frequency and number of source IP addresses.
Beginning in May of 2008 through December 2008 and into January of this year, there were reports of a newer Slow/Low-key Brute force attempts from various BotNets. With these newer attacks, the attack strategies were modified such that they are occurring at a much slower rate and occurring from various source addresses. In deed, upon inspection of the rules that were implemented to counter the attack, as they were acting as a directional selection pressures, it should have been expected to see a response in the attack strategies as they evolved in reaction to the selection pressures.
The SSH brute force detection rules have two principle components which act on the attack in as a selection pressure in a directional manner; the number of failed attempts per period and the source IP addresses. Only attacks which slowed their rate (in response to the failed attempts per period directional selection pressure) and distributed their attacks (in response to the source IP address selection pressure) could be expected to have a reasonable chance of being able to get through their account/password dictionaries.
It is possible that an attacker could have modified their strategy in only one direction to continue their attacks. If the attacker simply distributed their attack and failed to throttle the login attempts, all of the hosts which were participating in the attack would have been banned fairly quickly. If the attacker just used a single host and throttled their attack, it would take a substantial amount of time to iterate through the account/password dictionary.
If the attack strategy is inspected further, to find that the account list that is attempted is in alphabetical order and is synchronized across the BotNet. By making use of these additional characters, the strategy employed to block these attacks could continue to evolve.
SSH attacks are simply result of taking a list of accounts with common passwords and trying all of the username/password combinations to see if any of them allow access into a system. Early attempts simply tried to supply all of the combinations as fast as possible to determine if there was a valid combination present. Applications such as denyhosts, fail2ban, and sshguard exist to detect brute force attempts and ban those IP addresses from trying to access the server.
At a high level the counter strategy employed to prevent successful brute force attempts on a system implements a rule similar to the following: If a number of unsuccessful login attempts are detected within a short period of time; block all connection attempts from that address for an extended period. This rule acts as a directional selection pressure in that it forces attackers that are using the brute force strategy in a specific direction by controlling the login attempt frequency and number of source IP addresses.
Beginning in May of 2008 through December 2008 and into January of this year, there were reports of a newer Slow/Low-key Brute force attempts from various BotNets. With these newer attacks, the attack strategies were modified such that they are occurring at a much slower rate and occurring from various source addresses. In deed, upon inspection of the rules that were implemented to counter the attack, as they were acting as a directional selection pressures, it should have been expected to see a response in the attack strategies as they evolved in reaction to the selection pressures.
The SSH brute force detection rules have two principle components which act on the attack in as a selection pressure in a directional manner; the number of failed attempts per period and the source IP addresses. Only attacks which slowed their rate (in response to the failed attempts per period directional selection pressure) and distributed their attacks (in response to the source IP address selection pressure) could be expected to have a reasonable chance of being able to get through their account/password dictionaries.
It is possible that an attacker could have modified their strategy in only one direction to continue their attacks. If the attacker simply distributed their attack and failed to throttle the login attempts, all of the hosts which were participating in the attack would have been banned fairly quickly. If the attacker just used a single host and throttled their attack, it would take a substantial amount of time to iterate through the account/password dictionary.
If the attack strategy is inspected further, to find that the account list that is attempted is in alphabetical order and is synchronized across the BotNet. By making use of these additional characters, the strategy employed to block these attacks could continue to evolve.
A counter-strategy could be employed to include tracking the addresses that are using brute forcing by seeing if they are supplying accounts alphabetically. This counter-strategy has the weakness in that the attacker would only need to modify the order in which the accounts are tracked to a random sequence. This would get around the alphabet test but at the cost of additional resources to track the combination of usernames and passwords which have been attempted. Without tracking the attempted combinations, the BotNet would eventually starting using previously supplied combinations which are known to have failed and count as wasted attempts (and resources). Or the attacker could simply increase the number of bots that were participating in the attack such that only one bot supplies an account/password combination. This would require a large number of bots to participate in the attack, and also have the cost of requiring additional coordination through out the BotNet. By increasing the number of bots participating in the attack, it also exposes the attacker to additional risk in that it would allow a researcher to learn the identity of more of the bots in their network.
By devising a counter strategy which targets the synchronization of the accounts across the BotNet, a new strategy could be used as a basis for augmenting the firewall rule set by keeping a list of accounts that were attempted recently. If another address attempts to use that account, it would automatically drop the connection and block further connection attempts from that address.
Another counter-strategy could be implemented which borrows from Conficker/Downadup's attack strategy. Conficker scans for infect-able hosts on the same network, as they are typically all configured in a similar way (in the enterprise there are GPO policies which are frequently pushed out and for the home user they are almost always left in the default configuration). Making use of this information, instead of blacklisting just the host which is attempting to brute force the system, the attacker's network could instead be blacklisted.
The server could simply nullify the ability of the attacker's brute force attempts by requiring a form of multifactor authentication.
To the researcher who conducted further analysis of the attack, it appeared that the Slow/Low-key SSH brute force attempts began to modify their strategy further to avoid the OpenBSD machines that they were monitoring.
SSH brute forcing provides an easy way to compromise a host, as no exploit is needed and a host running SSH is designed to be remotely administered. Since the strategy employed to detect SSH brute force attempts acted as a directional selection pressure, the attacker was able to modify their strategy to avoid detection for an unknown period until the total number of failed login attempts rose to the level in which administrators and researchers noticed. Eventually the attacker further modified their strategy to avoid the OpenBSD machines that were being used all together.
To the researcher who conducted further analysis of the attack, it appeared that the Slow/Low-key SSH brute force attempts began to modify their strategy further to avoid the OpenBSD machines that they were monitoring.
SSH brute forcing provides an easy way to compromise a host, as no exploit is needed and a host running SSH is designed to be remotely administered. Since the strategy employed to detect SSH brute force attempts acted as a directional selection pressure, the attacker was able to modify their strategy to avoid detection for an unknown period until the total number of failed login attempts rose to the level in which administrators and researchers noticed. Eventually the attacker further modified their strategy to avoid the OpenBSD machines that were being used all together.
Posts
No comments:
Post a Comment