View Single Post
Old 05-05-2005, 10:28   #1
TheBlueRaja
cf.mega poster
 
Join Date: Dec 2003
Location: Baw deep in a munter
Age: 49
Services: Initiations, rep rigging and orgies!
Posts: 5,750
TheBlueRaja has a nice shiny starTheBlueRaja has a nice shiny starTheBlueRaja has a nice shiny starTheBlueRaja has a nice shiny starTheBlueRaja has a nice shiny star
TheBlueRaja has a nice shiny starTheBlueRaja has a nice shiny starTheBlueRaja has a nice shiny starTheBlueRaja has a nice shiny starTheBlueRaja has a nice shiny starTheBlueRaja has a nice shiny starTheBlueRaja has a nice shiny starTheBlueRaja has a nice shiny starTheBlueRaja has a nice shiny starTheBlueRaja has a nice shiny starTheBlueRaja has a nice shiny starTheBlueRaja has a nice shiny star
How Can an Attacker Bypass a Firewall?

Simply as an FYI - here are some methods that attackers can use - most notablty the more common ones. It pays to read this to get an understanting of why you should only allow specific programs to use specific ports. I got this from www.eEye.com's newsletter but as its helpful - and informative, i thought i would post it here.

---

If the ultimate goal is executing commands on a system behind a firewall, there are a number of very different approaches an attacker can take to accomplish this. The applicability of each depends on the configuration and network layout between the attacker and the target; we will address the key points here.

The most obvious way to penetrate a firewall is to look for a hole in its configuration that will allow your traffic to slip through. Possibly the best-known trick in this category is to send packets to the target host with a source port of 53. Because DNS queries are (connectionless) UDP packets often sent out from a variable high port, but always with a destination port of 53, sometimes the easiest way to allow the DNS responses to reenter the network is just to allow all incoming traffic with a source port of 53. Another example of a misconfiguration would be mistakenly allowing a firewalled server to receive connections to some of its services (e.g., SQL on port 1433) from any IP address, rather than a restricted "whitelist" of addresses. This type of misconfiguration is so egregious that there might as well not be a firewalled installed at all.

A bit more wily approach is attempting to attack the firewall itself, by exploiting a software vulnerability or abusing a misconfiguration in its administrative settings (e.g., default password or SNMP community name). In the case of a NAT-enabled router, compromising the router would give the attacker a way to send packets directly to hosts on the internal network, an ability that may not otherwise be possible (for instance, in the case of a home user connected to a cable modem via a broadband router). Similarly, taking over any other device that bridges the internal and external networks, like a server with two NICs, would provide the same sort of stepping-stone to sending unsolicited traffic to internal hosts.

In contrast to sending "unsolicited traffic" into a protected network, a firewall could be bypassed in some circumstances by getting a protected host to "solicit" traffic from a malicious host on the outside, in which case the firewall would most likely allow the malicious host's response back through. For instance, an attacker could compromise a web site visited by the user of a protected host within the network, or could hijack or poison a DNS server and redirect that user's traffic to a malicious system. For a more specific example, consider the Windows XP SP2 firewall and its behavior regarding UDP broadcasts. A Windows XP SP2 system block all incoming traffic by default, but whenever it sends out a UDP broadcast packet, all UDP responses originating from the system's subnet, and with a destination port set to broadcast packet's source port, are allowed back through for three seconds following the broadcast. Because default XP SP2 systems will send UDP/137 and UDP/138 broadcasts periodically on their own, an attacker could repeatedly send spoofed packets to a host running XP SP2 and the traffic would eventually be allowed through. If a vulnerability were discovered in a service related to UDP/137 (NetBIOS Name Service), UDP/138 (NetBIOS Datagram Service), or in SMB named pipe sessions (which the system may be tricked into establishing in response to crafted UDP/138 traffic), it would be able to penetrate the XP SP2 firewall using this approach.

Very often, the users themselves may allow attacks through the firewall by connecting to externally-accessible proxy server or other conceptually similar services, including chat services (e.g, IM and IRC) and peer-to-peer networks, or by accepting external data onto their machines via web pages and e-mail. As has been painfully demonstrated, sending malicious e-mails, e-mail attachments, instant messages, and IM file transfers is an effective attack that allows an individual, rather than a computer, to be targeted and attacked via client software vulnerabilities and/or social engineering.

Finally, it's worth mentioning that alternative access and physical access both provide additional proven ways around firewalls and into protected networks. "Alternative access" here refers to phone lines and wireless media, which allow internal systems or devices (e.g., WAPs, laptops in ad-hoc wireless mode, computers with modems, and even fax machines) that are connected to both this "alternative network" and also the protected LAN to be accessed. Physical access obviously refers to an attacker who can physically tamper with the hardware which the network comprises -- by introducing rogue access points or modems, reconfiguring systems, rearranging cables, or adding a rogue PDA or even a Dreamcast with specific malicious objective to the network. The attacker need not be able to communicate with the device once it's on the network, as long as its instructions are self-sufficient, or the device could "phone home" and accept further commands from its owner.

This is just a sample of different approaches to circumventing a firewall; undoubtedly there are more concepts and infinitely many "tricks of the trade" that can be used to bypass firewalls and other related forms of protection.
TheBlueRaja is offline   Reply With Quote