4 ms·

If it turns out that their web server has 100% unfettered access to the database then I'll gladly pick up a pitchfork as well. You may want to think twice. Try

If it turns out that their web server has 100% unfettered access to the database then I'll gladly pick up a pitchfork as well. You may want to think twice. Try to design an architecture that doesn't have that. If you think it through, you'll realize the best you can do is not to deny access, but to monitor access so that any statistical deviation in requests-per-hour will trigger an alarm. Yet nobody does that, so why should Equifax have been a pioneer in this method? This is the uncomfortable truth that everyone is obscuring here. There wasn't a solution. Equifax got owned, and they happened to have a trove of data. Everyone now wants to see their heads roll, but you too would find yourself in the same situation if you have an RCE on your servers.

Iknowsecurity 9y ago
Agreed
kelnos 9y ago
> You may want to think twice. Try to design an architecture that doesn't have that. We have an architecture like that where I work. It's not that hard. Our web applications have very little direct access to databases; most of it is mediated by services downstream of the web app. That's certainly not a silver bullet, but it makes it impossible to exploit a RCE vuln in the web server in such a way that it lets you have arbitrary access to the database.
- sillysaurus3 9y ago
  Have you had a netpen? Give me access to your web server (aka an RCE) and I can probably find a way to pivot to your downstream databases.
  - theossuary 9y ago
    That's the point, you have to pivot. If you don't have to jump through another host or two to get unfettered database access from web tier, you're doing it wrong.
    - sillysaurus3 9y ago
      It wouldn't have changed Equifax's situation at all. Everyone would still be just as outraged. It occurs to me that maybe it might seem like pivoting is a big process that takes months. In reality you can map out an internal network within a few hours. Most people keep the servers at the edge of their network meticulously up to date. Once you're inside, you find way more old software. Not to mention creds just laying around the system in many cases since the devs don't expect anybody to be able to access them. I feel like the worst offense Equifax could be accused of is not getting regular pentests. A netpen would have caught the outdated Struts issue, and they had money to get monthly tests. But very few of us get regular pentests.
      - occultist_throw 9y ago
        That's one thing the org I work for does right. We do have monthly tests, scans, and network BGP issues. And our governmental side has a different set of scans, which also include system security scans. Whomever the oncall is, ends up doing them during the week. It's usually pretty quick, but can turn into a slog. Oh, and all our machines are updated appropriately, not just the border machines. There are some services we're not able to adequately update, like FreeRadius - but for each of those we review the criticality and determine if we need the resources to make it work (aka: remote priv exploit)
  - munin 9y ago
    I have done netpens. Almost always it is as you describe. Sometimes someone has their shit together and it is not.
- jeremyjh 9y ago
  And let me guess. Those services give the webservers...the data that they ask for? Once you've compromised a server, learning how to ask for the data you want is not hard. You have access to all the webserver's code, can make full dumps of communications occurring normally in the app, etc.
  - icebraining 9y ago
    The believe the usual way is to have a separate authentication service, to which you send the user's credentials and you get a token that you can use to request only that user's data. That means, barring other exploits, you can only access the info from the users who logged in while you had control of the machine.
  - kelnos 9y ago
    It's different, though. If my web server has direct database access, and it gets compromised, an attacker can go in and directly do "SELECT * FROM users" and get all my data in one go. If the database is behind a restrictive service, and they compromise just the web server, then they have to sit on the web server and pull each user record one at a time. And they might not even be able to, depending on search options -- like they might just be able to do "GET /users/{userId}", and if you don't know the user IDs, you get nothing (our user IDs happen to be randomly-generated 128-bit numbers, so searching through that space would take a while). Even if they can get past that hurdle, the extra traffic it would require to pull down the full database with one request per user would certainly set off alarms, and doing it slowly enough to not set off alarms would just take too long. Of course, another option would be to use the web server compromise to then jump to the database service and compromise that box as well, but, again, more hurdles to jump means less of a chance of success. Nothing is perfectly secure, but you can design systems with defense in both breadth and depth, and you can slow down or defeat many attackers that way. It's not about making Fort Knox, it's just about making breaking in more expensive than they can handle.
williamscales 9y ago
I broadly agree with you, but disagree with your claim that Equifax has no duty to innovate in security. They have one of the biggest databases of PII in private industry. I believe that bestows on them the duty to keep it safe.
Boothroid 9y ago
There are lots of companies offering software to do exactly what you describe, that is, statistical analysis of telemetry as a way to detect anomalous behaviour e.g. LogRhythm
biafra 9y ago
The problem is that this information can be used for identity fraud. You should really find a solution for that problem.

Iknowsecurity 9y ago

Agreed

kelnos 9y ago

> You may want to think twice. Try to design an architecture that doesn't have that. We have an architecture like that where I work. It's not that hard. Our web applications have very little direct access to databases; most of it is mediated by services downstream of the web app. That's certainly not a silver bullet, but it makes it impossible to exploit a RCE vuln in the web server in such a way that it lets you have arbitrary access to the database.

sillysaurus3 9y ago
Have you had a netpen? Give me access to your web server (aka an RCE) and I can probably find a way to pivot to your downstream databases.
- theossuary 9y ago
  That's the point, you have to pivot. If you don't have to jump through another host or two to get unfettered database access from web tier, you're doing it wrong.
  - sillysaurus3 9y ago
    It wouldn't have changed Equifax's situation at all. Everyone would still be just as outraged. It occurs to me that maybe it might seem like pivoting is a big process that takes months. In reality you can map out an internal network within a few hours. Most people keep the servers at the edge of their network meticulously up to date. Once you're inside, you find way more old software. Not to mention creds just laying around the system in many cases since the devs don't expect anybody to be able to access them. I feel like the worst offense Equifax could be accused of is not getting regular pentests. A netpen would have caught the outdated Struts issue, and they had money to get monthly tests. But very few of us get regular pentests.
    - occultist_throw 9y ago
      That's one thing the org I work for does right. We do have monthly tests, scans, and network BGP issues. And our governmental side has a different set of scans, which also include system security scans. Whomever the oncall is, ends up doing them during the week. It's usually pretty quick, but can turn into a slog. Oh, and all our machines are updated appropriately, not just the border machines. There are some services we're not able to adequately update, like FreeRadius - but for each of those we review the criticality and determine if we need the resources to make it work (aka: remote priv exploit)
- munin 9y ago
  I have done netpens. Almost always it is as you describe. Sometimes someone has their shit together and it is not.
jeremyjh 9y ago
And let me guess. Those services give the webservers...the data that they ask for? Once you've compromised a server, learning how to ask for the data you want is not hard. You have access to all the webserver's code, can make full dumps of communications occurring normally in the app, etc.
- icebraining 9y ago
  The believe the usual way is to have a separate authentication service, to which you send the user's credentials and you get a token that you can use to request only that user's data. That means, barring other exploits, you can only access the info from the users who logged in while you had control of the machine.
- kelnos 9y ago
  It's different, though. If my web server has direct database access, and it gets compromised, an attacker can go in and directly do "SELECT * FROM users" and get all my data in one go. If the database is behind a restrictive service, and they compromise just the web server, then they have to sit on the web server and pull each user record one at a time. And they might not even be able to, depending on search options -- like they might just be able to do "GET /users/{userId}", and if you don't know the user IDs, you get nothing (our user IDs happen to be randomly-generated 128-bit numbers, so searching through that space would take a while). Even if they can get past that hurdle, the extra traffic it would require to pull down the full database with one request per user would certainly set off alarms, and doing it slowly enough to not set off alarms would just take too long. Of course, another option would be to use the web server compromise to then jump to the database service and compromise that box as well, but, again, more hurdles to jump means less of a chance of success. Nothing is perfectly secure, but you can design systems with defense in both breadth and depth, and you can slow down or defeat many attackers that way. It's not about making Fort Knox, it's just about making breaking in more expensive than they can handle.

williamscales 9y ago

I broadly agree with you, but disagree with your claim that Equifax has no duty to innovate in security. They have one of the biggest databases of PII in private industry. I believe that bestows on them the duty to keep it safe.

Boothroid 9y ago

There are lots of companies offering software to do exactly what you describe, that is, statistical analysis of telemetry as a way to detect anomalous behaviour e.g. LogRhythm

biafra 9y ago

The problem is that this information can be used for identity fraud. You should really find a solution for that problem.