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." > _______________________________________________ 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.
