Rich Kulawiec via plug on 31 Dec 2020 08:54:33 -0800


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] OT: SolarWinds


On Sat, Dec 26, 2020 at 08:01:20AM -0500, Rich Freeman via plug wrote:
> Only on an FOSS mailing list will you hear somebody just toss out that
> using Office365 is "well-known" to be a worst practice.

Yes, "well-known".  At this point, observing that Office365 is insecure
is somewhat like noting that the ocean is wet.

But if somehow you missed this, let me help you out, including a way
for you to independently prove this to your own satisfaction.

One of the fundamental principles of Internet operational security is
that outbound abuse/attacks from any operation are a surface indicator
of underlying security issues.  Those surface indicators may or may not
give clues as to what the underlying issues really are -- but they're
an existence proof.  And if those surface indicators are chronic and/or
systemic, then the underlying issues are chronic and/or systemic.

With that in mind, let me show you something:

	theirhost.2048 > myhost.22: S 330661887:330661887(0) win 64240 <mss 1440,sackOK,timestamp 2887943854 0,nop,wscale 7> (DF)
	theirhost.2048 > myhost.22: S 2916380755:2916380755(0) win 64240 <mss 1440,sackOK,timestamp 2888492739 0,nop,wscale 7> (DF)
	theirhost.2048 > myhost.22: S 1130043971:1130043971(0) win 64240 <mss 1440,sackOK,timestamp 2888801188 0,nop,wscale 7> (DF)
	theirhost.2048 > myhost.22: S 560813747:560813747(0) win 64240 <mss 1440,sackOK,timestamp 2889099664 0,nop,wscale 7> (DF)

	[about 15,000 lines elided]

That's a set of log entries from pf.  I've replaced the IP addresses
with "theirhost" and "myhost".  Note the destination port: 22.  Every one
of those lines is associated with a pair of log entries like this:

	myhost sshd[33071]: Failed password for root from theirhost port 2048 ssh2
	myhost sshd[33071]: Received disconnect from theirhost: 11: Bye Bye [preauth]

It's a brute-force ssh attack.  "Myhost" is one of mine.
"Theirhost" is inside Office365.

Which means that there are two and only two possibilities here:

1. It was someone/something working for Microsoft.

	Which means that for some inexplicable reason someone at
	Microsoft decided to take a brute-force run at root on one of
	my systems via ssh.  I'm a very harsh critic of Microsoft, but I
	doubt anybody working there is stupid enough to try this, doubly
	stupid enough to try it from a source address inside Office365,
	and triply stupid enough to try it against a target that's
	publicly announced itself as a honeypot.  (BTW, in case
	you're wondering: no, the source address wasn't spoofed.)

2. It wasn't someone/something working for Microsoft.

	Which means that someone who doesn't work there (or does work
	there but isn't actually working for Microsoft) had/has at
	least enough control over a system inside Office365 to launch
	outbound attacks.

In either case, there is quite clearly a security problem in the
originating operation.

(Also, in either case, this means that whoever's managing Microsoft's
firewalls hasn't blocked outbound ssh from the Office365 infrastructure.
That's a rather obvious security failure in and of itself.)

This is one (1) datapoint.  I have a lot more of these.  A *lot*.
And they're diverse, including all kinds of attacks and abuse.  They go
back many years.  You could amass a similar collection, if you did your
own research.

In fact, I invite you to do that very thing: set up a couple dozen
of your own hosts.  Diversify them by network, domain, OS, HTTP server,
DNS server, IMAP server, MTA, etc.  Mark some as honeypots, don't mark others.
Log everything that you can.  Use passive OS fingerprinting where you can.

Then wait.  And watch.

After a few years it should become painfully clear to you that there are a
number of large, prominent, popular operations that have systemic and chronic
security and abuse issues.  Office365 is one of them, but it's certainly
not the only one.

So I don't have to prove any of this to you.  You can prove it to yourself
-- *if* you're willing to do the work.

If, on the other hand, you're not willing to do the work, then perhaps
you could consider learning from those of us who have.

This isn't news -- well, not to anyone who's been paying attention.
That's why I said it's "well-known".  Nor is it surprising: if you think
about it, this is more-or-less what we should expect to observe.  It would
be quite remarkable indeed if operations like this were secure.

Now, for the purposes of *this* discussion -- about SolarWinds -- they should
have known this.  They should have known that given the criticality of
their products -- a criticality they have bragged about constantly --
that outsourcing their email to ANY operation, let alone one that's
well-known to have security issues, was a massive mistake.


---rsk
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug