Davis, you could set up a test network and get Phillip to stress test it for you.
I don't believe he's asking maliciously. Maybe it could be an exercise for a LUG meeting if Davis can't take up the challenge? P. -- Evolution (n): A hypothetical process whereby infinitely improbable events occur with alarming frequency, order arises from chaos, and no one is given credit. On 20 July 2012 13:12, Mike Epps <[email protected]> wrote: > what Mr Phillip Simbwa said..always nice to see people that know > stuff like that.. > > On 7/20/12, Phillip Simbwa <[email protected]> wrote: > > 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. > _______________________________________________ > 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. >
_______________________________________________ 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.
