Pete Finnigan's Oracle Security Forum


    
      
        Pete Finnigan's Oracle Security Forum
        (http://www.petefinnigan.com/forum/yabb/YaBB.cgi)
      

        Oracle Security >> Oracle Security >> Who wrote the P-O-C Worm?
        
(Message started by: Pete Finnigan on Nov 25^th, 2005, 11:18am)

Title: Who wrote the P-O-C Worm?
Post by Pete Finnigan on Nov 25^th, 2005, 11:18am

Hi,

Do we know how wrote the proof-of-concept worm?
The chance the author posted code in the past is high (IMHO). And chances are high those code/questions are stored in Google. And beacuse I'm very curious about who is the author of the worm (just curiosity) I'm looking at the code to see if I find any clue about the author. I started looking for spellingerrors in the comment, eg. adress instead of address, to see if I can find similar errors in Google. People tend to make the same spellingerrors. I did not find any errors (more comments next time please:-) . Next I looked at the variables to see if I can discover the author's language. People tend to use their own language to name variables. No luck. Then I looked at the variables. People tend to use the same variablenames in their programs. I looked in Google if I could find hits with the same variablenames. Variablenames like ret_val, i1, i2, i4, etc. No luck. It seems that the author took care not to reveal his/her identity. He/she used unique variablenames.
The most promising search is: ret_val "exit when"
I'll keep searching:-)

Ivan

Title: Re: Who wrote the P-O-C Worm?
Post by Pete Finnigan on Nov 28^th, 2005, 2:53am

The most surprising bit for me was the use of the older style DBMS_SQL rather than EXECUTE IMMEDIATE (avaiable in 8i onwards).
EXECUTE IMMEDIATE is a lot simpler. DBMS_SQL has two advantages though. Firstly, and the main one for general applications, is that the same cursor can be re-opened which saves on a parse. Secondly, DBMS_SQL can be invoked over a DB link (ie a session on database A can use DBMS_SQL on database B, given a database link with the right grants) to run anonymous PL/SQL on the remote database.
It makes me wonder if the reason EXECUTE IMMEIDATE wasn't used is that this was based on another Oracle hack which required that functionality (eg to act as some DoS CPU hog).