3 ms·

I'm going to guess it was simple spray-and-pray. (My account took its fair share of compromise attempts, too, probably because I use the same username everywhe

by patio11 13y ago

I'm going to guess it was simple spray-and-pray. (My account took its fair share of compromise attempts, too, probably because I use the same username everywhere so it's going to be in many modern dev-heavy password dumps.) Github is, for better or worse, a high-value target these days. Compromise of a Github account will often get you credentials which you can use to compromise high-value targets, for example production machines. (Example from the Rails world: if someone gets read access to your git repository, expect them to figure out your secret token which you use for HMACing sessions to prevent forgery. If an attacker can forge sessions, they have remote code execution on your production servers. You can assume they will go directly from code execution to root on those servers, and from root on those servers to a systemic compromise of your entire network (if they want to do that).) Use your imagination on what a mass compromise of accounts gets you. The simplest possible example is grepping for /bitcoin/, finding the full source code and credentials for a Bitcoin exchange, and rooting them then emptying the hot wallet. That results in fairly obvious economic advantage, right? You could also use scriptable attacks to root thousands of big-n-beefy production machines on fairly trusted IP addresses, then add them to a botnet, which you'd use for spamming or various other nefarious activities. Then, even farther down the list, you have a dedicated adversary actually go through every repository they got access to and look for something uniquely fun to do with that particular target. If you were looking to do industrial espionage on a particular target, you'd probably pick a way that was less likely to be detected and cause a company-level security response. (Use passive recon to identify one or a few likely target email addresses, find one or a few likely passwords for them, and try them first. Heads you win, tails you just left evidence in a log of perfectly normal user behavior. You might follow up this perfectly normal user behavior with a social engineering attack.)

Wingman4l7 13y ago
Don't forget API keys in commits from users foolish enough to trust the security of private repos. Yeah, spear phishing / social engineering makes more sense for industrial espionage.
tedunangst 13y ago
Is there a setting I can change to turn off this "session -> code execution" feature?
- patio11 13y ago
  You could, hypothetically, move from CookieStore to a different session store, but I am not positive that this will mitigate the vulnerability (by making it more difficult for the attacker to get write access to the session, not by making it more difficult to turn a session into code execution), and do not have a few hours to reacquaint myself with the code to give you a firmer answer there. I am weakly confident, on the basis of some spelunking in the Rails internals in February, that if you get attacker chosen data into the session you're uniformly hosed on (at least) Rails 2 and Rails 3.
  - rmc 13y ago
    if you get attacker chosen data into the session you're uniformly hosed on (at least) Rails 2 and Rails 3. I wonder if you could expand on this? I'm not too knowledgeable about Rails or security, so I'd wonder how that works?
    - patio11 13y ago
      Long story short: If a cookie is valid (HMAC signature matches what you'd expect given the cookie contents and your secret key), Rails (Rails 2) or Rack middleware (Rails 3) will attempt to use Marshal.load(txt) on the cookie contents to populate your session hash. You might naively assume that this creates a map of strings into other strings, but surprise, Marshal.load(txt) can create arbitrary object payloads and, through a code path which the margins of this comment are just slightly too thin to contain, allow you to do remote code execution. See: http://www.exploit-db.com/exploits/27527/ http://www.exploit-db.com/exploits/27527/ This can be done in an entirely automated fashion and requires no knowledge of the application other than the session's secret key.
  - alinajaf 13y ago
    And Rails 4. The difference with Rails 4 is that the session is encrypted as well as HMAC'd, but it's still the case that as along as you have the token (or can otherwise craft a session) you're hosed.
Bluestrike2 13y ago
On the Rails note, you should be setting an ENV variable rather than hardcoding it as is the default. Same goes for any other keys/tokens/credentials that you're interacting with in your code. With these sorts of things, it's best to rely on pessimistic assumptions and take proactive steps accordingly.

by patio11 13y ago

Wingman4l7 13y ago

Don't forget API keys in commits from users foolish enough to trust the security of private repos. Yeah, spear phishing / social engineering makes more sense for industrial espionage.

tedunangst 13y ago

Is there a setting I can change to turn off this "session -> code execution" feature?

patio11 13y ago
You could, hypothetically, move from CookieStore to a different session store, but I am not positive that this will mitigate the vulnerability (by making it more difficult for the attacker to get write access to the session, not by making it more difficult to turn a session into code execution), and do not have a few hours to reacquaint myself with the code to give you a firmer answer there. I am weakly confident, on the basis of some spelunking in the Rails internals in February, that if you get attacker chosen data into the session you're uniformly hosed on (at least) Rails 2 and Rails 3.
- rmc 13y ago
  if you get attacker chosen data into the session you're uniformly hosed on (at least) Rails 2 and Rails 3. I wonder if you could expand on this? I'm not too knowledgeable about Rails or security, so I'd wonder how that works?
  - patio11 13y ago
    Long story short: If a cookie is valid (HMAC signature matches what you'd expect given the cookie contents and your secret key), Rails (Rails 2) or Rack middleware (Rails 3) will attempt to use Marshal.load(txt) on the cookie contents to populate your session hash. You might naively assume that this creates a map of strings into other strings, but surprise, Marshal.load(txt) can create arbitrary object payloads and, through a code path which the margins of this comment are just slightly too thin to contain, allow you to do remote code execution. See: http://www.exploit-db.com/exploits/27527/ http://www.exploit-db.com/exploits/27527/ This can be done in an entirely automated fashion and requires no knowledge of the application other than the session's secret key.
- alinajaf 13y ago
  And Rails 4. The difference with Rails 4 is that the session is encrypted as well as HMAC'd, but it's still the case that as along as you have the token (or can otherwise craft a session) you're hosed.

Bluestrike2 13y ago

On the Rails note, you should be setting an ENV variable rather than hardcoding it as is the default. Same goes for any other keys/tokens/credentials that you're interacting with in your code. With these sorts of things, it's best to rely on pessimistic assumptions and take proactive steps accordingly.