Hi Benjamin, IT Security is a strange thing - not technical, not academic, not social:
A company buys a state-of-the-art firewall and the network admin deploys it with the default login credentials, or with a permit any any..... A bank leases a Wimax link for its ATM and the ISP does not prevent direct communication between different customers on the same base station.... I read somewhere that in Israel, the state security agency (Shin Bet?) supervises IT security for banks because the financial system is considered a part of the critical national infrastructure, and it works because majority of citizens are security oriented courtesy of a mandatory stint in the army. Many of my colleagues on this list would scream murder if they heard of this happening in UG or elsewhere... My thinking is that security is an ongoing effort that everybody, including we the consumers of services, should give sufficient attention to. Most of the time, it boils down to attitude. Kind regards, Bernard On 17 July 2012 14:26, Benjamin Tayehanpour <[email protected]> wrote: > Believe it or not, I actually got that bit. But the banking interface is > part of the bank, as far as I'm concerned. What Phillip described is in > effect a MITM attack, and that type of attack would not be possible if the > Java web start strap were served over HTTPS using a good CA. So far, the > bank is still at fault, since it provides no way of actually verifying that > the files downloaded are the ones intended. So, yes, I suppose the intrusion > is being done through a fault in the security of the corporation, but then > through another flaw in the banking interface. Both flaws make this attack > possible. > > Also, surely, surely the ATMs do not run their communication through the > Internet at all, but rather through dedicated cables? Or at the very least > with some kind of precautions to prevent MITM attacks? Luckily, I have it > set-up so that I need to approve manually (by independent means) every > transaction on my card before my issuer grants the withdrawal, so a leak > would not do very much at all, but you're still giving me the chills! > > > On 17 July 2012 13:40, Peter C. Ndikuwera <[email protected]> wrote: >> >> Ok, seems to be some confusion. >> >> Phillip's attack is against a corporation running an insecure banking >> interface. This way, the banking and account transactional information of >> the corporation is vulnerable to his attack. This doesn't mean that the bank >> is being hacked. No. It's the corporate entity. >> >> My security examples are for the corporation, not the bank. Haven't dealt >> with any banks so can't speak for their security. >> >> So Benjamin, apart from the Windows-based ATM interfaces that are >> vulnerable to some basic man-in-the-middle attacks, banks are pretty safe! >> >> Seriously, though, from informal discussions with my few banking friends, >> I believe most banking fraud in Uganda is insider dealing, not external >> hacking. >> >> >> 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 17 July 2012 13:18, Benjamin Tayehanpour <[email protected]> >> wrote: >>> >>> 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. >>> >>> Have you ever played wargames? Basically, at a LAN party or similar, a >>> person or a team sets up a computer on the network and secures it. The level >>> of security depends on the level of the wargame, of course. Then other >>> people are supposed to try to hack that computer through the network and >>> demonstrate this, often by doing some kind of defacement (once the objective >>> was to deface the projector showing game stats, once we had indicator lights >>> and sound, &c.) showing off your prowess. Have you done any similar games >>> here in Uganda? It's great fun, and good security training for both the >>> attacking and the defending team. >>> >>> >>> On 16 July 2012 20:40, Peter C. Ndikuwera <[email protected]> wrote: >>>> >>>> Davis, >>>> >>>> Your input was a defense strategy wasn't it? And it assumed certain >>>> security measures being in place that I know don't exist in several >>>> corporations I could name. Also, in those corporations, sysadmin and >>>> security admin are more or less synonymous! :-) Even when they're not, or >>>> when PWC does an "IT Audit", they're mostly concerned with external >>>> security/firewall/TLS/SSL/IDS, not internal. >>>> >>>> >>>> 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 16 July 2012 14:54, <[email protected]> wrote: >>>>> >>>>> Hi Peter, >>>>> >>>>> my input is not an attack strategy at all. My input assumes Simbwa has >>>>> successfully gotten to those lines of defense and is then faced with >>>>> resolving the questions at hand. >>>>> >>>>> Also, this is not the jurisdiction of the corporate sys admin we are >>>>> discussing, rather that of the security admins and managers. >>>>> >>>>> >>>>> >>>>> > Davis' plan is actually flawed from the outset. >>>>> > >>>>> > Phillip's attack is NOT at the bank (stanbic in his example) >>>>> > >>>>> > The attack is at a corporate client of Stanbic's who uses stanbic's >>>>> > online >>>>> > banking interface. >>>>> > >>>>> > And his attack isn't completely hypothetical. Both him and I have >>>>> > worked >>>>> > at >>>>> > one such corporate client and helped to install the said stanbic >>>>> > software. >>>>> > And the IT security at this company was non-existent on the internal >>>>> > network. >>>>> > >>>>> > This paragraph actually made me chuckle. Is this Uganda we're talking >>>>> > about? I've done aircrack cracks on a number of corporate wireless >>>>> > networks >>>>> > and there's a lot of WEP and WPA1 out there. And I know many >>>>> > corporate >>>>> > system administrators who wouldn't be able to expand a single one of >>>>> > the >>>>> > abbreviations in this paragraph. Yes, even SSL. >>>>> > >>>>> > "Goodness, in the corporate world, security does not mean passwords, >>>>> > actually PAP is the least secure, leverage schemes like CHAP, >>>>> > DIAMETER, >>>>> > RADIUS, TACACS/TACACS+ yet even at the port level you have EAP, >>>>> > security >>>>> > goes even to the physical level to leverage Quantum cryptography; >>>>> > PKI, >>>>> > RSN, TLS/SSL, DNSsec, IPsec, PGP, etc are all there for you to use. >>>>> > You >>>>> > have so many strategies for protection, forget the days of GSM and >>>>> > WEP or >>>>> > even DES for that matter. At the human interface you have a range of >>>>> > multi-factor authentication schemes, Biometrics is also cheap >>>>> > nowadays >>>>> > (assume FAR is a myth, yet even if not, you could leverage the multi >>>>> > factor scheme)" >>>>> > >>>>> > >>>>> > P. >>>>> > >>>>> > -- >>>>> > Evolution (n): A hypothetical process whereby infinitely improbable >>>>> > events >>>>> > occur with alarming frequency, order arises from chaos, and no one is >>>>> > given >>>>> > credit. >>>>> > _______________________________________________ >>>>> > 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. >> >> >> >> _______________________________________________ >> 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. -- Bernard Wanyama Technical Manager SYNTECH ASSOCIATES Ltd Kampala, Uganda Cell: +256 712 193979 Fixed: +256 414 251591 Web: www.syntechug.com Email: [email protected] _______________________________________________ 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.
