The Tech Herald recently spoke with Trusteer CTO Amit Klein, who took the time to talk with us about application security, the state of crime on the Internet and various other topics.
Amit Klein chats with The Tech Herald. (Photo:Trusteer)
Trusteer is a different kind of security vendor. The company does not sell to consumers, instead its product 'Rapport' is sold to banks and e-commerce companies, which, in turn, offer it to their customer bases. Trusteer was founded in mid-2006 by Amit Klein, who came on as the CTO, along with Mickey Boodaei (CEO), and Shmulik Regev (Chief Architect).
Rapport is unique: this little desktop agent has no interest in identifying malicious processes or programs on a computer. Instead, it watches Web-based transactions and monitors browser processes. Taking this approach, Rapport keeps Malware from logging keystrokes, redirecting browsers to malicious Web sites, or hijacking sessions and compromising the current transaction.
ING Direct and Muriel Siebert are early customers, and with the state of financial security today, this start-up is bound to take off. That is, if it isn’t bought out in the near future.
So who is Amit Klein? Amit started his career in 1997 with Perfecto Technologies, this later became Sanctum and was later rolled into Watchfire.
“I left Sanctum in 2004 to join Cyota (now “RSA, the security division of EMC”) as their chief scientist. Finally, in mid 2006 I joined Trusteer as the CTO -- which is where I am today,” he explained. Klein is a WASC officer and board member, and honestly has far too many articles and papers on security to reference.
This led to the Tech Herald's first layered question:
What was it that got you started in security? As an ex-member of the Israeli Army did that have anything to do with it, and did the time spent in the military help guide subsequent IT career choices?
“I think that the “security researcher” within me has always been there. In many instances in my life I found myself looking at a system and thinking of ways it can be attacked. From shoplifting to border control, and from computers to physical security, I was always interested [academically, he stresses] in ways to circumvent protection mechanisms. When I started working in the IT industry, choosing the information security sector was simply a way for me to finally exercise this critical thinking and put it to use,” Klein explained.
Web Application Security is a big topic; it has its fans and those who see it as snake oil. As an expert in this area, TTH asked Klein how he explains its use in business and how it is he enforces the point of why it is important?
“Frankly I can’t see how it is “snake oil”. Here’s why -- in order to secure their Internet infrastructures and online transactions with consumers - businesses must address two separate web application security contexts,” he offers.
“First, the “site to consumer context” in which the site has to establish a “secure channel” with the consumer, allowing the two parties to interact, exchange sensitive information and conduct critical transactions. In this context, application security provides a guarantee that the web site’s end of the channel is not breached. Needless to say, this same guarantee has to be somehow provided for the client side, which is where Trusteer comes in, by the way.
“Second, the “site to visitor context”, in which the site has to secure itself against abuse attempts, e.g. attacks that plant malware on the site, or redirect visitors to a malicious 3rd party site. While the web site functionality itself is not directly impacted, this type of compromise affects both public confidence in the organization and the public health of the Internet. Of similar nature are web site defacement attacks and DoS attacks, which directly impact the company’s business.”
Rounding out his points, Klein adds: “If a site is vulnerable in the first context, consumers trying to conduct financial or other sensitive transactions can have their identity data and or assets stolen. This is a serious problem. The more sensitive the web application, the more serious vulnerabilities become. If the site is vulnerable in the second context, it may lose business and credibility due to the PR impact and the bad image that may be associated with such events. For some sites, this may be even a bigger problem than the first one.”
With that said, TTH asked for Klein's thoughts on a recent comment concerning Web Application Security Scanners and Firewalls. The comment states: “Web Application Security Scanners and Web Application Firewalls will never replace proper coding and stronger development lifecycle processes.” What does he think about that?
“I see secure coding in a wider scope, covering issues like privacy, anti-fraud, accountability, logging, compliance, integration with other security components (server side, client side) and so forth. From this point of view, web application scanners and web application firewalls are more like “point solutions” that solve technical issues in the narrow sense of “web application security.
“But when you look at the broader scope of transaction security and fraud prevention, the issues become more than just technical web application security problems -- they encompass risk calculations, reach beyond the server (DNS issues, client side issues) and exhibit many layers of complexity that span many systems. These broader issues are not completely addressed by application scanners/firewalls.”
Criminals are still targeting client side applications, they always will. However, the new dynamic is that they are using Web applications to help accomplish this. Considering Klein’s years of experience, TTH asked him how the scales have tipped?
Are companies simply not adopting the better coding and development practices? If they are adopting them, why, for example, did ASP have such a rough time earlier this year with automated exploitation? It was proven that the servers attacked were vulnerable simply due to older coding standards. So what stands out to him as the biggest gap that led to this new vertical of attack?
“The scales tipped when attackers developed mechanisms for infecting more PCs in less time. As spam filters became more efficient, infection by email became more difficult. Attackers soon figured out that they could infect machines by injecting their own HTML code (typically frames) into legitimate web sites to automatically infect visitors. Finding insecure web sites is easy using Google to look for patterns that expose vulnerabilities. I suppose they did so with ASP-related patterns.
“Now, ASP can be found in (old) 3rd party code, or in older in-house code. Many web site operators won’t fix vulnerable (but working!) code just because it’s insecure. So even sites which don’t develop new ASP pages today, and which enforce secure coding practices on their new code, can still be vulnerable to attacks against their existing ASP and old (ill-written) code. In short, the problem may very well be in legacy code and 3rd party (old) code.”
So what makes the Internet such a lucrative target for crime?
“To put it in the words of Willie Sutton , "Because that’s where the money is." And nowadays, the Internet is full of money -- online banking money, eBrokerage, eCommerce, online advertisement (clicks), etc. Securing online transactions is a huge challenge, which is getting more difficult as attacks become more sophisticated,” he answered with a bit of humor.
Getting serious he adds: “It’s not just about the web server, anymore. It’s increasingly about securing the path between the web server and the client which traverses proxy servers, firewalls and routers, it’s the DNS infrastructure (consider Dan Kaminsky’s generic DNS cache poisoning attack earlier this year, and my own sequence of per-server attacks earlier), and last but not least it’s the client itself, namely the browser, and its surrounding operating system. In order to conduct a secure transaction, a business needs to make sure every link in the chain is secure. In order to successfully commit a crime, an attacker only needs to find one weak link.
“Finally the anonymous nature of the Internet and potential financial gains make Internet fraud very enticing – think of a Ukrainian fraudster that defrauds a Japanese citizen with a British bank account by hacking into a Kansas City server. The complicated nature of tracking down and prosecuting criminals on the borderless Internet makes it an excellent breeding ground for crime and a nightmare for law enforcement.”
The Tech Herald also asked Klein to list some basic security tips he would give to a normal Internet user worried that “hackers are out to get me,” which would ease some of their fears. At this point he makes another joke, by asking us specifically, “You mean beyond installing Trusteer Rapport?”
“Seriously, I think the single best practice is to avoid being infected in the first place. A good idea is to resist the attempt to run anything that comes through email/web. And yes, this includes the dancing skeleton “movie” and the IRS “invoice.”
So where does he see criminals heading next, and what will be the next big thing they use to get what they're after?
“I think we’ll see more and more “unique” Trojans, where a master copy/template resides on a server, and each request from the server yields a mutation of that template. This strategy is designed and likely to defeat anti-virus tools,” he said.
“We’ll see more covert Trojans that are better at hiding in the operating system, kicking in only when online transactions take place. And the activity (payload) of the Trojan may be customized per the web application the user interacts with – e.g. in an online banking context, a Trojan may define a new payee (on behalf of the user), and start siphoning money to this new payee, possibly soliciting the unintended cooperation of the user to achieve that. Using this approach, the Trojan maximizes the impact of the “man in the browser” (or “man in the middle”) attacks, making it very hard for the server’s fraud detection systems to realize that the activities are not initiated by the legitimate user.”
Same focus, what will be the next big thing for IT security?
“We’re seeing a trend of moving into the cloud – i.e. security offerings that combine data from different agents in a central location, thereby leveraging the installed base to form a distributed network of knowledge which is bigger than the sum of its nodes.”
Finally, each interview subject has to tell a battle story, so TTH asks him to detail a security issue he had to deal with that simply drove him nuts? How did he resolve it?
“In late 2003, I was called in to look at the results of a web application audit Sanctum conducted for a customer. The results weren’t very interesting – we didn’t even find a single event of cross site scripting (later it turned out that they went through two different audits specifically for cross site scripting before they hired us). We were reluctant to hand in such as report, because we had a hunch that the site was somehow vulnerable,” he starts.
“So I fired up some HTTP investigation tools, and started looking at the site. After a while, I noticed that it was possible to inject data into the HTTP response stream. Unfortunately, the response at hand was a 302 (redirection) HTTP response, which the browser (at least, Internet Explorer) doesn’t really parse. And while it felt like a security issue, I didn’t quite know what to do with it. I had to sit and think. Here was something I was sure represented a security vulnerability – but I didn’t know how to exploit it. This was very frustrating. But I soon realized that by injecting data into the response, I could split it into two – the first response was the original 302 response, and the second was a brand new injected HTTP response.
“Now it was a matter of how to exploit this, but that wasn’t too hard – I made the browser send another request over the same TCP connection, and thereby I had the browser “consume” the response that was already there waiting for it. At this point, I could demonstrate cross site scripting (which was a big thing for the site), but it turned out that I could do much more, such as web cache poisoning, and crossing wires in HTTP requests/responses going through proxy servers.”
If you want to read more, Klein informed us that a paper, which summarizes his findings, was published in 2004. You can read it by clicking here .
Comment on this Story