:)Hi, this is a mailing list, perhaps the guy is not in UG :):) As for the challenge, the ISPs are public networks, ain't they? I suppose none of them runs unsecured DNS, but for those that do, then a dns spoofing challenge would be good for their customers.
Also, some of them offer wireless connectivity; there could be some that offer it over unencrypted and insecure channels, an MITM challenge for them would also be good for their customers. :)As for a practical network; yes Benjamin suggested we build an open source wireless network, (really nice idea if we can get our hands together and make it work). The last update about it was from Vass presenting a nice guideline book for the community to follow through each design phase, and my take was that he takes the lead since he probably was more familiar with his guideline book. I think this network would be free to stress to the limits. > 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. _______________________________________________ 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.
