Trojan horse attack involving many major Israeli companies, executives

[Anne & Lynn Wheeler]

Amir Herzberg wrote:
> Nicely put, but I think not quite fair. From friends in financial and 
> other companies in the states and otherwise, I hear that Trojans are 
> very common there as well. In fact, based on my biased judgement and 
> limited exposure, my impression is that security practice is much better 
> in Israeli companies - both providers and users of IT - than in 
> comparable companies in most countries. For example, in my `hall of 
> shame` (link below) you'll find many US and multinational companies 
> which don't protect their login pages properly with SSL (PayPal, Chase, 
> MS, ...). I've found very few Israeli companies, and of the few I've 
> found, two actually acted quickly to fix the problem - which is rare! 
> Most ignored my warning, and few sent me coupons :-) [seriously]
> 
> Could it be that such problems are more often covered-up in other 
> countries? Or maybe that the stronger awareness in Israel also implies 
> more attackers? I think both conclusions are likely. I also think that 
> this exposure will further increase awareness among Israeli IT managers 
> and developers, and hence improve the security of their systems.

there is the story of the (state side) financial institution that was 
outsourcing some of its y2k remediation and failed to perform due 
diligence on the (state side) lowest bidder ... until it was too late 
and they were faced with having to deploy the software anyway.

one of the spoofs of SSL ... was originally it was supposed to be used 
for the whole shopping experience from the URL the enduser entered, thru 
shopping, checkout and payment. webservers found that with SSL they took 
a 80-90% performance hit on their thruput ... so they saved the use of 
SSL until checkout and payment. the SSL countermeasure to MITM-attack is 
that the URL the user entered is checked against the URL in the 
webserver certificate. However, the URL the users were entering weren't 
SSL/HTTPS ... they were just standard stuff ... and so there wasn't any 
countermeasure to MITM-attack.

If the user had gotten to a spoofed MITM site ... they could have done 
all their shopping and then clicked the checkout button ... which might 
provide HTTPS/SSL. however, if it was a spoofed site, it is highly 
probable that the HTTPS URL provided by the (spoofed site) checkout 
button was going to match the URL in any transmitted digital 
certificate. So for all, intents and purposes .. most sites make very 
little use of https/ssl as countermeasure for MITM-attacks ... simply 
encryption as countermeasure for skimming/harvesting (evesdropping).

in general, if the naive user is clicking on something that obfuscates 
the real URL (in some case they don't even have to obfuscate the real 
URL) ... then the crooks can still utilize https/ssl ... making sure 
that they have a valid digital certificate that matches the URL that 
they are providing.

the low-hanging fruit of fraud ROI ... says that the crooks are going to 
go after the easiest target, with the lowest risk, and the biggest 
bang-for-the buck. that has mostly been the data-at-rest transaction 
files. then it is other attacks on either of the end-points. attacking 
generalized internet channels for harvesting/skimming appears to be one 
of the lowest paybacks for the effort. in other domains, there have been 
harvesting/skimming attacks ... but again mostly on end-points ... and 
these are dedicated/concentrated environments where the only traffic ... 
is traffic of interest (any extraneous/uninteresting stuff has already 
been filtered out).

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com