22

http 500 error

Recently I came across a website and when clicking on one of hyperlinks it displayed a HTTP 500 error page as shown in the image, which indicated that it is using Java Server Pages and on line 23 the code read as

Connection con = Drivermanager.getconnection(conStr,"some_username","some_password");
  1. Have they hardcoded the username and password on the JSP page?
  2. Before submitting the bug to the site owner, how can I test the information exposure and "exploit"?
  3. What is the best way to prevent such instances besides following OWASP Top 10?
  4. Is this DB publicly accessible now?
schroeder
  • 123,438
  • 55
  • 284
  • 319
Wasim Wani
  • 322
  • 1
  • 8

6 Answers6

38

They have quite obviously hardcoded the Oracle database credentials.

Unless the database is exposed to the internet, there is nothing in what you have shown that allows you to directly connect to the database. But connecting is not necessary. They have exposed their credentials. That's enough.

Credentials should be stored in another location and called as part of the connection string.

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • 4
    Excellent answer, +1. OP, see https://security.stackexchange.com/questions/13353/is-it-safe-to-store-the-database-password-in-a-php-file for some interesting reading on more secure ways of storing database credentials used for enabling server-side scripts to access a database. – mti2935 Feb 13 '22 at 18:31
  • 3
    To be fair, architectures that intentionally forgo a password (as the password has to be stored on the relevant servers anyway, whether that's in a config file or source file) and primarily rely network restrictions (especially when the db is hosted on the same server) are far from uncommon. – David Mulder Feb 14 '22 at 09:16
  • 2
    Sorry, total security noob. Why is connecting not necessary? How are the credentials enough? How can you get the data (I assume that's somebody's goal) if you don't or can't connect? Not criticizing, I simply don't understand if you're being literal and if that's the case how could someone read the data or do something malicious. – Blueriver Feb 14 '22 at 18:28
  • 7
    @Blueriver Theoretically someone could gain network access via other exploits or maybe is an internal employee of the company who has network access but shouldn't have the user/pass. It's a threat even if OP can't exploit it on their own. But the real point is that the organization set a user/pass, which indicates that they intended to use it as a security layer, and would likely want to be informed if it was rendered useless. – Clay07g Feb 14 '22 at 20:37
  • 5
    @Blueriver The question was "how to exploit so *so that I could submit a bug*". The exposed credentials are enough to submit a bug. – schroeder Feb 14 '22 at 23:39
  • @Blueriver theres also a question around “what else did they reuse that username and password for?” - even if you cant get the data from this particular database, what about the admin account on their router, the dns server, the Google admin page etc etc. Plenty of scope here. – Moo Feb 15 '22 at 08:19
  • Dumping stack traces to error responses in a production application is the more fundamental error here. Hardcoding credentials is super dumb but wouldn't know that if the stack wasn't shown. – JimmyJames Feb 15 '22 at 14:26
15

Have they hardcoded the username and password on the JSP page?

Yes, they did.

Before submitting the bug to the site owner, how can I test the information exposure and "exploit"?

No need to test anything. It's right on the source code of the site, so I doubt any further proof is necessary.

What is the best way to prevent such instances besides following OWASP Top 10?

There are some relevant OWASP entries:

Security Misconfiguration: a production server should not be configured in such a way that errors with debug messages got sent to the clients. This allows an attacker to enumerate products, versions, and possible vulnerabilities. In this specific case, even database access credentials.

Software and Data Integrity Failures: "Software and data integrity failures relate to code and infrastructure that does not protect against integrity violations."

Database access should be handled by a software component (for the lack of better definition) that should handle, among other things, exception handling and log generation. In this case, there's no exception handling at all and the log is sent to the client.

Identification and Authentication Failures: "Uses plain text, encrypted, or weakly hashed passwords data stores."

Cryptographic Failures: "... previously known as Sensitive Data Exposure, which is more of a broad symptom rather than a root cause, the focus is on failures related to cryptography (or lack thereof). Which often lead to exposure of sensitive data. Notable Common Weakness Enumerations (CWEs) included are CWE-259: Use of Hard-coded Password, CWE-327: Broken or Risky Crypto Algorithm, and CWE-331 Insufficient Entropy."

In this case, CWE-259: Use of Hard-coded Password applies. It's more a sensitive data exposure than a cryptographic failure, but it's a failure anyway.

Is this DB publicly accessible now?

It depends. They leaked the username and password, so if someone manages to get network access (remote file inclusion, remote code execution, server-side request forgery, etc) it's possible to connect direct to the database.

This could be development code ending up in production, but this does not lower the severity of the issue. If this is the case, it shows the company does not have proper software lifetime standards in place, or don't even have development/staging/production environments.

ThoriumBR
  • 50,648
  • 13
  • 127
  • 142
2

This is not good practice on a number of levels:

  1. Hardcoding credentials in your code
  2. Exposing error info to the web
  3. Using "magic" strings in code, rather than variables.

All of which should be avoided! Good programming practise alone might have mitigated this somewhat as the password/username would be references to variables, not raw strings. But there's lots of things wrong here.

shearn89
  • 141
  • 5
1
  1. Before submitting the bug to the site owner, how can I test the information exposure and "exploit"?

You don't. If you login to the database and check out the information exposure to 'test' it, you are basically accessing it without authorization which is a crime.

Jason Goemaat
  • 592
  • 3
  • 7
0

I would add to the other answers and point out that the method of connecting to the database being used in this instance is incorrect.

Java EE based systems, access to resources should be provided and managed by the application server (or web container in cases like Tomcat or jetty) i.e. you don't connect to anything directly, you configure the application server to connect then the application looks up the connection in JNDI

Their code would be looking up a Datasource Object which is already connected, hence the application would not deal directly with the credentials at all.

Generally, the Application Server or Web Container will use an alias for the credential in its config and store the credential values in a Keystore alongside any Private Keys for example.

Chris
  • 1
  • 1
-2

Looks like you hit some forgotten debug code that doesn't work, probably exactly because the exposed connection credentials are not valid.

The credentials may be valid for some development database or not relevant to anything anymore.

While still a result of some bad practice (the debug code should not be left in the production setup and the error messages should go into some log infrastructure and not expose the code to the end user), it likely doesn't expose something sensitive.

The exposed part of the program code is fairly generic as well.

fraxinus
  • 3,425
  • 5
  • 20
  • 3
    Why do you think that this is dev data and not live? – schroeder Feb 14 '22 at 11:13
  • 3
    @schroeder Assuming the rest of the site works, this doesn't and the only thing we know it tries to do is connect to a db, it's a good guess. – JollyJoker Feb 14 '22 at 15:36
  • 1
    We have a part of the page. And as you say, it's a *guess* based on an assumption. The Answer is written as if it is a certainty. – schroeder Feb 14 '22 at 17:19
  • @JollyJoker: Might be worth escalating however if the site eventually loads on a refresh - because then it could be that the PreparedStatement failed, not the actual connection attempt - although that does seem unlikely. But yeah - if it works elsewhere, it's likely credentials that are meant for dev and not live database connections. – Alexander The 1st Feb 14 '22 at 17:53
  • That said - I do think this is still an issue, as if the Prepared Statement were to crash next time, it might reveal the correct production credentials, without making refactoring changes mentioned in @schroeder's answer to improve the security of the system. – Alexander The 1st Feb 14 '22 at 17:55
  • 2
    Connecting to the database is a part of the code that should be expected to fail in production - because of database-server failure, networking issues etc. So I see no hint to "debug code" – piet.t Feb 15 '22 at 08:27