Prev: FM radio in mobile phones
Next: Black box inventor David Warren dies at 85
From: Oliver Betz on 22 Jul 2010 03:25
D Yuniskis wrote:

[...]

>> Do you have a *legitimate* reason?
>
>Of course! For "illegitimate" reasons, you can be far

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:

[...]

>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! :>

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:
From: David Brown on 22 Jul 2010 04:13
On 21/07/2010 18:52, Tim Wescott wrote:
> On 07/21/2010 09:43 AM, D Yuniskis wrote:
>> 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! :> )
>
> 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.
>

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.


From: David Brown on 22 Jul 2010 04:42
On 21/07/2010 20:41, D Yuniskis wrote:
> Tim Wescott wrote:
>> On 07/21/2010 10:52 AM, D Yuniskis wrote:
>>> Hi Vladimir,
>>>
>>> Vladimir Vassilevsky wrote:
>>>
>>>> D Yuniskis wrote:
>>>>
>>>>> 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! :> )
>>>>
>>>> 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.
>>>
>>> The problem lies in my expectation of a "(properly configured)"
>>> firewall.
>>>

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

>>> 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.
>>>

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.


>>> 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)
>>
>> 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.
>
> 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).
>
>> Is there a comp.arch.embedded.corporate.politics group?
>
> I'm not sure they know how to access USENET! :-/

From: robertwessel2 on 22 Jul 2010 16:40
On Jul 22, 1:21 pm, D Yuniskis <not.going.to...(a)seen.com> wrote:
> Oliver Betz wrote:
> > D Yuniskis wrote:
>
> >>> Do you have a *legitimate* reason?
> >> Of course!  For "illegitimate" reasons, you can be far
>
> > and the firewall admin is so evil that he doesn't allow this
> > legitimate traffic? Sound strange.
>
> 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??


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?


> 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)


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.
From: Oliver Betz on 23 Jul 2010 02:16
D Yuniskis wrote:

[...]

>>> 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! :>
>>
>> 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.
>
>Who *cares* what "legitimate traffic" it has?! It has a need to

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

Oliver
--
Oliver Betz, Munich
despammed.com is broken, use Reply-To:
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: FM radio in mobile phones
Next: Black box inventor David Warren dies at 85