Re: SQL Hooker Release

["J.M. Seitz" <lists () bughunter ca>]

> How about automating the process of auditing Oracle internals 
> for hunting even more pl/sql injections ? 

This is interesting, and yes it would be possible. It might also be
interesting to examine the size of the variables at the point when the
Oracle internals fire. You may be able to determine if an internal function
inside the database is vulnerable to a stack/heap based overflow. However,
that might be a bit beyond the scope of what we wrote the tool for, of
course always accepting patches :)

> Rather than hooking SQL OLEDB  , it can be fine-tuned for 
> attaching to related oracle process , waiting for the other 
> side (second script*) to trigger an injection in list of 
> targeted packages/stored procedures . output would be a list 
> of packages/SPs in oracle , harmed by second-script* and 
> detected by hooker script. 

Yes, essentially this is what it's designed for, it's just a matter of
Dave/me/someone else, doing a bit of RE work and finding the magic hook
points. Go hard Dave!
 
> Second-script* , would be a parser engine , reading list of 
> stored procedures among their parameters  for example, and 
> sending them to oracle from any query interface, while 
> manipulating some of parameters ...
> example, 

Yeah, really you can use anything to generate the input, that's the beauty
of it. Dave is looking to do some SPIKEProxy integration, but you could be
using ParosProxy or really anything to generate it, just use the hooker to
filter out what is useful for you. Not to mention it's a great way for an
internal development team to exercise any global filtering implementations,
anything that gets sent back to the RPC server made it past the filters.

JS

_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave