5 ms·

I’m a bit newbie in this exact field but when Keycloak is used to autenticate an external client, wouldn’t revealing that you’re using Keycloak itself be a secu

I’m a bit newbie in this exact field but when Keycloak is used to autenticate an external client, wouldn’t revealing that you’re using Keycloak itself be a security concern? Giving that information to a possible attacker could be dangerous, is it possible to make it totally impossible to understand if someone is using Keycloak or not?

Lacerda69 3y ago
I dont quite get why you think it would be a security concern? The alterntive to using a tried and tested solution is to build it yourself - but are you really confident you will do a better job than professionals in the field?
- paulmd 3y ago
  Server information leakage is generally viewed as a security vulnerability, eg by scanning tools utilizing the OWASP guidelines, because it assists in server fingerprinting. https://www.ibm.com/docs/en/control-desk/7.6.1.x?topic=checklist-vulnerability-server-leaks-information https://www.ibm.com/docs/en/control-desk/7.6.1.x?topic=check... https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/02-Fingerprint_Web_Server https://owasp.org/www-project-web-security-testing-guide/lat... The general problem is that if you just go and blab about what software you're running, if you ever have a version with a known vulnerability (or a zero-day) then the attacker immediately knows what payload to run against you, in fact you can potentially be programmatically attacked from Shodan/etc. Obviously it's better to simply never run any insecure software, but forcing them to run a search for payloads against you will hopefully create an opportunity for them to trip alarms and generally increase the attack time. I am not super duper concerned about leaking what the gateway app is in general, as a sibling mentions it's pretty unavoidable that an attacker is going to fingerprint a server if they really want to, I generally agree (without knowing which is which) that there are clearly a couple of them that have distinctive UI looks lol. On the other hand, leaking version info is probably a bridge too far in my opinion - if you do ever end up with a vulnerable JVM/library/appserver/gateway, now it can be programmatically identified by an attacker. Things like log4shell or the Jakarta Struts vuln have a long long tail of shit that's gonna be vulnerable forever. It's not the end of the world, but honestly I really, really dislike the way "security by obscurity!" tends to be used (more often than not) as a thought-terminating cliche. The line is supposed to be that "obscurity as the only method is not security" and that's true, but, obscurity is generally an important part of defense-in-depth. There's no reason to hand an adversary more information about the system than necessary, them blundering around your obscurity and triggering security alerts for patched attack payloads/etc or weird errors that don't normally crop up increases the chance of detection. People treat it as "anything that increases obscurity is a bad thing" and no, actually that's generally a good thing (as OWASP acknowledges). Just not if your system is designed such that it doesn't work if obscurity fails. Building a secure system and then adding obscurity is a net increase over a secure system without the obscurity. Should your application be secure if you hand them a classfile list? Sure. Is it a good idea to actually hand them one? No. Same for network maps/IP ranges/etc. Is it something they could figure out eventually? Sure, but make them work for it, and hope they try to connect somewhere that isn't allowed for that container/VLAN and alarms go off. Security and obscurity are two great tastes that go great together, because obscurity increase the chances that an attacker trip alarms in a way that catches attention.
  - 8organicbits 3y ago
    Wait, what server information leakage are we talking about? I didn't think keycloak leaked `x-powered-by`, and there's discussion[1] in their repo that shows they understand the concern. All software can be fingerprinted (if not then it has no user visible behavioral differences). Making it trivial to fingerprint a server isn't a good idea, but avoiding it entirely doesn't make sense. Was there a specific trivial information leakage you were worried about? [1] https://github.com/keycloak/keycloak/pull/5293 https://github.com/keycloak/keycloak/pull/5293
- yardstick 3y ago
  > but are you really confident you will do a better job than professionals in the field? Sometimes it’s better to do just the thing you want, and nothing more. Othertimes it’s better to rely on tried and tested solutions. I’m still scratching my head over the crazy unnecessary feature in log4j2 that lead to their massive security vulnerability recently. A feature that I had never heard of nor would have ever used. The trade off isn’t always obvious between reduced attack surface of bespoke solutions vs the many eyes on popular public solutions.
precommunicator 3y ago
Once you're a Keycloak user you can figure out if someone is using Keycloak within seconds, e.g. I know my credit card company uses it. And this isn't a matter of security, security by obscurity is really bad idea.
- ElongatedMusket 3y ago
  Are you referring to the formatting/contents of the session token, or some other way to tell within seconds?
  - rad_gruchalski 3y ago
    The cookie name and login/registration URL (realm) gives it away immediately.
havnagiggle 3y ago
Like every other server revealing they use Apache or Nginx? Yeah, zero days in software are an issue so it's important to be vigilant for any public deployment, but it's also not something to count against unless the software is not being maintained or too slow to fix issues.
- jeroenhd 3y ago
  I've talked to devs who added PHP headers and fake server name headers to their servers. A fake /wp-login/ also seems to greatly confuse the automated scanners, especially if you slowloris them. This won't stop any kind of targeted attack, but it may confuse the low-effort automated scripts enough to send the wrong types of payloads. It can also make for an easy source of blacklisted botnet IPs. This stuff takes maybe five minutes to set up and it weeds out a lot of the automated crap.
  - ilyt 3y ago
    > A fake /wp-login/ also seems to greatly confuse the automated scanners, especially if you slowloris them. You're just wasting a bit of your own resources for no gain here. If you want to "do something about it", throw that IP onto temporary blacklist (temporary because those IPs will inevitably rotate and might be actual dynamic ISP IPs that can be given to different user next time) > This won't stop any kind of targeted attack, but it may confuse the low-effort automated scripts enough to send the wrong types of payloads. How does that help ?
    - 8organicbits 3y ago
      Imagine an automated scanner and attack tool. First it fingerprints your server, then it attacks with only payloads it thinks may work. If you trick it into thinking you run WordPress, for example, then it will attack you with WordPress payloads that won't affect you, even if it happens to know one that does. Attackers have limited resources, so slowing them down with slowloris, or tricking them to use the wrong attacks provides protection. Dedicated attackers may notice the WordPress trick or may just run every payload against you, but automated scanners that are trying to be efficient will not. Hopefully a WAF can detect that much more noisy attack and deny-list their IP address(es), and other more traditional defences kick in.

Lacerda69 3y ago

I dont quite get why you think it would be a security concern? The alterntive to using a tried and tested solution is to build it yourself - but are you really confident you will do a better job than professionals in the field?

paulmd 3y ago
Server information leakage is generally viewed as a security vulnerability, eg by scanning tools utilizing the OWASP guidelines, because it assists in server fingerprinting. https://www.ibm.com/docs/en/control-desk/7.6.1.x?topic=checklist-vulnerability-server-leaks-information https://www.ibm.com/docs/en/control-desk/7.6.1.x?topic=check... https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/02-Fingerprint_Web_Server https://owasp.org/www-project-web-security-testing-guide/lat... The general problem is that if you just go and blab about what software you're running, if you ever have a version with a known vulnerability (or a zero-day) then the attacker immediately knows what payload to run against you, in fact you can potentially be programmatically attacked from Shodan/etc. Obviously it's better to simply never run any insecure software, but forcing them to run a search for payloads against you will hopefully create an opportunity for them to trip alarms and generally increase the attack time. I am not super duper concerned about leaking what the gateway app is in general, as a sibling mentions it's pretty unavoidable that an attacker is going to fingerprint a server if they really want to, I generally agree (without knowing which is which) that there are clearly a couple of them that have distinctive UI looks lol. On the other hand, leaking version info is probably a bridge too far in my opinion - if you do ever end up with a vulnerable JVM/library/appserver/gateway, now it can be programmatically identified by an attacker. Things like log4shell or the Jakarta Struts vuln have a long long tail of shit that's gonna be vulnerable forever. It's not the end of the world, but honestly I really, really dislike the way "security by obscurity!" tends to be used (more often than not) as a thought-terminating cliche. The line is supposed to be that "obscurity as the only method is not security" and that's true, but, obscurity is generally an important part of defense-in-depth. There's no reason to hand an adversary more information about the system than necessary, them blundering around your obscurity and triggering security alerts for patched attack payloads/etc or weird errors that don't normally crop up increases the chance of detection. People treat it as "anything that increases obscurity is a bad thing" and no, actually that's generally a good thing (as OWASP acknowledges). Just not if your system is designed such that it doesn't work if obscurity fails. Building a secure system and then adding obscurity is a net increase over a secure system without the obscurity. Should your application be secure if you hand them a classfile list? Sure. Is it a good idea to actually hand them one? No. Same for network maps/IP ranges/etc. Is it something they could figure out eventually? Sure, but make them work for it, and hope they try to connect somewhere that isn't allowed for that container/VLAN and alarms go off. Security and obscurity are two great tastes that go great together, because obscurity increase the chances that an attacker trip alarms in a way that catches attention.
- 8organicbits 3y ago
  Wait, what server information leakage are we talking about? I didn't think keycloak leaked `x-powered-by`, and there's discussion[1] in their repo that shows they understand the concern. All software can be fingerprinted (if not then it has no user visible behavioral differences). Making it trivial to fingerprint a server isn't a good idea, but avoiding it entirely doesn't make sense. Was there a specific trivial information leakage you were worried about? [1] https://github.com/keycloak/keycloak/pull/5293 https://github.com/keycloak/keycloak/pull/5293
yardstick 3y ago
> but are you really confident you will do a better job than professionals in the field? Sometimes it’s better to do just the thing you want, and nothing more. Othertimes it’s better to rely on tried and tested solutions. I’m still scratching my head over the crazy unnecessary feature in log4j2 that lead to their massive security vulnerability recently. A feature that I had never heard of nor would have ever used. The trade off isn’t always obvious between reduced attack surface of bespoke solutions vs the many eyes on popular public solutions.

precommunicator 3y ago

Once you're a Keycloak user you can figure out if someone is using Keycloak within seconds, e.g. I know my credit card company uses it. And this isn't a matter of security, security by obscurity is really bad idea.

ElongatedMusket 3y ago
Are you referring to the formatting/contents of the session token, or some other way to tell within seconds?
- rad_gruchalski 3y ago
  The cookie name and login/registration URL (realm) gives it away immediately.

havnagiggle 3y ago

Like every other server revealing they use Apache or Nginx? Yeah, zero days in software are an issue so it's important to be vigilant for any public deployment, but it's also not something to count against unless the software is not being maintained or too slow to fix issues.

jeroenhd 3y ago
I've talked to devs who added PHP headers and fake server name headers to their servers. A fake /wp-login/ also seems to greatly confuse the automated scanners, especially if you slowloris them. This won't stop any kind of targeted attack, but it may confuse the low-effort automated scripts enough to send the wrong types of payloads. It can also make for an easy source of blacklisted botnet IPs. This stuff takes maybe five minutes to set up and it weeds out a lot of the automated crap.
- ilyt 3y ago
  > A fake /wp-login/ also seems to greatly confuse the automated scanners, especially if you slowloris them. You're just wasting a bit of your own resources for no gain here. If you want to "do something about it", throw that IP onto temporary blacklist (temporary because those IPs will inevitably rotate and might be actual dynamic ISP IPs that can be given to different user next time) > This won't stop any kind of targeted attack, but it may confuse the low-effort automated scripts enough to send the wrong types of payloads. How does that help ?
  - 8organicbits 3y ago
    Imagine an automated scanner and attack tool. First it fingerprints your server, then it attacks with only payloads it thinks may work. If you trick it into thinking you run WordPress, for example, then it will attack you with WordPress payloads that won't affect you, even if it happens to know one that does. Attackers have limited resources, so slowing them down with slowloris, or tricking them to use the wrong attacks provides protection. Dedicated attackers may notice the WordPress trick or may just run every payload against you, but automated scanners that are trying to be efficient will not. Hopefully a WAF can detect that much more noisy attack and deny-list their IP address(es), and other more traditional defences kick in.