Drilling through firewalls

Hi,

I'm looking for ideas on ways to subvert firewalls for short messages. I.e., passing what *appears* to be

*legitimate* traffic through a (properly configured) firewall that is, in fact, *not* acting in the "apparent" purpose. In particular, I'm interested in some of the "less obvious" ways of doing so.

I'm concerned with "classic" firewalls, here (e.g., running on a bastion host) -- not the MS variety (the idea of running a firewall on a desktop machine seems *too* funny! :> )

Thx,

--don

Reply to
D Yuniskis
Loading thread data ...

Do you have a *legitimate* reason?

This is far easier to do if your purpose is to enact point-to-point communication between two cooperative computers via a 'unfriendly' firewall than if you have some need to drill through a firewall to unknown software on the other side.

I know it can be done: I remember a conversation with a fellow at the Embedded Systems Conference whose company had figured out how to make their VPN work on the http port (port 80?), so that they could log into their network through hotel ethernet connections while on the road.

--
Tim Wescott
Wescott Design Services
 Click to see the full signature
Reply to
Tim Wescott

To establish any communication, at least one computer outside must have open server port. Clients could connect to it and communicate to each other through whatever outbound connections allowed by firewall. There is no problem to encapsulate your data into http or any other common protocol.

VLV

Reply to
Vladimir Vassilevsky

Of course! For "illegitimate" reasons, you can be far more brazen and careless in your approach...

Yes, you just need to find a protocol that is *likely* to be tolerated by the firewall and an appropriate port. The trick lies in deciding A PRIORI (remember the E in c.a.e) what that strategy will be -- without knowledge of the particular firewall (and its configuration) you are likely to encounter.

Folks using a laptop in a hotel have much more leeway: their strategy can be adaptive (as adaptive as the humans involved can be!); and, the firewall in question will already (typically) have been configured to be highly permissive (since, presumably, the hotel wants to offer this as an amenity to its guests).

Reply to
D Yuniskis

The problem lies in my expectation of a "(properly configured)" firewall.

A good security officer will look at *each* node on his network and configure the firewall to allow the *minimum* connectivity REQUIRED by the device in question. Then, write rules to restrict the traffic between that node and the outside world to *exactly* that level -- nothing more.

If, for example, the device in question is a laptop, then the MAC/IP associated witht he laptop will probably have very permissive rules regarding what it can and can't talk to on the outside.

OTOH, if the device in question is a temperature sensor (recall this is c.a.e), chances are it *won't* be allowed to access websites, send email, etc. directly with the outside world! :>

Likewise, the outside world will be "hindered" from accessing that device as well (no doubt, this example would have the device "not routed"... but, with some thought, you can come up with a device that *will* be routed -- though with limits placed on its connectivity).

So, the task is to come up with "non-obvious" (see my post) ways of drilling through the firewall's rule set.

Before the days of switches, this would have been easier as network/peer discovery was almost "free". But, now the switch limits just what traffic you see and, thus, how much you can glean about the rest of the network (and the traffic that the firewall is allowing for those *other* nodes)

Reply to
D Yuniskis

If the IT staff is that attentive and the firewall that restrictive, then turn the problem around: your equipment isn't defective if it can't talk through the firewall, the problem is with the firewall and/or the people managing it.

Is there a comp.arch.embedded.corporate.politics group?

--
Tim Wescott
Wescott Design Services
 Click to see the full signature
Reply to
Tim Wescott

If the firewall is routing a connection for a machine inside (A), then sending a packet in may get routed, but then if the IP source is checked, it may be blocked (depends on firewall), the problem then becomes that A will reject the sequence order or end up crashing or time out in a CRC error resend loop, as packet number n-1 is never refetched.

Not difficult really, more irritating.

Reply to
jacko

If you've workeed with IT/IS departments at larger organizations, you'll find them RETENTIVE (beyond "ATtentive") -- BofH comes to mind :> There seems to be a mindset that borders on "control freak". As if the network (and everything attached to it) was their *personal* property (and they never learned to "share" as children :> ).

Couple that with the fact that they don't understand anything that isn't a PC. And, can't *control* those other things ("no user serviceable parts inside") puts them really on the defensive.

In one case, they made such a stink that a separate network was installed (for fear that these "black boxes" would CORRUPT their precious network). Then, responsibility for the network was given to another NON-IT group (which *really* frosted them as all the new automation was now beyond their jurisdiction -- money is being spent on "electronic goodies" and they have no say in how or where that money is spent).

I don't want to play politics. I just want to solve (technical) problems and move on. To that end, I have found that doing things in a more clandestine manner is easier than fighting the good fight (if you "win", you've made enemies; if you "lose", you end up dealing with a bunch of ignorant, pompous asses).

I'm not sure they know how to access USENET! :-/

Reply to
D Yuniskis

Yes, but this only works if the clients (skype#1 & skype#2) can get *out* through their respective firewalls *first*! I.e., they have to either exploit a *poorly* (vs. *properly*) configured firewall *or* leverage protocols that the firewall *will* pass (for their IP).

E.g., skype wouldn't work in an institution where it was trying to originate connections from a node constrained to be an NNTP server/client. (think in terms of *appliances* instead of "PC"s)

Reply to
D Yuniskis
[...]

and the firewall admin is so evil that he doesn't allow this legitimate traffic? Sound strange.

Regarding your temperature sensor example from your other posting:

[...]

unless you describe the type of equipment, nobody can answer your question about circumventing the firewall, because it's not clear what legitimate traffic the device has.

Oliver

--
Oliver Betz, Munich
despammed.com is broken, use Reply-To:
Reply to
Oliver Betz

Googling for "http tunnel" gives about five million hits. Of course, all the software you'll find there is for PC systems, so if you are talking about a small embedded system rather than an embedded linux device, they won't help much.

Reply to
David Brown

"properly configured" is a matter of taste - thus there is no answer to this question.

No, a good security officer will do nothing of the sort. A good security officer will balance the requirements of security, reliability, convenience of use, ease of maintenance, and cost. That invariably means a firewall that is more permissive than the absolute minimum, while not introducing significant security risks.

Also remember that a significant proportion of the people in charge of network security are not "good".

The reality is that on most networks, any node can get an IP address by DHCP, resolve DNS queries, and sent out by http on port 80. This should be your basis, and it is all that is needed for a small embedded system

- anything else (such as passing on emails) can be handled at your server end. Other features, such as sending emails directly or SNMP alerts, should be optional.

Make these three parts - DHCP, DNS and HTTP - part of the requirements for the device, just like any other requirements such as power supply needs. Any company buying them will be able to provide this.

There are a few reasons why this might not fit in immediately with a company's network setup. How much effort you put in to this is up to you.

They may not have DHCP enabled (it's rare, but it happens). In this case, you would have a way to manually set the IP address and related parameters.

They may be using IPv6.

They may have DHCP enabled, but only for known MAC addresses. In this case the installer would have to coordinate with the IT department to register the MAC addresses.

They may be using a captive portal. In this case, all outgoing traffic is redirected to a specific server until the user is authenticated (such as by username and password). If that's the case, you would need to arrange with the IT department to get around the portal - there are too many variations for a non-human device to support every likely portal system.

They may be using a whitelist to restrict access to external servers, in which case you need to get their IT department to add your servers to the list.

The issues listed above are only going to be seen on networks configured by competent administrators. That means they will also know how allow your devices the access they need. It doesn't mean they /will/ give you that access - that's a matter for the customer to decide internally.

There will certainly be corporate networks and potential customers who will simply refuse to allow your devices on the network.

Any attempts to "get around" the firewall will certainly be seen as abuse. If the network is simple and permissive, there is no need to work around it. If not, then the chances are very high that any tricks will be spotted - and then you'll be lucky if you simply lose the customer and are only sued for the cost of purchase, installation, and the IT department's time.

Reply to
David Brown

Skype is very good at drilling through firewalls. Quite apart from the obvious HTTP (CONNECT, etc) facilities, it can open a port in a packet-filtering FW using "hole punching". Google it, but basically it relies on a 3rd party to make firewalls at both clients *think* that both clients are attempting an outbound connection to the other, so they allow packets to come in. The 3rd party is there to guess the ports that will next be allocated. Cunning.

Or just sign up as a Skype developer and use their API.

Clifford Hesth.

Reply to
Clifford Heath

He's doing his job -- protect the company's infrastructure and IP -- based on his idea of what and how devices should/could utilize it and what constitutes a "potential threat".

*I* won't let *anything* "foreign" onto my infrastructure. Too much to risk and too little to gain. If friends visit and want to use my Internet connection, they get exclusive use of it (i.e., their machine can't even talk to my "exposed" host). If they don't have a laptop with them, I "loan" them a virgin machine which serves that role for the duration of their visit -- then wipe the machine clean after they leave and restore the original disk image. I.e., *my* security officer (me) doesn't have time to spend installing the latest patches, upgrades, etc. So, "he" has decided to provide security through 100% isolation. (it has proven to be far more effective and far less costly than the "chase the latest updates" approach).

Now, this IT guy is being told that someone is going to put a device on "his" network. It has no user serviceable parts inside. It runs software that he has never seen before (and can't inspect -- *if* he was qualified to do so). It will sit there for

10-20 years -- long after his tenure. It will never be powered off. Aside from a power indicator, he has no idea if it is even *alive*!

Even if the device doesn't "steal" corporate secrets, doesn't actively try to subvert other hosts on the network, doesn't misimplement standard protocols, etc., how is he to know that it is "benevolent" -- other than the fact that the CEO has authorized the purchase and installation??

They *can't* be "infected" with virii or other malware. They can't be (intentionally) corrupted by outsiders or disgruntled employees. They're communications are predictable and repeatable. I.e., they are probably *the* most well-behaved, predictable devices in the entire organization. Yet, they are the most "feared" because they are the *blackest* of boxes. (FUD)

[the fallacy in this fear is that the same questions apply to his latest MS OS and application suite running on those 3,000 corporate seats. What if *all* of them have some fatal flaw?? (which is usually the case in these homogenous installations) How capable of detecting it will he be? What will he be able to do to rectify it -- short of pleading to their vendor(s) for a fix?? block traffic from *all* of the hosts???]

And, unless he sets a packet sniffer on the line 24/7, he'll never be able to *prove* any harm that the device *might* cause in the future (assuming harm to mean *any* sort of "problem" that he choses to blame on it). I.e., he is largely impotent wrt this device(s) -- something very contrary with his (speaking of the typical IT department) role in all other things IT-related. There, upper management typically defers to him instead of trying to understand the details of the complaint some other department is lodging against them/him:

- "Why are we blocked from visiting

formatting link
"

- "Why can't I access my POP3 account on foo.com?"

- "Why can't I access the NNTP service at blah.org?"

- "Why can't I use Google Earth?" Any of those complaints heading up the corporate hierarchy are invariably deflected back down; "Let IT/IS handle it". (I know of a hospital that blocks their machines from accessing webmd.com -- "Um, why *allow*

formatting link
and *block* webmd.com? Fear of competition?? :-/ ")

Introducing a device that uses services that he doesn't *think* it should use gets under his skin. "Why does your device need to contact

formatting link
" "What information is your device sending to foo.com?" etc.

[in one case, a firewall was constricted to allow access to *just* XXX.XXX.XXX.XXX -- e.g., "foo.com". Some months later, the client complained that the device wasn't performing as planned. Apparently, the targeted site had a new IP. DNS queries resolved that new IP -- but the device couldn't contact it because the IP had been hardwired into the firewall and the rules hadn't been updated to reflect the new IP. Of course, the client was charged for the service call -- "no fault found". And, was not happy when the fault was found to be in *his* organization (hello Mr Security Officer!). Perfect example of a battle "won" -- and an *enemy* made (the security officer)]

This is particularly troublesome at "non-engineering" type companies (smaller "box" or, perhaps, thicker walls?) When you do these sorts of things at engineering firms, they are usually impressed with the technology. They will set a packet sniffer on the line just to try to see what sort of information you actually *are* getting and try to deduce how you are using it (curiosity instead of paranoia). It's also usually easier to get their buy-in for even more permissive access (e.g., "I'd like to configure the devices to talk to my development server so I can see all of the data they are acting upon in real-time and better understand any anomalies that may turn up. Do you mind if I access your network? I'm at XXX.XXX.XXX.XXX/Y ...")

Who *cares* what "legitimate traffic" it has?! It has a need to talk through a firewall that is typically far more restrictive than it needs to be -- at least in terms of these devices. The question is a search for *other* (than the obvious ones) techniques for getting through firewalls. Does the technique depend on the semantic content of the message(s) being exchanged?? (e.g., blue vs. red?) What do you care weather I am exchanging loop gains, weather forecasts, lottery number predictions or horoscopes? Do lottery predictions have to be routed differently (for fear someone might steal the "winning number"?) than control loop gains (which are boring and have no retail value)?

This is a bit of an obsolescent query as newer generation systems are going wireless. This is even more threatening to the IT folks as now the devices can talk to themselves without

*any* monitoring (well, no *practical* monitoring unless you expend lots of resources to cover the entire geography). I.e., *they* have to request *me* to provide a "tap" into the message stream (which is a "special request" -- one that their management is often not interested in paying for: "Why do we care what they are saying? Aren't we only concerned about what transpires on *our* internet? What's the risk to our infrastructure if the devices aren't talking *to* it??")
Reply to
D Yuniskis

OK, I was about to scold you for not understanding the requirements, but you at least acknowledge them. One of the great frustrations in my life when wearing my network admin hat are protocols that deliberately go out of their way to make themsleves hard to block. I

*won't* block legitimate/necessary traffic, but by making things hard for me, you've merely pissed me off. Not to mention that devices that actively try to hack around firewalls are often difficult to restrict

- I may choose to trust IBM, and I may choose to allow the support processor on the server have Internet access, but you can be darn sure that I know exactly which servers at IBM and which local devices are allowed to communicate. OTOH, what morons though that SOAP using HTTP as a transport was a good idea?

And here you're wrong. Let's (for sake of discussion) assume that whatever this device is doing over the Internet happens by establishing a TCP connection. Now, can you *prove* (and not just to yourself), that there is *no* buffer overflow that a malicious server (assuming the real one, which is obviously outside your customer's control, has been subverted) could take advantage of? Any of the other myriad attacks that have happened against both the TCP/IP stack and the applications running on them? Or what about if an adjacent device on the network gets subverted, and starts blasting away at your box (and such a subverted device has a number of additional possible attacks, including ones based on load, that are not possible for the subverted external server).

And then there is the issue of firmware updates. Given that you have a device with a network port, it would be most unusual in this day and age if you didn't have some mechanism for doing a firmware update. And trojaned firmware updates have occurred, both from the real vendor (deliberately and otherwise) and via a third party. A number of years ago someone started distributing a fake BIOS update for PCs, and managed to brick a fair number of PCs from a large vendor. And if the device physically supports a firmware update, once you get hacked in, even from outside, you can do one, and then not even a reboot will clear the device.

David Brown's advice is good. Just make the Internet requirements part of the requirements for the device. If the network admin decides it's too risky to attach to one network, he can put it on another. Or justify to his CEO why they can't use this device.

And frankly, if the network admins are incompetent, you're screwed, in the sense that you're not going to be selling product, but sometimes those are the breaks.

So stick with something simple. Like David suggested, require DHCP, DNS and HTTP, and be done with it. HTTP on a non-standard port, or HTTPS may make some people happier (although not everyone), so those might be a config option.

And think about what your device actually requires. Is it reasonably for the device to run for extended periods *without* Internet access? Can you get by with just email? It might be easier to get access to an email server (and if the device is only *sending* messages, that can be a relatively easy option to get past security). Or can you provide dial-up as an option (obviously that's only meaningful if the device is not otherwise network connected)?

But I would beseech you to *not* actively hack around firewalls. No matter how tempting the horde of incompetent morons tending firewalls may make the idea.

Reply to
robertwessel2
[...]

well, if you don't care, I have no advice.

Oliver

--
Oliver Betz, Munich
despammed.com is broken, use Reply-To:
Reply to
Oliver Betz

That's pretty obvious!

Reply to
D Yuniskis

Of course! The problem is, most IT departments operate far too independently of their corporate user bases. And, because "technology" is so "technical", management tends to take a hands-off attitude towards it (deferring to the "IT professionals" more than they usually *should*). They forget that they serve two roles -- protecting the corporate infrastructure *and* facilitating the use of that infrastructure! They fixate on the former at the expense of the latter.

I see this starting to change and traditional IT departments are losing glamour and becoming "PC support" entities -- with the other bits of "smart technology" being handled by "higher tech" departments with more technical expertise (e.g., instrumentation, etc.). As more and more technology creeps into traditional commercial infrastructure, the torch will pass to these new groups (as the IT folks often aren't skilled in the related technologies that are being "instrumented" -- and, these devices tend to require less "hand-holding" than PC users do)

I'm not sure that is a characteristic of the well-defined protocols. Rather, an "unexpected consequence"? Most of them can be (ab)used for other purposes -- which is what makes getting around firewalls so easy. They tend to be designed to make doing "something" easy -- and, that often facilitates doing

*other* things easily, too.

The problem is defining what constitutes *legitimate* use of a particular protocol? E.g., if a user types into his/her browser:

formatting link
or
formatting link
is this something that your firewall *should* filter? I.e., you've just passed something through a firewall that, in all honesty, is probably completely bogus (but the firewall doesn't know that!)

Don't use TCP. Too heavy and too buggy. It doesn't afford us anything (that was part of the original design goal -- do everything connectionless).

Yes. The code has been thoroughly tested and deployed for several years without incident. The sources are maintained in escrow. This safeguards against supplier going out of business *and* to support any litigation against supplier in the event malice or damage is suspected. The design and implementation have been reviewed, in detail, by supplier and customer to ensure both agree on the design's fitness for the specification and application. If you've worked in any industry that takes these issues seriously (e.g., Pharma), you'd understand the measures that are taken before a product is "released". We're not talking about a hundred dollar toy you can pick out of a Black Box catalog...

All you can do to this device is fill the (external) pipe and prevent "other" packets from making it to the device. You can't bring the network stack to its knees by tying a 100MHz oscillator to the interface connector (figuratively speaking). Unexpected/incorrect packets just get discarded. We're not talking about a "desktop PC stack" that tries to accommodate any potential application. Rather, this is a stack tailored *to* the actual protocol being used. Everything is very rigidly defined so that the outside world can go to hell without consequences -- things keep working "as best they can" with the information they have to date.

Firmware updates are signed. Before an update will "take", you have to physically be present at the device to activate a switch. When the update is complete, the switch must be restored before the device will resume operation (i.e., you can't leave the switch "active"). Updates are VERY expensive (because of the time and effort required to test and validate the code, etc.) so they are infrequent -- and, as such, can be "inconvenient". (this is actually a blessing for all involved)

If you've read any of my posts over the past few decades, you'd realize I am a *huge* advocate of formal specifications!

The interface is specified in *gory* detail. Not only the addresses and ports used but the packet formats *and* timing information (i.e., what to expect in terms of packet frequency, response times, end-to-end "propagation delay", timeouts, etc.). These are parts of the overall specification so they are freely available. Things are written very carefully (i.e., a specification should be viewed as a *contractual* obligation between all parties involved) so that you stick to the *letter* of the spec (no hand-waving about the "spirit" of the spec -- treat it like a legal contract).

In one case (I mentioned in another post), a "failure" was traced to an IP address hard-coded in the firewall rules. When the IT dude tried to cover his backside by claiming that he had followed the spec, we pointed out that the spec didn't define a *numeric* IP address. It had very clearly indicated that traffic would be routed to "foo.com". The fact that *he* had opted to resolve foo.com on the day he wrote the filter rules was *his* failure (little "nits" like this are essential when it comes to deciding who pays air fare, meals, lodging, etc. for the service call :> )

That's where you're wrong. The network administrators don't make the purchasing/deployment decisions. And, they don't sign the checks. They're just grunts that can either facilitate the process or hinder it. This is why it is desirable to have solutions that work *despite* them: when you can unplug the CEO's PC and plug in your device and *show* it working, it makes it hard for the IT folks to *not* make the system work elsewhere -- the CEO has already

*seen* it work ON THEIR PREMISES! (if you, instead, have to arrange for their firewall to be configured a particular way *before* you can do that demonstration, then you are at their mercy -- *did* they really write the correct rules that you requested? Is there other infrastructure in the way that they have forgotten to mention??)

We often sit on networks that are "deeply embedded" in organizations (so the traffic that gets in/out is considerably restricted). We make less demands on the network/firewall than you've suggested. Part of the design philosophy has been to leave a very small footprint. This is reflected in the resources that we use (message sizes, frequency, etc.)

You'd be surprised at just how *little* you need to get through

*most* firewalls! :> I suspect there are techniques similar to the ones we currently use that could also be used (hence the purpose of this post) equally well. (I'm engaged in a conversation elsewhere that may have turned up a very different approach!)

Different devices have different capabilities and expectations. Since network connectivity is never "guaranteed" to be available, everything knows how to operate in the absence of that. But, the effects of prolonged absence vary with the device and application. When the network *is* available, we can add *lots* of value (i.e., this is what makes things so attractive to customer)!

Email (SMTP/POP/IMAP) seems to be abhorred even more than HTTP! I guess folks have a harder time keeping their mail servers up and running. The store-and-forward nature of email also means it isn't "current" (it's easier to deal with *no* data than it is to try to figure out how to compensate/adjust late data). If you expect incoming mail, then you leave yourself vulnerable to "strangers" forging messages that *are* obligingly passed along to you -- more work for you to discard them (else you have to hope customer can filter individual email accounts, etc. -- this puts a big requirement on the customer... "big footprint")

Dial-up requires a phone line at each node. And, getting an analog modem is more expensive than a network interface. Also, many firms have digital PBX's -- analog modems don't work with these (*poof*!). Designing for specific digital PBX's is costly (and the PBX vendors often are uncooperative as well as disavow any performance guarantees for "foreign devices" on *their* "networks")

I don't see anything "wrong" with the (ab)uses we are taking of existing protocols. Statistically, you'd never be able to identify the increase in traffic, any potential decrease in reliability or availability, etc. Folks who don't *know* we are there would be hard pressed to *discover* our presence. Those that *do* know might not *like* what we're doing (because it is "wrong" in some semantic sense or is a personal afront) but it works quite well.

Remember, we're not streaming video, etc. "Small/infrequent messages" as I said in the original post.

I suspect most of these issues will be going away, soon, as more of this goes wireless. It seems that the wired networks in most places will just find use supporting desktop machines and the IT folks who babysit them. That "fabric" is already in place and working. Not much to be gained by replacing it with wireless technologies.

Everything else will move off the cable (since running cable is costly). This puts extra burdens on those devices (to safeguard their gazintas and cumzoutas) -- but, any prudent design does this already (i.e., you wouldn't assume you were safe from hostile hosts just because you sat behind a firewall!) As I see it, the biggest challenge will be the variability in the level of connectivity associated with these new technologies (and designing in the face of them).

Reply to
D Yuniskis

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.