Return to Answer

From reading the disclosure, it seems what happens is that the open port isn't actually just a random port, but rather it is a port where a certain internal service that had never been designed to be exposed directly to the external world was listening on. If there is a vulnerability in that internal service, that might have allowed a possible attacker to obtain the API key of users that uses their service within the specified period of time.

While they do note that the attack looks like an automated attack rather than a targeted attack, it should be considered that sophisticated attackers often uses a highly visible automated attack to divert the server's and the sysadmin's attention away from another covert, targeted attack that are hastening at the same time, i.e. the big DDoS that causes a lot of attention is just a diversion.

A sophisticated attacker could have erased their tracks if they managed to gain privilege into the system to make it look like nobody has compromised important data. This is why they recommend changing your API keys, even though they found no evidence of the data being actually queried. Especially since this is a logging server that was compromised, and since sysadmin would usually use logs to detect compromise, a compromised logging server can hide what's truly happening.

A sophisticated attacker could also have left a backdoor/rootkit on the system to allow themselves to reenter the system at later date when everyone thought things have settled down, so they can do their actual attack at a more leisurely pace from inside the security boundary, which could be highly dangerous. This is why they are decommissioning the machine involved.

Or it could be that they may be doing this as a show to some potential security-conscious customers that are on the fence on buying decisions due to doubts about their security. This might shift the attitude of those potentials customers to decide to take up their service, since they're now reassured that the company wouldn't be keeping mum when there are vulnerabilities that might affect them.

Is there some reason that simply having open ports would be considered a potential compromise here?

Yes, the open port exposes an internal service that wasn't designed for external use. Services intended for internal use often lacks the security hardening that public facing services would get, because the assumption was that the service is only accessible from trusted machines. For example, an internal service might not use SSL to communicate within the trusted network, or they might not validate their inputs as thoroughly as they assume the trusted senders already does any necessary validations, or they might have administrative commands that can be used without authentication, because it assumed that any necessary authentications have been done by the public facing services.

From reading the disclosure, it seems what happens is that the open port isn't actually just a random port, but rather it is a port where a certain internal service that had never been designed to be exposed directly to the external world was listening on. If there is a vulnerability in that internal service, that might have allowed a possible attacker to obtain the API key of users that uses their service within the specified period of time.

While they do note that the attack looks like an automated attack rather than a targeted attack, it should be considered that sophisticated attackers often uses a highly visible automated attack to divert the server's and the sysadmin's attention away from another covert, targeted attack that are happening at the same time, i.e. the big DDoS that causes a lot of attention is just a diversion.

A sophisticated attacker could have erased their tracks if they managed to gain privilege into the system to make it look like nobody has compromised important data. This is why they recommend changing your API keys, even though they found no evidence of the data being actually queried. Especially since this is a logging server that was compromised, and since sysadmin would usually use logs to detect compromise, a compromised logging server can hide what's truly happening.

A sophisticated attacker could also have left a backdoor/rootkit on the system to allow themselves to reenter the system at later date when everyone thought things have settled down, so they can do their actual attack at a more leisurely pace from inside the security boundary, which could be highly dangerous. This is why they are decommissioning the machine involved.

Or it could be that they may be doing this as a show to some potential security-conscious customers that are on the fence on buying decisions due to doubts about their security. This might shift the attitude of those potentials customers to decide to take up their service, since they're now reassured that the company wouldn't be keeping mum when there are vulnerabilities that might affect them.

Is there some reason that simply having open ports would be considered a potential compromise here?

Yes, the open port exposes an internal service that wasn't designed for external use. Services intended for internal use often lacks the security hardening that public facing services would get, because the assumption was that the service is only accessible from trusted machines. For example, an internal service might not use SSL to communicate within the trusted network, or they might not validate their inputs as thoroughly as they assume the trusted senders already does any necessary validations, or they might have administrative commands that can be used without authentication, because it assumed that any necessary authentications have been done by the public facing services.

From reading the disclosure, it seems what happens is that the open port isn't actually just a random port, but rather it is a port where a certain internal service that had never been designed to be exposed directly to the external world was listening on. If there is a vulnerability in that internal service, that might have allowed a possible attacker to obtain the API key of users that uses their service within the specified period of time.

While they do note that the attack looks like an automated attack rather than a targeted attack, it should be considered that sophisticated attackers often uses a highly visible automated attack to divert the server's and the sysadmin's attention away from anotger covert, targeted attack that are hastening at the same time, i.e. the big DDoS is just a diversion.

A sophisticated attacker could have erased their tracks if they managed to gain privilege into the system to make it look like nobody has compromised important data. This is why they recommend changing your API keys, even though they found no evidence of the data being actually queried. Especially since this is a logging server that was compromised, and since sysadmin would usually use logs to detect compromise, a compromised logging server can hide what's truly happening.

A sophisticated attacker could also have left a backdoor/rootkit on the system to allow themselves to reenter the system at later date when everyone thought things have settled down, so they can do their actual attack at a more leisurely pace from inside your security boundary, which could be highly dangerous. This is why they are decommissioning the machine involved.

Or it could be that they may be doing a show to potential security-conscious customers that are on the fence about their security, that they take security seriously. This might shift the attitude of those potentials customers to decide to take up their service, since they're now reassured that the company wouldn't be keeping mum when there are vulnerabilities that might affect them.

Is there some reason that simply having open ports would be considered a potential compromise here?

Yes, the open port exposes an internal service that wasn't designed for external use. Services intended for internal use often lacks the security hardening that public facing services would get, because the assumption was that the service is only accessible from trusted machines. For example, an internal service might not use SSL to communicate within the trusted network, or they might not validate their inputs as thoroughly as they assume the trusted senders already does any necessary validations, or they might have administrative commands that can be used without authentication, because it assumed that any necessary authentications have been done by the public facing services.

From reading the disclosure, it seems what happens is that the open port isn't actually just a random port, but rather it is a port where a certain internal service that had never been designed to be exposed directly to the external world was listening on. If there is a vulnerability in that internal service, that might have allowed a possible attacker to obtain the API key of users that uses their service within the specified period of time.

While they do note that the attack looks like an automated attack rather than a targeted attack, it should be considered that sophisticated attackers often uses a highly visible automated attack to divert the server's and the sysadmin's attention away from another covert, targeted attack that are hastening at the same time, i.e. the big DDoS that causes a lot of attention is just a diversion.

A sophisticated attacker could have erased their tracks if they managed to gain privilege into the system to make it look like nobody has compromised important data. This is why they recommend changing your API keys, even though they found no evidence of the data being actually queried. Especially since this is a logging server that was compromised, and since sysadmin would usually use logs to detect compromise, a compromised logging server can hide what's truly happening.

A sophisticated attacker could also have left a backdoor/rootkit on the system to allow themselves to reenter the system at later date when everyone thought things have settled down, so they can do their actual attack at a more leisurely pace from inside the security boundary, which could be highly dangerous. This is why they are decommissioning the machine involved.

Or it could be that they may be doing this as a show to some potential security-conscious customers that are on the fence on buying decisions due to doubts about their security. This might shift the attitude of those potentials customers to decide to take up their service, since they're now reassured that the company wouldn't be keeping mum when there are vulnerabilities that might affect them.

Is there some reason that simply having open ports would be considered a potential compromise here?

Yes, the open port exposes an internal service that wasn't designed for external use. Services intended for internal use often lacks the security hardening that public facing services would get, because the assumption was that the service is only accessible from trusted machines. For example, an internal service might not use SSL to communicate within the trusted network, or they might not validate their inputs as thoroughly as they assume the trusted senders already does any necessary validations, or they might have administrative commands that can be used without authentication, because it assumed that any necessary authentications have been done by the public facing services.

From reading the disclosure, it seems what happens is that the open port isn't actually just a random port, but rather it is a port where a certain internal service that had never been designed to be exposed directly to the external world was listening on. If there is a vulnerability in that internal service, that might have allowed a possible attacker to obtain the API key of users that uses their service within the specified period of time.

While they do note that the attack looks like an automated attack rather than a targeted attack, it should be considered that sophisticated attackers often uses a highly visible automated attack to divert the server's and the sysadmin's attention away from anotger covert, targeted attack that are hastening at the same time, i.e. the big DDoS is just a diversion.

A sophisticated attacker could have erased their tracks if they managed to gain privilege into the system to make it look like nobody has compromised important data. This is why they recommend changing your API keys, even though they found no evidence of the data being actually queried. Especially since this is a logging server that was compromised, and since sysadmin would usually use logs to detect compromise, a compromised logging server can hide what's truly happening.

A sophisticated attacker could also have left a backdoor/rootkit on the system to allow themselves to reenter the system at later date when everyone thought things have settled down, so they can do their actual attack at a more leisurely pace from inside your security boundary, which could be highly dangerous. This is why they are decommissioning the machine involved.

Or it could be that they may be doing a show to potential security-conscious customers that are on the fence about their security that they take security seriously. This might shift the attitude of those potentials customers to decide to take up their service, since they're now reassured that the company wouldn't be keeping mum when there are vulnerabilities that might affect them.

Is there some reason that simply having open ports would be considered a potential compromise here?

Yes, the open port exposes an internal service that wasn't designed for external use. Services intended for internal use often lacks the security hardening that public facing services would get, because the assumption was that the service is only accessible from trusted machines. For example, an internal service often doesn't use SSL to communicate with trusted machines, or they might not validate their inputs as thoroughly as they assume the trusted senders already does most of the validations, or they might have administrative commands that can be used without authentication, because it assumed that any necessary authentications have been done by the public facing services.

From reading the disclosure, it seems what happens is that the open port isn't actually just a random port, but rather it is a port where a certain internal service that had never been designed to be exposed directly to the external world was listening on. If there is a vulnerability in that internal service, that might have allowed a possible attacker to obtain the API key of users that uses their service within the specified period of time.

While they do note that the attack looks like an automated attack rather than a targeted attack, it should be considered that sophisticated attackers often uses a highly visible automated attack to divert the server's and the sysadmin's attention away from anotger covert, targeted attack that are hastening at the same time, i.e. the big DDoS is just a diversion.

A sophisticated attacker could have erased their tracks if they managed to gain privilege into the system to make it look like nobody has compromised important data. This is why they recommend changing your API keys, even though they found no evidence of the data being actually queried. Especially since this is a logging server that was compromised, and since sysadmin would usually use logs to detect compromise, a compromised logging server can hide what's truly happening.

A sophisticated attacker could also have left a backdoor/rootkit on the system to allow themselves to reenter the system at later date when everyone thought things have settled down, so they can do their actual attack at a more leisurely pace from inside your security boundary, which could be highly dangerous. This is why they are decommissioning the machine involved.

Or it could be that they may be doing a show to potential security-conscious customers that are on the fence about their security, that they take security seriously. This might shift the attitude of those potentials customers to decide to take up their service, since they're now reassured that the company wouldn't be keeping mum when there are vulnerabilities that might affect them.

Is there some reason that simply having open ports would be considered a potential compromise here?

Yes, the open port exposes an internal service that wasn't designed for external use. Services intended for internal use often lacks the security hardening that public facing services would get, because the assumption was that the service is only accessible from trusted machines. For example, an internal service might not use SSL to communicate within the trusted network, or they might not validate their inputs as thoroughly as they assume the trusted senders already does any necessary validations, or they might have administrative commands that can be used without authentication, because it assumed that any necessary authentications have been done by the public facing services.