[ Note to moderator(s): this may not be interesting enough since it was a single-vendor problem, and that it has now been fixed. However, that vendor makes the leading java application server, and anyone who used the effected site should know their information may have been compromised. And, the vendor response was, um, less than stellar. ] Until recently, there was an SQL injection vulnerability in the developer site at http://developer.bea.com/. Raw SQL commands could be issued by inserting SQL in the password field (and probably username as well) of the login form. The problem is now fixed, but any user of the BEA Developer site may have had any information they gave it (email, phone, and snail mail contact information, password[1], etc) stolen by third parties, such as competitors in that market space, general SPAM harvesters, etc. That which can be (e.g. passwords) probably should be, by any effected user. A scarier possibility is that the database this app pointed to had other confidential BEA internal or customer data on it such as financial/billing information, credentials for any supported customer sites, etc, which would therefore also have been exposed after some database plundering (which I did not attempt). History: -First discovered Nov 29, 2001, when trying to log in to my account created nearly a year before which included a single quote in the password (and which caused a verbose Oracle parse error) -Reported to BEA that day; message included below[2] with names and IPs changed to protect the guilty -Received a prompt reply from a BEA employee who understood the issue, thanked me for bringing it to their attention, and said they would pass it to the appropriate folks -Checked again Jan 9, 2002; problem still not fixed -Replied to the individual who had acked my previous mail, said that the problem was still there -Received a reply next day from someone else at BEA, who understood the issue, thanked me for bringing it to their attention, and said they would pass it to the appropriate folks -Checked again every week or two until Jan 29, 2002; bug was never fixed -On Jan 29, 2002, fwded original mail to original recipients, plus several more addresses of BEA directors/managers whose information was exposed by the bug. In it I informed them of my intention to publish two weeks later (today, Feb 13, 2002), whether the bug was fixed or not -On Jan 29, 2002 (same day) got a reply from a third individual at BEA, who understood the issue, thanked me for bringing it to their attention, and said they were escalating the issue immediately. -Checked again Feb 9, 2002 and... the problem is fixed -In further exchanges, I was told that they believe the error was fixed in November or so when I first reported it, but was subsequently un-done when the relevant JSP was overwritten I do not know which is worse; either a vendor takes over two months to fix a problem brought to their attention repeatedly, and only after publication is threatened, or they fixed it immediately, but poor change control and follow-up caused the bug to resurface almost immediately and be neglected until multiple reminders are sent and only after publication is threatened. As with past dealings I've had with BEA, every individual with whom I delt seemed competent and committed, but organizationally, some things appear to be broken. :-P Hank Leininger <hlein@progressive-comp.com> E407 AEF4 761E D39C D401 D4F4 22F8 EF11 861A A6F1 [1] Of course one shouldn't use a password with a site like this that has any meaning anywhere else. In addition to the usual, all access is in plaintext including login, and the password is stored in the database in plaintext, and is sent back to the browser in the HTML for the "update profile" page. [2] The original mail sent to BEA follows: Date: Thu, 29 Nov 2001 02:02:19 -0500 (EST) From: Hank Leininger <hlein@progressive-comp.com> To: webmasterat_private Cc: securityat_private Subject: SQL Insertion vulnerability in http://developer.bea.com/do_login.jsp I've found a serious security problem with BEA's Developer Center site which exposes confidential information about all registered users of that site. I just attempted to log in to BEA's developer center for the first time in probably a year (to see if security problems with cookie handling and the webserver plugins that I reported in November 2000 had been fixed yet). The account I created and used back then has a single quote in the password. Upon POSTing my username/password to http://developer.bea.com/do_login.jsp I received: [snip boilerplate] Server Error We're sorry, an error occurred in the application. Error is com.islco.bea.partner.DataAccessException: LoginManager.getSingleValue(). Query: select id from t_User where UPPER(userid)=UPPER('fooat_private') and UPPER(password)=UPPER('X'XX XX'). Error: ORA-00907: missing right parenthesis The above is the classic sign of a SQL insertion vulnerability--someone could submit arbitrary SQL in the password field and have the server act on it. I tested a login with a valid username and the password ') or UPPER('a')=UPPER('a and was successfully logged in as 'SOME BEA EMPLOYEE' (who perhaps has the first record in the t_User table?). Logging in with password: ') union select id from t_User where userid<>'SEMPLOYE' and 'A'=UPPER('A I was greeted as 'SOME OTHER BEA EMPLOYEE'. I notice also that in the user profile section, the current password is sent from the server to the client in plaintext. I suspect that at the very least a malicious attacker could (with a patient script generating valid SQL) enumerate every user on the developer site, harvest all their email addresses and passwords, just from this single vulnerability. Other confidential customer data may be exposed elsewhere on BEA webservers, with a little more investigation and data mining. This vulnerability could also almost certainly be used maliciously to destroy data (change or delete information in databases with which this server communicates). Feel free to contact me for more information or suggestions, or if the above has not been clear. [ ObDisclaimer: I do computer security in my day job, but that's not the context in which I am contacting you. ] You will probably wish to do an investigation to attempt to determine if this condition has already been exploited by others. All of my testing has taken place between 1:17:15 AM US/Eastern and 1:47:16 AM US/Eastern today, November 29, 2001, from IP XXX.XXX.XXX.XXX. Thank you, Hank Leininger <hlein@progressive-comp.com> E407 AEF4 761E D39C D401 D4F4 22F8 EF11 861A A6F1
This archive was generated by hypermail 2b30 : Wed Feb 13 2002 - 16:41:47 PST