Neglecting the Rules: A Hacker s Tale

Neglecting the Rules: A Hacker's Tale

I would now like to present two hacking scenarios that occurred in organizations that did not practice the virtues and rules of security. One example is from a professional hacking group that successfully attacked a Fortune 500 company, the other is from a giant organization that fell prey to random script kiddies. These two cases were specifically chosen to illustrate how failure to practice specific rules and virtues, and a general failure to remain security focused, can lead to disaster.

"Sneak Attack"

This is the story of a hacking group that successfully gained access into the network of a large international organization, which we will refer to as ORG. ORG had a relatively large security practice, including a 24x7 monitored network operations center (NOC), more than 30 centrally managed firewalls, and a structured logging and reporting system at the perimeter defenses. ORG is a very well-known company, and thus has a very high likelihood of being targeted for an attack. Knowing this, the organization made security a somewhat strong focus. ORG's security, however, was narrowly focused on perimeter defenses, with very few attempts to secure the internal networks or systems.

Pre-Attack

In the middle of the week, a series of Internet-based attacks were made against several other corporate giants. This was gaining a lot of news and publicity at the time, and it was thought that ORG would also come under attack. Thus, the Internet firewalls underwent a series of rigid tests to see if the company could withstand similar exploits. For several days and nights, the security devices were tested, adjusted, and retested as the company awaited an attack.

In parallel to this, ORG's employees were reporting strange calls with a very muffled voice saying the same thing, "Oh… sorry… wrong number." This seemed like a very minor occurrence in light of a pending Internet attack, so it was not investigated further.

The Attack

More days went by as ORG waited for an attack to occur, but the hackers seemed to finally end their crusade without ever turning to this organization. It was not until a few days later that an administrator of one of the networks happened to notice that a core router was rebooted without a consent. When looking at the logs, he discovered something very strange: the router was accessed from another router that had been dialed into through a modem. It was discovered that the modem was attached months before for troubleshooting and was never removed. (The modem console on the router was later found to have no password assigned to it.)

Beginning to think this was a security incident, the engineer asked the security team to investigate. Referring back to the router command logs, it was discovered that someone had dialed into this router and proceeded to Telnet into the core router. The hacker then typed a series of commands that would break the router chain, erase the operating system on the core router itself, and perform a shutdown, leaving the entire network in an unusable state until the problem was discovered and the main router rebuilt.

The Effect

By some extreme luck, the hacker made a fatal flaw in the last three commands he or she entered. This router did indeed reboot, but the hacker mistyped the final commands by inserting one incorrect word, thus causing the router to make all changes temporary. After 15 minutes of downtime, the router finished its reboot and came back to its normal state.

Luckily, what happened in this situation was far less damaging than what could have happened. Downtime of the core series routers for this organization would have cost millions in a matter of hours. And, had the attacker's intentions been more than bringing down the network, he or she could have further infiltrated the network and internal systems.

Where Security Failed (Lessons Learned)

Security in this organization failed for many reasons. Here are the correlating virtues and rules that could have prevented the incident:

Virtue of Higher Focus Security failed because ORG did not maintain a higher focus. So much emphasis was placed on the Internet firewall that no one bothered to look for attached modems or consoles without passwords, or bothered to investigate the automated war-dialer that was calling all the numbers.

Virtue of Education ORG failed to educate the staff on the policy that modems are strictly forbidden. Several modems had been put in place by network engineers who had never read the security policy, nor were they ever educated on the dangers of direct dial-up.

Rule of the Weakest Link ORG placed so much attention on having strong and secure firewalls, and yet there were several unprotected areas throughout the network. The entire attack never even touched ORG's Internet perimeter, rendering their costly security measures useless. ORG also failed to secure internal routers, believing the internal network to be safe from hackers.

Rule of Preventative Action No proactive security measures were taken on internal systems. Policies existed that said no modems were allowed within the organization, but no attempts were made to actually enforce this policy or check for existing modems. No security audits ever took place and no penetration testing was ever performed.

"Self-Sabotage"

In this scenario, we have another corporate giant with a very robust and complex global WAN. We shall call this company ORG2. ORG2 had already been the target of multiple attacks, and over the years, had built up a strong perimeter defense with some limited internal defenses as well. In an effort to maintain a robust infrastructure, ORG2 had a matrix of WAN links, which within a few seconds could allow all WAN and Internet traffic to be re-routed through any of its major U.S. hubs. On paper, this very expensive network seemed rather flawless.

Pre-Attack

ORG2 had a large variety of Hewlett-Packard printers in use across its various locations. It became apparent that there were enough printers to warrant some form of central management, but no one was quite sure how to go about it. An employee of the organization decided that this was his opportunity to shine as he began to evaluate different products for print management. In his spare time, he built a UNIX test server and installed a variety of printer management tools.

Meanwhile, a series of network changes were also taking place within the organization. A new communications line was being brought up to a major partner, and a network engineer was working around the clock trying to integrate the two networks. This work was getting a lot of attention, while the printer project was off the radar.

The Attack

In the afternoon on a very busy Wednesday, users started to report a slowdown in their Internet and WAN activities. After about 30 minutes had passed, the entire network began to crawl and no one knew the cause. It was known that the network engineer had been working to bring up the new line, but there was no tracking system in place to see the progress or what actions had taken place on that day. Another 30 minutes passed before the network engineer was tracked down and forced by the CIO to undo all of his work. Routers were rebooted, networks were shut down, and a lot of work was lost, but still the problem persisted.

A little later, the redundant firewalls shut down, and on investigation, a security engineer noticed that the network was being bombarded with what looked like an attack. The firewall's logs were filled up with millions of entries, forcing it to shut down. The redundant firewall failed over, and in a matter of seconds, it also shut down due to the same issue. In a knee-jerk reaction, the company decided to re-route all traffic through its West Coast facility. Twenty minutes later, the network of the secondary facility came to a crawl and the firewalls on their Internet connection shut down.

While working to restore the primary firewalls, a security engineer began to parse the giant log file to see what events caused it to fill up. Looking at it in the calm of the server room, the engineer noticed that the attack was coming from an internal address. He did a lookup and found that the system's IP address was not officially assigned by the corporation. This was brought to the attention of other engineers, managers, and staff, until finally, an employee returning from his lunch break overheard the conversations. Upon returning to his new print management server, he quickly unplugged the network card, which eventually let operations return to normal for the company, after three hours of downtime and chaos.

The Effect

As it turns out, the individual had misinterpreted the configuration option for the printer discovery services of the test server. Thinking he was entering one minute for the group search interval, he actually entered one millisecond. He also failed to specify a proper IP range and had the system discovering all possible addresses (more than four billion in all). This, combined with the power of the system he was working on, let out billions of probing packets destined for all computers on the LAN, WAN, and Internet.

This error resulted in three hours of sporadic downtime, causing great damage to the company. In addition, all the work for the network migration had been reverted to its original state, causing the project to fall behind schedule.

Where Security Failed (Lessons Learned)

It took a combination of several security failures for this incident to occur. These failures, while appearing obvious to someone practicing the virtues and rules of security, were actually not so obvious to this company, which had invested millions in security consulting and security equipment only to find themselves lost in the chaos.

Rule of Least Privilege Again we find a situation where the Rule of Least Privilege was not practiced, only this time, it manifested in a more physical form. The individual creating the system was in no way qualified to be building or installing a powerful network server on the LAN. He was given the system and began to work with no one ever questioning if he was capable of performing such work.

Rule of Change ORG2 did not follow the Rule of Change. Too many components of this rule were violated to go into detail on each one, but here is a list of issues related to this rule:

  1. The individual attaching the device to the network had given no indication to management, the NOC, or change management personnel that he was going to be performing scans on the internal network. There was no official policy stating he had to do so, and no training in how the corporate process and change management system should work.

  2. Likewise, the network engineer had not kept change management up-to-date on his efforts. The new line had been up and stable for days before the attack, but since no one bothered to report this, it seemed like the logical cause of the problem. Though the company had a change management system, it was not practiced by most people and never enforced by management.

  3. The print management product implemented was only in its final Beta release with no support and no testing performed. The final release (a few weeks later) fixed the issue and forced the configuration to have a minimum delay well beyond one millisecond. Thus, the company was a guinea pig.

Rule of Immediate and Proper Response The response from the company to shift networking operating to the West Coast facilities did not come from a written procedure, nor was it well thought out or investigated. Having not fully determined the cause of the problem on the East Coast, the company panicked and forwarded everything, including the problem, to the rest of the network. Rather than helping, this actually amplified the damage done.

The company had no guidelines to follow, nor a proper chain of command to address such issues. Thus, the idea to push all traffic to another location was made by a few people, with little data to explain the anomaly, in the midst of a great panic.



Inside the Security Mind(c) Making the Tough Decisions
Inside the Security Mind: Making the Tough Decisions
ISBN: 0131118293
EAN: 2147483647
Year: 2006
Pages: 119
Authors: Kevin Day

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net