Hi, Very nice writing! My thoughts:
Phillip's attack strategy is quite strong - takes advantage of technical and social weaknesses. with a lot facts. Davis on the other hand takes a dismissive approach to defence and has low chances of catching Phillip. Moral of the story: these things are real, let us be interested even in the silliest possibilities, because it is the small, overlooked things that let down even the strongest. Kind regards, Bernard On 16 July 2012 13:09, <[email protected]> wrote: > @By joining the LAN, i circumvent outward facing firewalls, IDS & IPS > rendering them useless. > > Which LAN are u joining and what are you allowed to do when you have > joined? (The whole corporate network is segmented by VLANs, Firewalls, > Routers and protected and monitored) > > > @I then one of my scripts would poison the local DNS cache or just > setup a rogue DNS server. The motive here is to get > http://download.newbusonline.standardbank.co.za to resolve to my > laptop running apache2 with a fake download page (thanks to httrack, > dreamweaver + photoshop). > > Banks run DNSsec > > > > @Ntop & wireshark can help get a quick > feel of the network and single out the accountant's IP. > > This means you will have to leverage promiscuous mode which can only go as > far as the segment to which you are connected, yet will quickly signal to > the manager about its presence on the corporate network. > > > > > @With that, just MITM that IP with ettercap > > And you think there is no EAP TLS or EAP TTLS? > > > > > @But even if its the l33t dude, they will be a little complacent > after installing this banking app several times and my bet is they > will just follow the advise of the banking support team and reinstall > without looking at the bigger picture. > > No, you are wrong, installation alarms will ring as the app is being > fetched for installation from your fake laptop server > > > > > @How many sysadmins on this list have never installed unsigned binaries vs > those who have, even when checksums are available online. > > Pre installation checks sound the alarm, signal to the Network Operations > Center folks, and you can't proceed. > > > > > @i can choose to systematically degrade my star rating by > deliberately making "stupid" but intentional mistakes to down play my > IT prowess. Together with a big mouth, i could win my self a "Golola" > status rating. > Deception is my other tool and any serious attacker doesn't invest a > lot in his ego and feelings. > > Since you are an outsider and not much is known about you, then not much > is availed to you either. > > > > > @You realise that i choose the Stanbic banking software which is a java > desktop app NOT an applet. And its not hard to convert my code and > compile my exploit as a java jar file instead of doing an applet. > > Recall, your fake desktop app needs to talk to your fake server or talk to > the real app server or otherwise simulate the expected real app server > responses for the accountant to act accordingly. With all internal > controls in place like EAP, IPsec, SSL/TLS, PKI, SAP proprietary controls, > etc your payload stands no chance through the network. > > > > > > @Its common > practice to protect the perimeter and leave the LAN with less harsh > configurations. > > All security managers learned this from the fall of the Great Babylonian > empire and won't make that mistake. All security managers know that a > great deal of attacks stem from the inside (disgruntled and poorly paid > employees) and will assign appropriate labels to each LAN segment and > there by the minimal protection needed for it. Besides you can't pass Bank > Auditing checks when you are running such networks and risking client's > money. You may want to be able to defraud the overnight banking rates, but > probably not via this scheme. > > > > > > @A good setup would require a healthy IT budget that may not always be > the case on most organizations. But again even with meager funds, the > IT team may use open source solutions like Packet-fence and with VLANs > make the attacker's stomach catch some gastric distress. > But just in case i don't succeed, i wouldn't kill myself over that. > Sometimes the IT dudes have done a great job and there is little you > can do (shit happens). > > Well said > > > > > > @simple complacency of just running Linux or Mac OS and banking on the > root password being your security > > 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) > > > > > > > @Also note that much as i would love to demonstrate or give full > specifics of how i could successfully launch such an attack; there may > be legal implications on sharing such material openly especially when > such an attack can cause financial & trust issues for a big bank like > Stanbic. > For that reason, i won't post more details on this kind of thing. > > Just be careful with what you are concealing: Strong and robust security > lies in mathematics not secrecy (i know you will argue that keys are > supposed to be secret, and yes they are kept secret by publicly known > mathematics which you can't hack). You could think you are concealing good > secret info, yet you are sitting on a time bomb about to shutter you.... > > > > > > > > > > >>>> Every banking web interface I have ever seen has been running over >>>> SSL/TLS, so you would run into problems impersonating a server no >>>> matter >>>> how firmly you manage to lodge yourself in the middle of the data >>>> stream. >>>> And this is usually only the *first* line of defence; next up is the >>>> user >>>> authentication, which takes place in either one-time passcodes on >>>> scratchcards or a challenge-response keyfob. The latter would be >>>> especially >>>> hard to fool, since even if you were in a position to intercept the >>>> challenges and responses, sensible banks craft the challenge string to >>>> correspond visually to the user's action, and would thus stand out like >>>> a >>>> sore thumb if you had managed to substitute a rogue action (such as a >>>> generous donation to you) and were trying to get the user to sign it. >> >> Really???????? >> Stanbic Business Banking app is a java desktop application that is >> installed by downloading a JNLP file (tanzanite.jnlp) down-loadable >> from here: >> >> http://download.newbusonline.standardbank.co.za/Tanzanite/Tanzanite.jnlp >> >> The jnlp file when executed, will download a set of jar files that >> constitute the banking app. >> >> Also take note that the page where the tanzanite.jnlp is downloaded >> from is not SSL protected. These people don't even give you md5 or >> sha1 checksums to verify that you got the right jnlp file. This means >> that if i can get you to download my "adjusted" jnlp file, that picks >> my dirty jars with the exploit; you will install this fake & trojaned >> banking software. So lets get to how i would get you to download & run >> the wrong jnlp file now . >> >> I would choose not to attack from the outside (am a lazy dude, and i >> have a life) but to attack from within the organization. I would ask >> politely for a wifi password (if i fail to crack it) or a LAN cable, >> from the receptionist or a manager as long as i can get to convince >> them that am there for real business (print a serious plastic ID from >> Nasser Road, visit the company website and study their business and >> all i need to do is show up as a serious potential client. That could >> help me soften the sales manager when i ask for help to help me send >> an email to my boss via KMAIL which is on my laptop). >> >> Once i join the network, i will launch a series of scripts (to >> automate & speed up my attack) in my terminal launched via yakuake >> (and with the help of the screen command, hide my 3v1l works). I >> choose yakuake because i can hit F12 as a panic key. >> By joining the LAN, i circumvent outward facing firewalls, IDS & IPS >> rendering them useless. >> >> I then one of my scripts would poison the local DNS cache or just >> setup a rogue DNS server. The motive here is to get >> http://download.newbusonline.standardbank.co.za to resolve to my >> laptop running apache2 with a fake download page (thanks to httrack, >> dreamweaver + photoshop). >> >> The only hard part is getting the sysadmin to reinstall the exiting >> app on the accountant's pcs. Ntop & wireshark can help get a quick >> feel of the network and single out the accountant's IP. With that, >> just MITM that IP with ettercap (with filters to drop traffic to >> stanbic) in the morning hours (that when accountants use the banking >> softwares to check bank balances). The accountant wont be able to >> connect and will call stanbic (crested towers) and as usual, they will >> tell the accountant to talk to the IT people to reinstall the app. >> Most l33t sysadmins hate doing petty installations and will most >> likely send a junior admin to reinstall the app on the accountant's >> pc. But even if its the l33t dude, they will be a little complacent >> after installing this banking app several times and my bet is they >> will just follow the advise of the banking support team and reinstall >> without looking at the bigger picture. >> >> >>>> this is the interface for citizens and small businesses; I would assume >>>> larger corporations would be granted access to nicer security options >>>> such >>>> as pre-shared one-time client keys. >>>> How would you go about circumventing the above safety measures? >>>> Hypothetically, of course, but hypothesising is fun :) >>>> >> >> I know that. But heck, am here for the long haul. I could sweet talk a >> lady or come up with something. >> I could actually bring in a good looking l33t girlfriend to help me >> out here (i could vet some interns from MUK for this job). The IT >> dudes may actually suffer unexplained change of behavior (trust me, >> this usually works). >> As you have already figured, i would lean heavily on the human element >> to solve some of my security/lockout challenges (remember am a lazy >> dude with a life). >> >> >>>> Oh, and any sysadmin who installs unsigned binaries from an unchecked >>>> source in a sensitive production environment would most certainly be >>>> fired, >>>> with a memo stapled to the forehead which says "did not finish >>>> pre-school; >>>> should not cross the street or operate any machinery unsupervised". >>>> Perhaps >>>> not literally, but close enough. >>>> >>>> >> >> You are right. But lets do a fair poll on this list. How many >> sysadmins on this list have never installed unsigned binaries vs >> those who have, even when checksums are available online. But one >> thing for sure, not all those who have installed these unsigned >> binaries are that "stupid" or generally not IT/Linux savvy enough. >> Point here is; complacency is a sweet exploit in the human element and >> once in a while shows its ugly self with serious consequences. >> >> But hey, remember -- we are running an APT here; meaning that i will >> work low and patiently. >> Another characteristic of an APT is that the attacker blends a >> collection of attack vectors, methodologies & tools that individually >> would probably not go far BUT in combination would give you >> astonishing results. >> >>> @Trick the end user into running my exploit: >>> Yes that is possible, and its a big time night mare if you are the >>> security manager (actually if you said that and it was found out you >>> were >>> very knowledgeable in computer programming, that would merit cautioning >>> other security managers about your activities) >>> >> >> I agree. But i can choose to systematically degrade my star rating by >> deliberately making "stupid" but intentional mistakes to down play my >> IT prowess. Together with a big mouth, i could win my self a "Golola" >> status rating. >> Deception is my other tool and any serious attacker doesn't invest a >> lot in his ego and feelings. >> >> >>> @Leveraging Java Applets >>> On a properly managed and hardened corporate network that runs properly >>> signed apps only, using that route may get you gasping for breath >>> >> I know. This may slow me down but i believe that i can find a weak >> link if i can extend my stay or visit at the company. >> >> But its good to point out here that the particular exploit this thread >> is premised on was packaged as a java applet. But being a programmer >> and the exploit author, am at liberty to give my payload a different >> packaging that is relevant to my victim (one that will have a better >> chance of succeeding). >> You realise that i choose the Stanbic banking software which is a java >> desktop app NOT an applet. And its not hard to convert my code and >> compile my exploit as a java jar file instead of doing an applet. >> >>> @DNS cache poisoning >>> That could have fooled Pompey, but not properly managed recent day >>> Banking >>> systems >>> >> >> 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). >> >>> @crack the WEP or WPA >>> You may be able to compromise RC4, but not AES given you are not one of >>> those three letter orgs like NSA >>> >> >> Like i have already explained, once i fail or the process is slow; the >> human element (social engineering) could come in handy. And am a >> resourceful guy remember who is here for the long haul. >> >>> @beating some IDS & "corporate" firewalls >>> That's also a long term and very costly project if ever feasible; >>> beating >>> properly configured network based and host based IPS and IDS and not >>> talking cheap IPS/IDS here >>> >> >> When am on the company LAN, i can take my chances on this. Its common >> practice to protect the perimeter and leave the LAN with less harsh >> configurations. >> >> A good setup would require a healthy IT budget that may not always be >> the case on most organizations. But again even with meager funds, the >> IT team may use open source solutions like Packet-fence and with VLANs >> make the attacker's stomach catch some gastric distress. >> >> But just in case i don't succeed, i wouldn't kill myself over that. >> Sometimes the IT dudes have done a great job and there is little you >> can do (shit happens). >> >>> @Leveraging dynDNS >>> Usually there is a shared TSIG file btn DHCP and DNS that is used for >>> updates between the two, may be you could try to exploit that, but, >>> but.... >>> knowledgeable security managers have controls for that. >>> >> >> Thats easy, once i can't find any files or don't get a ping to my CC >> (command and control) server from my victim. I release a newer version >> of the exploit with the option of switching to a list of hard coded >> public IP addresses of a few attack servers bought with stolen credit >> cards from the some Russians hacker groups (Hey, did i mention that I >> play nice with others? Most "security/data analysts" (some euphemism >> here..) are natural team players). >> >> In summary, spear phishing attacks (highly targeted phishing) attacks >> have recorded high success scores lately due to the poor security >> sensitization mechanisms with corporates; a loop hole i would gladly >> exploit! >> The attack i describe here is a spear phishing attack and i would >> chose that over other forms because its most likely to succeed. >> >> Also note that much as i would love to demonstrate or give full >> specifics of how i could successfully launch such an attack; there may >> be legal implications on sharing such material openly especially when >> such an attack can cause financial & trust issues for a big bank like >> Stanbic. >> For that reason, i won't post more details on this kind of thing. >> >> And also, am an ethical chap. Just brought up that example just to >> demonstrate how such an exploit can be re-packaged and launched >> successfully as part of the larger attack which would eventually allow >> me to capture the root/admin passwords in the long run and may be pawn >> a few servers (these could come in handy some day or i could trade >> them with some Ukraine hackers to run botnets or something. Though >> that would be just a secondary objective.). >> >> Bottom line, for a seasoned attacker (who could even be a foreign govt >> or a l33t group) never underestimate the damage you can suffer out of >> simple complacency of just running Linux or Mac OS and banking on the >> root password being your security (the human element is the biggest >> exploit out there, and it will open gates for any other exploit if you >> run it well; irrespective of the OS you run). >> >> A few links may be in order here to demonstrate how blended attacks >> (using trojans and a range of attack vectors) together with some the >> H-element paid off even on Linux servers e.g the kernel.org servers): >> >> http://citadeladvantage.blogspot.com/2012/05/hackers-ply-new-tactics-against-banks.html >> >> http://www.securitynewsdaily.com/1506-citadel-banking-trojan.html >> >> http://www.extremetech.com/computing/120981-github-hacked-millions-of-projects-at-risk-of-being-modified-or-deleted >> >> http://www.linuxfordevices.com/c/a/News/Kernelorg-hacked/ >> >> http://www.infoworld.com/t/hacking/lockheed-hack-should-put-the-us-high-alert-329 >> >> http://www.wired.com/threatlevel/2011/09/sony-hack-arrest/ >> >> >> Cheers, >> >> -- >> - 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. -- 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.
