[Info-vax] DECnet challenge

[Stephen Hoffman]

On 2019-03-02 18:32:02 +0000, Mark Berryman said:

> On 3/1/19 4:47 PM, Stephen Hoffman wrote:
> 
> [ a good summary on the difficulties of maintaining complex systems]
> 
> However, I'm sure how much that applies here since, these days, most 
> routers and switches are centrally managed.  I would agree that trying 
> to maintain rulesets individually on more than a small handful of 
> devices will likely work fine until the person who implemented it was 
> no longer available.  Then errors would creep in.

Ayup.

Routers and switches are not the only part of a network with firmware 
or software, too.  Printers, mobile devices, laptops, servers, vendors' 
add-in network probes, point-of-sale devices, server and building HVAC, 
building security systems, etc.  Pretty much everything is IP connected 
or seemingly soon will be.  And various of that equipment then 
increasingly either has vulnerabilities and patches, or the equipment 
needs replacement when it's found vulnerable.  And we know that those 
replacements don't always happen.

I've previously linked to BeyondCorp:

https://static.googleusercontent.com/media/research.google.com/en/us/pubs/archive/43231.pdf 


Beyond big organizations, that same mess what I'm increasingly seeing 
in even SOHO and SMB networks.

Here's an example of an embedded security system:

https://tisiphone.net/2019/01/28/security-things-to-consider-when-your-apartment-goes-smart/ 

https://twitter.com/CharlesDardaman/status/1101626510333673474

> On the other hand, setting up such rules in a management station which 
> then pushes them to all required devices could easily be maintained 
> across both staff and talent churn.

Ayup, and there are organizations doing exactly that.   Dealing with 
the inevitable business exceptions can get entertaining.

>> ps: As for your question, I'd likely start with side channels on the 
>> servers and extracting keys, and with attempting to mess with the IP 
>> network (ARP, iBGP, WAP, DHCP) via an infested printer or infested 
>> client.
> 
> You aren't likely to get very far in compromising a DECnet network 
> using IP hosts or protocols.  Off of the top of my head, it seems the 
> most likely thing you could accomplish would be to interrupt the 
> traffic. However, if you did that, you'd be interrupting lots of 
> traffic and that would almost certainly get you noticed.

DECnet operates over IP in various configurations.  As does SCS.  And 
management operates over IP, including increasingly OpenVMS management.

If you're stuck with DECnet, implementing what you've done is one of 
the tasks you're faced with, if not add-on encryption via VPN or ilk.

And migrating from DECnet to a protocol where you don't necessarily 
have to watch the links quite as closely.

And if you've locked down DECnet to that degree, then that it's 
cleartext and unauthenticated is moot.

Unless and until there's an operational mistake made.

>> I'd also consider tossing DECnet routing messages from rogue DECnet 
>> hosts (IV is tougher here than V, if the switches are paying 
>> attention), or from existing DECnet or IP hosts that have 
>> "mysteriously" become routers for DECnet traffic.
> 
> The configuration would prevent a non-authorized host from trying to 
> become a DECnet router.  However, if you had admin access to one of the 
> existing DECnet hosts, you could certainly try playing games with its 
> routing setup.  However, then OPCOM on my host would alert me to those 
> changes and then we would have words.

Assuming your auditing noticed and flagged that, and the response was rapid.

And if your responses were rapid, I'd consider deliberately inject the 
packets to trigger the chatter, either randomly with isolated 
occurrences over a month or three, or maybe timed to misdirect your 
attention at a particular cause.  I'd look to wear down the response, 
to confuse, and try to cause the (mis)behavior to be ignored.

>> And I'd be more interested in watching the DECnet and SCS traffic than 
>> necessarily spoofing a DECnet proxy through obtaining a privileged 
>> network position via routing or mirroring or finding bugs, as the 
>> cleartext or poorly-hashed creds visible via DECnet and SCS and telnet 
>> and FTP are going to be useful for furthering access.
> 
> Ah, but there is the challenge.  HOW would you watch that traffic?

I'd try to phish your users and your management, and your suppliers, 
and would generally go after the humans.  Same as usual.

I might go after any WPA2 PSK detected.  Though with the sort of 
lockdown you're reportedly running, you're probably also running RADIUS 
and maybe tokens for that.

But trying to packet-capture a locked-down and VLAN'd DECnet network?  
Not going there.  That's about as sensible as going directly after 
competently-designed and competently-implemented cryptography.  Read: 
Not very.

You've made DECnet traffic not the easiest target.

With DECnet over IP, invoke an incantation involving IPsec or 
encrypting NIC for further hardening.

Throwing hardware at the problem, as this has been known.

Spent a whole lot of time and effort and hardware and thought doing that, too.

BTW: DEC offered the DESNC as an upgrade, though that DEC product was 
less than commercially successful.  And there are modern NIC-based 
equivalents.  But I digress.

How to attack this network?  I'd go after the staff and the AD and then 
the switches, if I really need access to the data traversing those 
locked-down DECnet links.  At the home networks of your staff, for 
instance.  At the coffee shop or pub that your IT staff frequents.  At 
the Wi-Fi in the vehicles used by key staffers.  I'd look to use a 
Wi-Fi Pineapple in various locations not necessarily your office, and 
capture whatever data might be available.  I'd look to spoof my way 
into the building.

As an attacker presented a hardened target, I'm going around.  Or I'm 
going elsewhere.  Elsewhere in your network and your security and your 
staff, or elsewhere and—if your work is successful—after some other and 
completely-unrelated target entirely.

>> Am I certain to get into the DECnet network?  No.  Can a good team 
>> block these paths?  Sure.  But I'm still not inclined to prefer to run 
>> unencrypted and unauthenticated and cleartext network traffic.
> 
> Here, I think most would agree with you.  If I were at a place that 
> wanted to continue to run DECnet in today's world...

DECnet has been in maintenance for ~25 years.   Lots of changes over 
that time, too.  To networking. To security. To the amount of money 
sloshing around.   To the effort and expense that (some) folks are 
willing to pay when going after a target, too.

We're still using DECnet in various installations because the migration 
has been a dumpster fire, and the network security on OpenVMS is still 
a mess, and that whether we're discussing TLS, IPsec, or VPN.  Or 
DECnet.

And as was mentioned earlier in the thread, if an organization reduces 
the scope of a pentest or of a bug bounty, then they are more likely to 
get the answer they want.  But maybe not the answer they need.

Same applies for security.  Or military defense strategies, for that 
matter.  An attacker will look for the weaknesses, and will bypass the 
hardest and strongest parts.





-- 
Pure Personal Opinion | HoffmanLabs LLC