Oouch, i guess you prefer the "theoretical/hypothetical" stuff! Sorry dude, am a practical guy. If you could set up something, then i would show you a few things...
But no worries chief. May be next time. We could may be close this thread before it spirals too far from where it was meant to go. Cheers, On 7/20/12, [email protected] <[email protected]> wrote: > What? :) Hey Phillip, on whose live systems do you want to try out that > crap? Forget that! I know the weaknesses in each of those lines of defense > and am bound not to expose them. Sorry, am out of that business. > > >> Hmmm, thats interesting. >> >> Do you run a network with any of the stuff you mentioned or do you >> access to corporate client with all or a good part of the stuff you >> mentioned? >> >> Reason I ask, is; for knowledge's sake (like you mentioned), i could >> show up and we tease & poke that network and we see how both you and >> me can stretch those controls to their limits. >> And if your client is ok with us discussing our findings on a mailing >> list like this one, everyone benefits. >> >> My charge: 2 litres of coke, Chips & chicken. (That's close to pro >> bono, for an intensive pen testing exercise). What do you think? >> >> I just need your calendar to compare with mine and we find some free >> time to see warrup! >> >> Cheers, >> >> >> On 7/18/12, [email protected] >> <[email protected]> wrote: >>> :) Hey Phillip, your attack (whether on the Bank or a corporate; wonder >>> if >>> attacking the corporate and not the Bank makes it any better evil) >>> without >>> those or other certain lines of defense being in place, will definitely >>> succeed especially when coupled with social engineering techniques: (its >>> clear that in the battle between cryptanalysts and cryptographers, the >>> former always win: recall the knapsack algorithm, rc4/WEP, gsm security >>> and the rest). There are so many techniques you can leverage for attack: >>> from power/timing analysis to covert channels, to collusion, even the >>> biometrics at nuc substations is subject to false accept rates (FAR), >>> etc, >>> etc. BTW in some countries, certain products are even installed at all >>> ISPs so they can filter email looking for keywords that can serve as a >>> basis for investigation. >>> >>> :)My interest in posing those lines of defense to you, was actually to >>> try >>> and explore possible weaknesses in them for the interested parties so we >>> can go to the next lines of defense, had you replied directly to each >>> question and not let others speak for you. Your mentioned bank may not >>> be >>> the only one with security problems, coz we have even read about bigger >>> ones that have been hiding their debts, fixing inter-banking/overnight >>> rates, and you never know the worst may come in when its realized that >>> one >>> of the leading global economies have (their reserve bank) been hiding >>> and >>> telling lies about their debt (and u know what, boom, another global >>> credit crunch) >>> >>> Thanks. >>> >>>> 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. >>>> >>>> 鄭occdrnig 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." >>>> >>> >>> >>> >> >> >> -- >> - 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." >> > > > -- - 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.
