FireEye Hacked

[AlecTrevelyan]

https://www.scmagazine.com/home/security-news/apts-cyberespionage/fireeye-hacked-red-team-tools-stol...

[JKWiniger]

My first question of course would be do we use the product and if so shut it down! Second step would be to apply the rules provided on GitHub to block any infection if we do use the product. Then have everyone being vigilant about looking for suspect activities and reporting what is seen.

I do believe this might mark a turning point in the information security industry. When private companies are attacked that's one thing, but now that the government has been attacked we may see new laws coming out to help prevent this from happening in the future. I can't even imagine what kind of slip ups and checks did not occur for a piece of malware to get into an update and be digitally signed? Are there no scans or checks in place? This goes back to where I believe that companies and programers need to start being held accountable for releasing poor code. To make matter worse the creation of bug country programs to counter their own bad programing breeds and environment for people to learn and be encouraged to find ways to compromise things. From there it is only a fine ethical line from good intention to bad intention.

My .02

John-

[tmekelburg1]

---

@JKWiniger wrote:

I can't even imagine what kind of slip ups and checks did not occur for a piece of malware to get into an update and be digitally signed? Are there no scans or checks in place?

---

With the sophistication behind this attack, it kind of sounds like this specific tool was targeted because of it's penetration into fortune 500 and Government clients. They did have their biggest clients very brazenly listed on their webpage and recently took down. Anything specifically you can discuss about how your company or clients are handling this or thoughts on the matter? @Caute_cautim @dcontesti 

https://www.solarwinds.com/company/customers 

[JKWiniger]

@tmekelburg1 You bring up a good point, when companies display their clients so openly they make it easy for attacker to know who to go after. This is like how on LinkedIn profiles and looking at job descriptions you often get a pretty good idea of the technology that is being used inside a company so it make it much easier to craft attacks. I believe there should be a general rule that this type of disclosure should probably not be allow.

John-

[ericgeater]

I can only think, "how do you establish defense-in-depth when something so central and this critical goes horribly wrong?".

Written for 2020, "Did anyone have 'Premier monitoring and maintenance tool for managed services providers and governments alike becomes unwitting CozyBear agent for six months' on their bingo card?"

[Caute_cautim]

HI John,  Yes, specifically Whitelisting and Characterisation has been around for some time.

Some governments insist upon both whitelisting and Characterisation to put in place - it is difficult but not impossible.  It is part of the Australian Government Essential 8:  https://www.sans.org/reading-room/whitepapers/critical/paper/38575

NIST also have a paper on how to implement it too:  Some vendors i.e. Juniper for instance actually build into their products from the outset to identify malware or manipulation of the updates or source code.   There are systems such as Carbon Black who provide good support, but it takes time - it frustrates Unix, Linux and Microsoft delivery teams having to deal with this, so they attempt to override it, but in fact as per the recent events, bypassing it can be extremely costly.  However, it is an important factor, trust nothing until proven it has not been manipulated or altered etc.  

Ensure secure source of software updates, normally a secure proxy pointing to the known and confirmed vendor web site or portal etc.  Then validate current state, apply integrity checking of source and verify i.e. hashing, test and apply - it all takes time.    Automation and orchestration is a way forward, manual approach is extremely frustrating for support staff.

https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final

Some apply Tripwire or NTT Change Tracker R2 for instance which includes AI and is reasonably charged, whereas the Tripwire needs constant technical support from the internal staff from experience.    A lot of banks tend to use it, but they do train their internal staff very well too.

Regards

Caute_cautim

[tmekelburg1]

---

@Caute_cautim wrote:

HI John,  Yes, specifically Whitelisting and Characterisation has been around for some time.

 Ensure secure source of software updates, normally a secure proxy pointing to the known and confirmed vendor web site or portal etc.  Then validate current state, apply integrity checking of source and verify i.e. hashing, test and apply - it all takes time.    Automation and orchestration is a way forward, manual approach is extremely frustrating for support staff.

---

Would those software update checking programs have caught it if it was digitally signed by the owner?

"SolarWinds.Orion.Core.BusinessLayer.dll is signed by SolarWinds, using the certificate with serial number 0f:e9:73:75:20:22:a6:06:ad:f2:a3:6e:34:5d:c0:ed. The file was signed on March 24, 2020."

[JKWiniger]

I guess having the mentality of do it right or don't do it at all leaves me a bit... I'm not sure what the right word would be... maybe annoyed. Far too often companies are just more concern with getting the product out and making money so they rely heavily on rapid application development and cut corners and I just don't agree with that. I feel like the burden gets put onto the end user / company to stay up on patch management when if the products where made better there wouldn't be such a high need. I just think places need to slow down and focus a bit more on the quality of the product and less about the quantity.

John-

[tmekelburg1]

Just listened to SANS Emergency Webcast: What you need to know about the SolarWinds Supply-Chain Attack hosted by Rob Lee and presented by Jake Williams 

It's free to view after making an account or logging in. Key takeaways:

• If you have SolarWinds Orion, assume compromise
• Check logs for C&C and Beacon domains released by FireEye
• If you have other SolarWinds products, assume those could be compromised as well. We don't know how SolarWinds was breached and if they tampered with other products
• Block your Network Management System (NMS) from the Internet or explicitly allow limited access to destinations (Zero Trust)
• Segment access within your NMS. One set of credentials to read and another to make changes (this can be further segmented as well)
• Attackers will retool, don't expect this group to use Sunburst malware going forward
• Attribution is not important, it shouldn't affect how you respond or mitigate 

[denbesten]

This is a good opportunity to invoke "never let a perfectly good crisis go to waste".

CISA does have response recommendations, but as CISSPs, our focus belongs more on the bigger picture than running the incident.  CISA's comment “Rebuild hosts monitored by the SolarWinds Orion monitoring software….” is a powerful statement from an influential organization,  basically asking you to rebuild everything you truly think important to your business (in some scenarios).  Coupled with the fact that your CIO is likely already asking if we are amongst their 300k customers creates a great opportunity for a "concentration of power" discussion.

Discussion points on the email I already sent to my colleagues:

1. Monitoring should be uncredentialled or read-only and any necessary accounts should have minimum privileges.
2. All High-privilege accounts should be stored in our secure privileged access vault with controls surrounding how they may be checked out, including by automated management systems such as Solar Winds.
3. Review controls surrounding our internal software packaging/distribution and our remote-admin tools, particularly those that work without user consent prior to each session.
4. Review our Solar winds architecture with respect to the CISA guidelines and to minimize its need for privileged access.
5. Ditto for all other system management tools, not just the monitoring tool.
6. Network segmentation/isolation for critical business applications (not just Solar winds)

Oh, also don't forget that the reading/research you do for this (such as the SANs video) are good for CPEs.

Finally, I do note that this attack comes at a particularly interesting time for the USA, politically speaking, and involves an fascinating set of actors, but the conspiracy theories surrounding that belong somewhere other than this community.

[Caute_cautim]

Hi All

Those of you who have been asleep at the wheel focusing on other things, had best look at this over 18000 companies have been compromised using the tools stolen from Fireeye recently.   Solarwinds is just one of those IT monitoring system many companies use.   So patch now and be vigilant, this is not going away.

Look at the effect on their value in the market - excellent examples for your respective organisations.

https://seekingalpha-com.cdn.ampproject.org/c/s/seekingalpha.com/amp/article/4394717-solarwinds-hack...

Regards

Caute_cautim