Keep Your Friends Close and Your Domains Closer!

Stay updated on FogMarks!

Happy 2019!
Hopefully you guys have survived new year’s eve and didn’t ignore the alarm clock and wake up 2 hours late like someone I know did..!

So, after my sincere, heartbreaking apology last year (i.e. two days ago), as promised- here is the case study. Unfortunately, the involved company did not allow me to disclose its name, due to the possibility that the vulnerability we are going to discuss about still exists in some other variations or platforms of it.

So what is this all about?

To start the new year with the right mood, today’s case study will present a different kind of vulnerability. A so-called “logic flaw” that can happen to you as well, with a bit of unawareness to it.

So a certain company had a middle-age crisis. Some fundamental, non-tech errors has been made, the stock went for a 40-meter dive at the Red Sea, and 30% of the stuff have been fired. The CTO was among them.
As bummed as it may sound, this situation is not new. A lot of tech companies, even solid and super-rich ones suffer from it. Once money and non-tech stock holders are involved, things can get pretty rough and actions are being taken too quickly, sometimes.

That company’s main business is providing frontend Javascript rich text editing services: their main product is a beautiful WYSIWYG editor which is serving dozens of popular platforms and websites.

No, not another WYSIWYG XSS!

The thing is, that their WYSIWYG editor was great. It didn’t had known security vulnerabilities, it functioned terrifically and was a great success.
To distribute it to their customers, they had offered them to install it via npm, or to reference it directly via their official CDN (i.e. place <script src=”https://xxxx.yyy/WYSIWYG.js> and .css in the source code).

If you’ve read my past posts regarding the latter solution- asking (or forcing) the clients to directly reference to your CDN, so they could have the latests patched release every time, you will think that there is nothing wrong with that.
Well, here is something I didn’t think of when proposing you to be referenced directly from your clients: you may loose your domain!


Indeed. Remember that I said that the CTO was fired during the middle-age crisis? Well, one of his responsibilities was to renew the product’s domain (which was different from their main logic and their UI – for his credit!).
After he and some other dev stuff got fired, the board has such a mess and they have completely forgot that the globe is still spinning and that bills should be payed..

When the fatal date arrived (on Sunday, of course)- everyone was asleep. Except from a domain-troll bot which had immediately acquired the domain.


Actually, the title is misleading. Badly.
When I was approached to with this problem (36 hours after the domain loss and only when the customers have reported it to the help team), I really didn’t had anything smart to say here.
The domain was bought legally by another company who saw it was expired. What can be done? Sue that China-Taiwan-New Mexico-Arab Emirates-Thailand legit company? Hack into their systems and liberate the stolen domain? Nothing can be done fast enough to minimize the damage to the customers and to the company, except starting a negotiation with the domain acquirer and praying for god (or whatever).


The crisis has ended ironically near the last day of Hanukah,  With the company buying back the domain for a very, very overpriced price. Well, even Trolls gotta eat.

So why did I chose to open 2019 with sharing you this type of a case-study? Because security vulnerabilities are endless, always was and always will. But all of them are solve-able. Some can be solved easy, some can only be solved after 3-gallons of coffee and 1 liter of the dev team’s tears, but eventually software issues are solve-able.
This was not a software issue. This was the loss of a very expensive and important asset, which resulted in a massive money loss (and a few customers, who is now doubting the company’s stability).
So what can be done to prevent these types of “vulnerabilities”?

  1. Don’t fire the CTO. Glue him to his chair if you have to. I’m kidding. Implement the approach in your company that when a member leaves – wether its the CTO or a QA personnel – he writes down his responsibilities and passes them to his successor. Like-da?
  2. For this specific domain-loss issue: For god’s sake – Buy domain names and similar assets for 10+ years! You are a f*****g commercial company and it costs nothing to you.
  3. Always monitor your services, internal and external ones. The clients should never be the one who detects the issue in your platform or service. Some 3rd party keep-alive functionality will do the trick.

2018 was a great, super-educating year. I wish 2019 will be even more educating and even more challenging.
Happy New Year!

Image result for 2019 fireworks icon