Hacker News Reader

Comment by gkanai | Hacker News Reader

Mozilla added SEED support to Gecko many years ago. Nothing has been done since then (on the Korean side) to implement support beyond that.

View on HN

But what exactly is needed? What is stopping someone from writing a FF extension that will capture all activex object tags and replace them with something doing the same operations in FF's chrome?

Is the auth protocol completely unknown? Is the activex control obfuscated more than is possible to reverse-engineer?

ActiveX is designed to hook directly into the Windows OS. That's what makes it so dangerous, but useful in this case, since you can add a cert to the trusted store.

Firefox is designed to be secure and sand-boxed, especially its plugin architecture.

You don't need to replicate all of the functionality that activex has. You just need to emulate the behaviour from the banks point of view of whatever their particular activex does. Maybe the ActiveX rewrites a bunch of files with admin privileges "for security", and then negotiates some sort of key exchange... in that case just write JS that says it did the shit that requires admin privileges, then negotiates the key exchange).

So the question is, if you are willing to ignore their activex and run your own custom JS instead, could these websites be made to work?

A major online bookstore (www.aladdin.co.kr) actually tried that this year. They teamed up with another startup company (Paygate) and allowed users to use credit card with no plugins, on any browser. The few people who tried that loved it.

And guess what happened?

Major credit card companies pulled out one by one, because they "cannot ensure" that a page without Active-X is secure enough. Of course nobody's pulling any strings, no government officials are receiving unknown gifts, and nothing can be ever proved. So, there. You work for months to provide users with modern browsing experience, and those banking powers-that-be just pull the plug.

The whole system is corrupt beyond imagination.

Citation (sorry, in Korean): http://www.hankyung.com/news/app/newsview.php?aid=2013091203... http://www.leejeonghwan.com/media/archives/002331.html

That's a solution from the provider's side though. I would have thought that it's much easier to handle it from the client side really... just pretend you did whatever verification was necessary and return the expected result.

Noone should be able to shut it down, because it's on the client side, rather than the service provider, so the retailer shouldn't be blamed.

No no no, it doesn't work that way. These banking websites don't expose a well-defined API that you can emulate. Instead they force you to install a bunch of ActiveX plugins (usually with administrative privilege) and you have to just trust that they won't, say, read the whole content of your hard disk and stream it to a third-party site.

A few years ago (when I was still in Korea), it was usually impossible to open two different bank's pages at the same time: I'd assume that's still the case now. As far as I know, the reason is that both banks will force you to install "anti-hacking" plugins, which hooks directly into your Windows Kernel and makes sure nobody else snoops on what you type. Yes, these webpages try to establish a direct connection between your keyboard and the website, completely bypassing every layer. Now imagine the fun when two such plugins try to run at the same time.

And of course without these plugins you can't use the site. Hell, sometimes these sites spontaneously break just because you're accessing it from the US, because nobody had thought to test them from a client with ping time > 200ms.

Now try emulating that in client. (I don't know if I should laugh or weep.)

EDIT: Besides, if you seriously try to make a platform that can emulate these "security" plugins, sooner or later you will be arrested for making tools to circumvent security measures, and people will be reminded that they should never install anything from "suspicious" sites. (But of course install everything from banking sites.) As a bonus, some news media will claim you were paid by North Korea, and many will believe that.

Thanks, that's the part I haven't heard of before - good explanation of the issue. So if someone wanted to reimplement the client, they would have to reimplement a different one for every single site.

Depending on the difficulty of working around the issue though, I wonder if it's a business opportunity: offer a web proxy which is transparent for all purposes, apart from the activex part - it would replace them with something that's either pretending to run the verification itself, or provides some replacement script. If you ran the company outside of Korea that took subscription money to bypass a number of the most popular services' auth, it would be hard to shut down. (but it would become a cat and mouse game of updating the algorithm until one side got bored...)

Unfortunately this would have to be written in some interesting way that guarantees the passwords / tokens / sessions are never captured by this system, otherwise noone would use it. But that's a technical problem - should be doable in some way.

Thanks for the great explanations. It actually makes some sense that Koreans are getting hacked all the time, since the binary rootkits they're required to install have probably not seen the scrutiny that more open solutions have. Secure systems used in the rest of the world get hacked because of weak entropy or through timing attacks: fairly esoteric stuff. It wouldn't surprise me if these ActiveX blobs have basic algorithmic errors. Do they crash quite a bit?

Sure, they crash (or do something funny) a lot of time, but that's the problem with these ActiveX controls. If you buy anything from a Korean site you end up with an unknown number of plugins downloaded from everywhere, so how do we know if it's a bug in some plugin, a plugin already infected with virus, or just some malware you downloaded accidentally? (The last one, because you have to hit "OK" all the time: actually recent versions of Windows is being quite reasonable and wants to warn you when you install binaries from random websites, but this is exactly what Koreans are asked to do every day, so Korean bank websites contain these helpful pages showing how to lower Windows' "security level" and override the warnings.)

The idea is "Can I, the end user, do this without the banks knowledge or cooperation?"

This is completely false. Firefox extensions have access to everything the browser does and can contain arbitrary native code.

There's a reason Mozilla's addon repository has a review process.

What makes addons better than ActiveX controls is that they're understood to extend the browser for the user's benefit, not merely make a crappy website work. Fewer people would buy that a bank website needs to install a Firefox extension before you can log in.

Such a thing was created many years ago:

http://www.adamlock.com/mozilla/plugin.htm

One could guess that it was never included by default because Mozilla did not want to encourage the use of ActiveX controls.

Oh $BABY_DEITY no! That's not what I was suggesting! Activex in FF? Scared the hell out of me...

What I meant is either reverse-engineering the algorithm and reimplementing it in FF chrome in clean JS like jlgreco mentioned below, or including just the kernel of the important logic, the way ndiswrapper uses windows driver for communicating to the network cards without actually implementing whole windows kernel.

The security implications of requiring users to install Firefox add-ons are not any better than requiring them to install ActiveX plug-ins. (Other than pure vendor politics.) You still have the artificial requirement of some Win32 blob, which is the real issue.

It seems that being forced to use IE on Windows is more limiting than having to install an extension for whichever browser you choose on whichever OS you choose. If the security protocol were published or reverse-engineered, a clean re-implementation outside of Win32 could take place.

It's still an undesirable result even if it compiled a portable Linux .so just for your CPU architecture. The requirements are so flawed the system should be junked, not hacked around.

Also, I'm not sure why my post was dinged, but Firefox extensions/addons/plugins can call into native code and can do pretty much anything an ActiveX control can do. There is no "sandbox" as someone else implied.

But if the protocol is reverse engineered, one could USE the bank websites. There is no need for the reverse engineered solution to do any kind of anti keylogger or virus scanning stuff!

Reply on news.ycombinator.com