websecurity@lists.webappsec.org

The Web Security Mailing List

View all threads

JBOSS JMX-Console HTTP Basic Authentication

RG
RDX Guy
Thu, Feb 13, 2014 7:41 PM

If a JBOSS server is using HTTP Basic Authentication to access its
jmx-console, how safe it is?

If the above JBOSS is configured in a way, that it supports only HTTPS, how
safe HTTP Basic Authentication is?

If the above jboss is configured in a way that it uses HTTPS to access
jmx-console on one port e.g. 21017 BUT then there is another port 21018 on
which jmx-console is available on HTTP and using the same user-credentials
for HTTP Basic Authentication? How safe that is?

If a JBOSS server is using HTTP Basic Authentication to access its jmx-console, how safe it is? If the above JBOSS is configured in a way, that it supports only HTTPS, how safe HTTP Basic Authentication is? If the above jboss is configured in a way that it uses HTTPS to access jmx-console on one port e.g. 21017 BUT then there is another port 21018 on which jmx-console is available on HTTP and using the same user-credentials for HTTP Basic Authentication? How safe that is?
AV
Andrew van der Stock
Fri, Feb 14, 2014 1:37 AM

Depends on a few factors:

a) Do they have CPU or audit logging to detect and escalate a response to
an in progress brute force attack? Usually, no
b) Depends if they have removed or disabled all default accounts for
jmx-console. Usually, no
c) Depends on the complexity of the passwords chosen. We can brute force
about 1000-2000 tests per second on a locally situated JBoss server that is
doing nothing else using Hydra or similar. If you have chosen a 16
character random password or a long passphrase, brute forcing will never
find the password in a reasonable time
d) Can an attacker intercept the communications between a valid
administrator of jmx-console or other sensitive traffic? If so, password
complexity does not matter, the issue relates to encrypted or interceptable
traffic. If jmx-console is not available outside of the management network,
I believe the risk to be relatively low. Just consider all those SuperMicro
IPMI vulnerabilities - folks can and are pwned by this issue, but for the
most part, if the management ports are properly protected as AS 4444 / BS
7799 / 17799 / 27002 has required since I don't know, 20 years now, then
... is this an issue that needs further tightening.

Honestly, considering that it took me longer to type this up than it would
take a system administrator to close these issues down, I would say "just
fix it". Attack surface reduction is always a great idea, just in case we
found out more later.

And it would be great if Red Hat would no enable JMX Console etc by default
for new installs. Those who need it, know it. They can turn it on after
thinking about how best to secure it for their specific business
requirements.

thanks
Andrew

On Fri, Feb 14, 2014 at 6:41 AM, RDX Guy rdx.guy@gmail.com wrote:

If a JBOSS server is using HTTP Basic Authentication to access its
jmx-console, how safe it is?

If the above JBOSS is configured in a way, that it supports only HTTPS,
how safe HTTP Basic Authentication is?

If the above jboss is configured in a way that it uses HTTPS to access
jmx-console on one port e.g. 21017 BUT then there is another port 21018 on
which jmx-console is available on HTTP and using the same user-credentials
for HTTP Basic Authentication? How safe that is?


The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

Depends on a few factors: a) Do they have CPU or audit logging to detect and escalate a response to an in progress brute force attack? Usually, no b) Depends if they have removed or disabled all default accounts for jmx-console. Usually, no c) Depends on the complexity of the passwords chosen. We can brute force about 1000-2000 tests per second on a locally situated JBoss server that is doing nothing else using Hydra or similar. If you have chosen a 16 character random password or a long passphrase, brute forcing will never find the password in a reasonable time d) Can an attacker intercept the communications between a valid administrator of jmx-console or other sensitive traffic? If so, password complexity does not matter, the issue relates to encrypted or interceptable traffic. If jmx-console is not available outside of the management network, I believe the risk to be relatively low. Just consider all those SuperMicro IPMI vulnerabilities - folks can and are pwned by this issue, but for the most part, if the management ports are properly protected as AS 4444 / BS 7799 / 17799 / 27002 has required since I don't know, 20 years now, then ... is this an issue that needs further tightening. Honestly, considering that it took me longer to type this up than it would take a system administrator to close these issues down, I would say "just fix it". Attack surface reduction is always a great idea, just in case we found out more later. And it would be great if Red Hat would no enable JMX Console etc by default for new installs. Those who need it, know it. They can turn it on after thinking about how best to secure it for their specific business requirements. thanks Andrew On Fri, Feb 14, 2014 at 6:41 AM, RDX Guy <rdx.guy@gmail.com> wrote: > > If a JBOSS server is using HTTP Basic Authentication to access its > jmx-console, how safe it is? > > If the above JBOSS is configured in a way, that it supports only HTTPS, > how safe HTTP Basic Authentication is? > > If the above jboss is configured in a way that it uses HTTPS to access > jmx-console on one port e.g. 21017 BUT then there is another port 21018 on > which jmx-console is available on HTTP and using the same user-credentials > for HTTP Basic Authentication? How safe that is? > > > _______________________________________________ > The Web Security Mailing List > > WebSecurity RSS Feed > http://www.webappsec.org/rss/websecurity.rss > > Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > WASC on Twitter > http://twitter.com/wascupdates > > websecurity@lists.webappsec.org > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org > >