Peter, don't sweat it. Its clear from the excerpts below that the authors didn't read everything i wrote or they just don't know what they are talking about (could have just concentrated on googling counter responses). First i thought it was me but even after you clearly stating it that the victim IS NOT THE BANK; its still not clear enough for some people!!!! (Sigh, sigh, cough, cough). Alternatively, you could use gimp to do a nice picture of the attack to save yourself 1000 words (i think the message will be clearer then).
But let me give it one more try. THE VICTIM IS A CORPORATE COMPANY NOT THE BANK. ++++++++++++++++ I remember point that out clearly +++++++++++++++++ My target is the local DNS server on the company LAN. I wouldn't sweat it trying to knock out the bank unless when push comes to shove and even so, it would be my very last option (am a lazy dude, with no jail wish and love succeeding while sipping a soda). +++++++++++++ End +++++++++++++++++++++++++++++++ Just a little secret though, I have run a similar attack before (ofcourse with the blessing of the client) to demonstrate something. And the only difference was that i wasn't using the exploit that this thread stemmed from. And yes -- i was only hypothesizing on a few things but mostly (esp. the tech stuff); stating facts! ==================== Excerpts begin Here ============================== > But even then, are u sure, there is a Bank that will allow the use of > unsecured DNS? You know something, you could be playing about with their > honey pots..... Can you let an unknown host join the network, run in > promiscuous mode, have access to other segments and services of the > corporate network, etc? Some corporates even go the extent of saying for > example (just an example): traffic from IBM should not pass through > certain Microsoft routers even if they are the best path available, let > alone that from Iraq passing via Pentagon routers... > Goodness. If every bank in this part of the world has equally dismal > security policies, I will seriously reconsider opening an account here. > Why is it like this? It is perfectly possible to achieve good security with > free software and free information. Why do some security admins insist on > sucking at what they are doing? > Note that Phillip's attack and Davis's defence both are more-or-less > conjecture at this point, Peter's anecdote notwithstanding. It is perfectly > possible that Phillip's attack would be doomed from the get-go; it is also > perfectly possible that the security of the target (let's call it > Hypothetical Bank or HB, so no external eyes are mistakenly led to believe > we're actually planning something, eh) is lacking due to human oversight. > There's really no way to tell for sure, short of a security audit or an > actual intrusion attempt. =================== END OF EXCERPTS ================================= -- - Phillip. “Aoccdrnig to rscheearch at an Elingsh uinervtisy, it deosn't mttaer in waht oredr the ltteers in a wrod are, the olny iprmoetnt tihng is taht the frist and lsat ltteer are in the rghit pclae. The rset can be a toatl mses and you can sitll raed it wouthit a porbelm. Tihs is bcuseae we do not raed ervey lteter by it slef but the wrod as a wlohe and the biran fguiers it out aynawy."
_______________________________________________ The Uganda Linux User Group: http://linux.or.ug Send messages to this mailing list by addressing e-mails to: [email protected] Mailing list archives: http://www.mail-archive.com/[email protected]/ Mailing list settings: http://kym.net/mailman/listinfo/lug To unsubscribe: http://kym.net/mailman/options/lug The Uganda LUG mailing list is generously hosted by INFOCOM: http://www.infocom.co.ug/ The above comments and data are owned by whoever posted them (including attachments if any). The mailing list host is not responsible for them in any way.
