[Info-vax] OpenVMS versus Windows/GE Telemetry Control Systems.

Simon Clubley clubley at remove_me.eisner.decus.org-Earth.UFP
Thu Jan 17 07:43:28 EST 2013


On 2013-01-16, David Froble <davef at tsoft-inc.com> wrote:
> Simon Clubley wrote:
>> On 2013-01-16, Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
>>> On 2013-01-16 08:44:17 +0000, David Froble said:
>>>> As a small example, I've implemented some socket communications.  The 
>>>> socket is basically an open port to the world.  But it's under program 
>>>> control, and what's coming in must meet expectations, or it's flushed 
>>>> and the connection dropped.  Are there ways to defeat such?  I have to 
>>>> say that I don't know, but, I really doubt it.
>>> DNS spoofing and routing-level shenanigans can be used for MiTM 
>>> attacks, and there are other approaches.
>>>
>> 
>> David, as a specific example of the above, how do you handle replay
>> attacks against this service of yours ?
>> 
>> (Or have you determined that replay attacks are not something which is
>> relevant to the service been offered ?)
>> 
>> Simon.
>> 
>
> Ya know Simon, you're not very nice.  You make me work ....
>

You are welcome. :-)

> So, I had to go lookup "replay attack" and read about it.
>
> Initially  we did not use encryption, but we're now moving to implement 
> SSL on all external communications.  We use certificate validation, so 
> this should reject any connections that do not have valid certificates 
> issued by our cert authority.  I "think" this will avoid replay attacks, 
> but perhaps not.
>

Encryption will certainly help, but it doesn't solve everything.

For one simple example, consider the case of a client PC which has been
compromised in such a way that a attacker has access to the data stream
after it's been decoded (for incoming data from the server) or before it's
encoded (for outgoing data to the server).

> Some of the communications include inventory inquiry, incoming purchase 
> orders, and such.  As for the inventory inquiry, yes, it's additional 
> work for our systems to perform, but it's minimal overhead.  So if 
> several get duplicated, so what.  If it's a storm of connections, then 
> yes, we'd have a denial of service situation.
>

So it's a traditional stock control type setup.

> In any case, if we used one of the methods to defeat such attacks, we'd 
> still get the communication requests, so a storm would still be a DoS 
> attack.
>

In this stock control case, I would be less worried about DoS attacks
and more worried about making sure that, say, a malicious employee could
not commit fraud by compromising the PC of a co-worker.

(I'm a commercial applications programmer as a major part of my day job,
so I get to think about these types of things every so often. :-))

> Incoming purchase orders would be an issue, however, our applications 
> long ago have implemented methods to detect and reject duplicate orders.
>

Yes, application level checks are equally as valid in this type of
application.

> Still, thank you for the question, I learned something new, even if I 
> did have to work to do so.  See, old dogs can learn something new, every 
> now and then ....

Age doesn't matter; only your mindset does. :-)

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world



More information about the Info-vax mailing list