Hackers went undetected in Citrix’s internal network for six months
techcrunch.com
techcrunch.com
How did Citrix not have 2FA in place?
Lower level Windows authentication mechanisms can't be configured for 2FA. If your active directory domain is functional at all then at the very least your systems need to be able to talk via SMB and ldap to a domain controller. With sufficient privileges you're able to execute code on other machines via either protocol.
You only need an infected machine, not even user credentials, to be able to perform password spraying or kerberoasting attacks.
Just think of any backend protocol that the system uses. The vast majority of those can't be 2FA'ed. This is not Windows specific either. The same is true for most all protocols.
This is why most companies buy firewalls and VPNs and only 2FA the VPN. That meets most compliance requirements and is simple to do. Is it secure? Probably not, but it checks the box (makes audit happy), so buy compromise insurance and move on.
I think Obama said "no comment" to reporters, but then basically admits it by talking about how he regrets that this information got out into the public.
The best you can do is to make some educated guesses (by looking at the timestamps, coding patterns, comments in the code, who might be interested in hacking the target, political connotation to the attacks etc.). That's usually how state-sponsored attacks get attributed.
For example, "Guccifer" used GTM+3 settings and attacked DNC a few hours after Trump publicly "hoped" that Russians will find the emails. That doesn't confirm that it was sponsored by Russia, but it makes it an educated guess.
https://foreignpolicy.com/2016/10/17/obamas-general-pleads-g...
Compare that to unauthorized access to a machine and cleaning the logs behind you... One doesn’t have to be more brilliant than the authors of stuxnet to do something illegal without getting caught.
So even if it's someone with valid access, it would be investigated immediately.
> Accenture told Marriott's IT staff that one of their security products, a database monitoring system called IBM Guardium, had detected an anomaly on the Starwood guest reservation database
https://www.zdnet.com/article/marriott-ceo-shares-post-morte...
Hiding on a box is easy. Hiding on the wire is hard.
I assume you rather meant 'connections originating from IP addresses owned by Chinese companies'? It's trivial to use IP address from any place in the world, regardless of your actual location.
Is there any blog or news that summarizes such post-mortem lessons? Could be a nice project to collect that.
Most small start ups don't get to the level where anyone that "big" is looking at them but in the event that something does get flagged the agency will go find their CEO/CTO/counsel on LinkedIn and either message them there or email them. I've never seen an actual vulnerability disclosed in email, if it's a potential legal issue (hello SEC and fintech) they may ask that your lawyer responds to them in writing but more often it's just "this is Agent XYZ with ABC. I have information about your company, please call me immediately."
For someone bigger (like Citrix) the company is hopefully big enough to have a team that is connected to the agencies in someway. Either the agency knows someone who knows them, or they have a designated Security and Compliance team that can handle these inquires.
The real problems come when you're in the middle of sizes - too big to have eyes on every email but too small to have a real security team.
About 5 years I was working for a SaaS company and one of our clients accidentally discovered a pretty serious hole in another company's product. This client wasn't overly tech savy and was basically like "hey is this how this is supposed to work?" when it very much was not... so we killed the API connection and told the client we'd take care of it. It's about 7pm ET by the time we figure out what's going on so we call and email the other company but couldn't find anyone. In the end we got the home phone number of their CTO and had our CTO call him at around 10pm. He thought it was a prank call but once our CTO convinced him this was a problem he was able to get their on call eng to patch it within hours.
Nowadays almost any company involved in security work either has a direct line to FBI/DHS or has a vendor who does. ie if I'm some medium consumer platform I probably don't get to talk to the FBI directly, but if I called up Crowdstrike or any security consulting firm they could do that. In the event that my medium consumer platform was infiltrated by Fancy Bear (and the government decided to tell me, sometimes they don't) an FBI agent would email/call the most likely point of contact for the fastest resolution without causing panic. Lots of time the damage is already done, two vs four hours on a response won't make a big difference in the long term so no need to email info@ or anything.
Over the past 6-8 years the corporation on public/private cyber investigations has definitely changed as red tape has decreased in sharing of info has increased - even more the last 4ish years since the DNC email hacks. I've had a clients get a casual "just a heads up, you should check this out" from the government without no paperwork and no follow up, something that would have been virtually unheard of 8 years ago.
DHS gets a lot of shit in the media (lots of which is deserved) but they've done a pretty good job just opening basic lines of communication and training other agencies that spending 20 minutes looking at a random tip, and following up if needed, is actually a pretty good use of time.
> [T]he hackers had “intermittent access” to its internal network from October 13, 2018 until March 8, 2019, two days after the FBI alerted the company to the breach.
Lots of companies still haven't upgraded to zero trust / BeyondCorp AuthN, and lots of companies don't have reproducible signed build artifacts from CI/CD with automatic policy enforcement regarding the properties that those build artifacts must have before they can be deployed.
High-profile companies that think VPNs and networking rules are a security solution have probably already been hacked and just don't know it yet.
Not saying Citrix security is perfect, but protecting yourself from this kind of attack is certainly not as simple as "Add 2FA and limit login attempts".
I'm especially interested because I had an offer from Citrix that I eventually turned down.
One thing that frustrates me more than anything else is people assuming that their corporate network is safe. Your firewall and your vpc or whatever is a speed bump at best. You have to assume that you have an attacker on the desk right next to you, because you will eventually.
I really wish we moved past the "everybody's owned" idea. Your defence should be proportional to the value you can lose. You can monitor for the rest. And you can't guarantee the are hackers in my network. (Unless you're saying you're guilty of breaking in? ;-) )
This of course does not apply if you are not holding on to anything interesting, but it’s very easy to become interesting at a certain size, or if you have interesting customers. Still, not everybody.
Recall that the Target POS hack back in 2014 happened because someone hacked the largest refrigeration contractor in western Pennsylvania, then bounced from there onto the Target Partners Online portal with legitimate credentials, and then from there in unspecified ways got onto the POS system. Obviously going from TPO to POS is a failure of Target's network security, but their network perimeter was much larger than just Target computers.
If your internal services are built to public-facing standards it’s a shrug.
Not many software can do this.
[0] https://www.citrix.com/analytics/prevent-security-breaches.h...
Wow. This simply reinforces the fact that humans cannot, and should not, be trusted with actively maintaining security of a system especially if there could be significant economic consequences.
Would a password manager help in this? I don't know.
Probably a hardware token which controls all and any access to a system.
*Removed some ambiguous sentences.
People should use a password manager with an rng to generate and store passwords. IT departments should run password spraying attacks themselves as well as blacklisting known-compromised passwords. There's really good tooling for this (likely the same tooling this adversary used!)
Separately from this, people should use hardware 2fa tokens whose weakest link isn't the cell phone company support.
Edited for clarity.
This probably makes 2FA moot for some scenerios. For scenarios where losing the token is a real risk, you would implement 2FA.
Use 2fa everywhere. It's cheap, easy, and significantly more effective.
Consider the following attacks which your suggestion provides no coverage for:
- Http downgrade (both SSLstrip and export-grade downgrade)
- Spear-phish
- Key-logger
- Spear-phish
- Shoulder-surf
- Spear-phish
- Evil maid (borrows device and compromises passwords)
And last but not least, spear-phish
Again, if a hardware 2FA token can deal with key-loggers, so can a password token.
Why would someone be able to shoulder-surf a display-less password token? You log on to the website, insert the device and the website proceeds to authentication without revealing anything.
Evil maid is the only legitimate attack I can agree with.
>attacks on the distant end system, as well as attacks on the password device itself.
This is not something that a hardware 2FA token is also foolproof against.
>Passwords make it tricky to audit if they've been duplicated.
This is a valid point.
My point may not be applicable for super sensitive systems but for a lot of services it should be sufficient enough. I'm saying so because I'm having a hard time getting my family/friends to use a password manager (specifically 1Password). They do not see the need, find it additionally complex and are turned off by the subscription pricing (I'm paying for my family though!). Syncing is also hard. I was hoping that a pure hardware token would make it more convenient and a one time 20-40 USD price is more palatable than 60 USD every year.
Do you have any idea why this is not popular? Is it too hard to implement or is it just that business's do not see security as something to invest a lot in?
https://www.yubico.com/solutions/fido-u2f/
https://webauthn.guide/ for an intro
https://www.w3.org/TR/webauthn/ for the JS API
TOPT codes are completely phish-able using ridiculously easy to setup kits out there like CredSniper[0]. Set up a MITM proxy authentication site, get the user to live authenticate through the proxy, steal the session cookie, game over.
Some of the feedback that has come out of internal campaigns has been things like "I thought the URL looked weird, but the email said it was a beta site, and I got the Duo push notification for the second factor so it seemed legitimate."
That's the real danger in 2FA mechanisms outside of U2F: people believe it protects against phishing, and it absolutely does not.
By all means, move towards a hardware-based 2fa setup. But don't let that prevent intermediate steps to improve security along the way.
Your example is also deeply flawed as it can be used to steal auth tokens for 2fa sites, even if they use Fido. Mitm is game over.
[...]
> Separately from this, people should use hardware 2fa tokens whose weakest link isn't the cell phone company support.
What would be better is to support certificate based authentication in combination with a username and password. Then you have 2FA without having to share the private key. You can even get 3FA if the private key requires a passphrase to decrypt it.
Using SMS or email based 2FA is not secure (or is only as secure as the email or cell phone account as you already pointed out). Using TOTP requires sharing a secret between the device and the server.
What I proposed was using a client-side TLS certificate in combination with the username/password for authentication. If the private key corresponding to that certificate requires a passphrase to decrypt, then it should be more than 2FA. What you know is the username/password, what you have is the private key. Whether the passphrase for that private key is considered what you know vs what you are is debatable (since, unlike the username/password or one-time token, the secret isn't shared by transmitting it over the network).
Also, this isn't tied into a specific application level protocol. This can be done over other other application level protocols like SMTP, IMAP, NNTP, IRC, etc.
From what I've read about U2F[1], you need to use Google Chrome. Just checking the preferences/settings for both Firefox and Chrome, they both have the option of importing client side TLS certificates. Thunderbird also has the option of importing client side TLS certificates.
To put it another way, my browser can tell I'm connecting to news.ycombinator.com by using the certificate authority bundle installed on my machine. I don't need any external service or new standard to accomplish this. The same principle applies to client side TLS certificates.
Third, yubikey is not only supported by chrome. I've used it with IE and Firefox just now to verify.
Fourth, yubikeys provide significant additional security as you cannot lose control of the private key without realizing it, even if your box is owned. The yubikey requires you to physically press a button to approve any action it takes with the private key. Soft certs are gone once they're decrypted in RAM (there's automation for this exact thing in many RATs).
Source: NIST has advocated for mutual auth with PIV for over a decade. They are now moving away from it and towards WebAuthn, because it's (mutual auth with certs) simply not as good.
Once the user installs the certificate, then their browser would use it during the TLS connection. If the signature couldn't be verified, then the connection wouldn't be established, or it could be, but without the client side TLS part of it (depending on how the webserver is configured). The login attempt could then be restricted because the client side TLS negotiation never took place.
> huge management headache dealing with CSRs securely.
Let's take a website like news.ycombinator.com. When I click on the login link, it gives me the option to provide credentials or create a new account. If I choose to create a new account, I'm asked to provide a new username and password. They could add a field that would allow me to submit a CSR along with an email address they could email the signed certificate to.
Then I could get the certificate by email, import it into my browser and then use it along with the new username and password to log in with my new account.
For equivalent online accounts, a workflow like that should be good enough.
> Third, yubikey is not only supported by chrome. I've used it with IE and Firefox just now to verify.
They should update their website. The link I cited earlier still has the following quote:
>> What browsers support the U2F-certified Yubikeys?
>> You must be running the latest version of the Google Chrome browser, which includes support for the U2F protocol. To check the version number, in your browser, click the Chrome menu in the toolbar, then select About Google Chrome. (Support for U2F is in versions 38 and later.)
>> At this time, Chrome is the only browser supported. However, Mozilla is currently building support for U2F and Microsoft is working within the FIDO Alliance to eventually bring support to Windows 10.
> Fourth, yubikeys provide significant additional security as you cannot lose control of the private key without realizing it, even if your box is owned. The yubikey requires you to physically press a button to approve any action it takes with the private key. Soft certs are gone once they're decrypted in RAM (there's automation for this exact thing in many RATs).
While this is true, is this something that I can currently use with my email/news client? What about my IRC client? I know that I can use client side TLS certificates with both.
> They are now moving away from it and towards WebAuthn, because it's (mutual auth with certs) simply not as good.
What do they plan to do to address more secure authentication over other protocols besides HTTPS?
2FA does not become 3FA when adding a new passphrase to a system that already had a knowledge based entry.
A password for a private key is _never_ considered what you are. You are severely misusing security terms and will mislead people to believe that a proposed solution has greater strength than it really possesses.
Then explain how authentication via a username and password validated server side, a client-side TLS certificate validated during the negotiation of a TLS connection between the client and server, and a passphrase validated locally on the client's device is not a better solution compared to typical 2FA implementations using email, SMS, or TOTP.
More importantly, this is also a false dichotomy, as the correct answer here is hardware protection of the private key, e.g. yubikey.
That essentially means the entire machine is compromised and logging into any service would allow the adversary to access them. That would compromise the email and SMS routes. If they have root access to my phone (or whatever I use to store the TOTP secret), that would allow them to generate the correct one time token to log into any service that I use TOTP 2FA with.
> With email/sms, at least it's possible for you to realize they're compromised
That's assuming I check carefully and often enough. If someone brute-forces my password over IMAP, then they could read my messages without me ever knowing. But I could always check the process list on my computer to determine if a keylogger is installed.
> and with TOTP the underlying keymat is likely not on the device so the attacker has to repeatedly win the race.
It depends on the application. If someone got access to my phone, they could easily get the TOTP secret out of my GAuth app.
> the correct answer here is hardware protection of the private key, e.g. yubikey.
Except that it's not universally supported. It's not going to work with my email client nor will it work with my IRC client.
While U2F, as mentioned in other posts, will protect against those scenarios, it doesn't appear to support application protocols other than HTTPS.
If that is the threat you are guarding against, that is the very reason for using different factors. In that way, you ensure that people cannot log in with credentials, even if they have them.
In the same way, an atm card cannot get you money, even if you stole it. In the case of an atm card and a pin, you need two factor classes, what you have and what you know.
Regarding the other part of your prior comment that incorrectly used 2FA, that is why Apple uses the terms separately, "two factor auth" and "two step auth". They are not the same.
> you ensure that people cannot log in with credentials, even if they have them.
Except that you left out the second part of that sentence:
>> or being able to bypass the log on process by using the conventional second auth factor against me (by doing the same thing to my email account and/or my cell phone provider).
For example: https://www.nbcbayarea.com/news/local/Mans-1M-Life-Savings-S...
In that case, the person was a victim of a SIM swap scam which redirected password reset messages to the attacker's cell phone, which then allowed them to access the account.
Regardless of how I initially termed it, having another factor just local to the device one is using rather than a 3rd party service that can be compromised in a way that you may not immediately realize is a far better way of doing multi-factor or multi-step auth.
But this solution should not just be limited to the HTTP application level protocol. It should also be available for other application level protocols (IMAP, SMTP, NNTP, IRC, etc). That means that U2F needs to account for this, or we should have more support for using client-side TLS certificates as part of the authentication process.
But rather than addressing the issues where a 3rd party serving as a second factor/step can be compromised without the account holder realizing it in time or the fact that U2F doesn't support other protocols besides HTTPS, you keep going on and on about "security points" which appear to be nebulous in the context of this discussion and also cherry-pick my responses only to go off on a largly irrelevant tangent.
This discussion could have been useful, but, unfortunately, it didn't turn out that way.
Yes, there is a fixation on security, since authentication is a security function that is often gotten wrong when people don't know the threat model and rush through a solution. This has been pointed out to you by several people more than once in this very thread.