Hacker Crashed My Zoom Engine Last Night

[Datasmith]

Running Version 7.0.1017
Dot.Net implementation (ZoomASPX.dll)

I am running the DLL in its own App Pool.

Last night a hacker imbedded a near-2k long SQL injection script in my Zoom search query string.
The search engine's dedicated app pool crashed and shut down.

Has anyone using the Dot.Net implementation ever seen this happen before?
Should I move up to the latest version? (7.0.1023)

I just had to restart the App Pool and everything is running again.

[Ray]

Zoom doesn't use any SQL, so there is no way that the injection script would achieve any intended effect.

So the only possible issue is the length of the query.

In IIS, there is a configurable limit to the query length. The default is 2048 characters. When the query exceeds this limit, the user will see a "HTTP Error 404.15 - Not Found" / "The request filtering module is configured to deny a request where the query string is too long." message. This can be configured, as described here:
http://www.iis.net/configreference/s.../requestlimits

We ran through some tests here using the latest build (V7 build 1023) and could not replicate a scenario where a query greater than 2000 characters would crash the application pool. By default, it would trigger the error as described above (but the application pool did not crash). When we then changed this limit to 4000, and submitted the long query, the search would simply execute with either "No results found for ..." or "No search query entered" if longer.

So going forward, you should:
1) Upgrade to the latest build (both indexer and the ASP.NET Server Control) to avoid discrepancies.
2) Try this query (presuming from your log) and see if you can reproduce the crash.
3) E-mail us with the query in question and we can try it here. If the index files are not too large, it may help to include these too so we can replicate the same scenario.

Note that there are other possible reasons that the application pool has terminated. It can be configured to terminate on certain situations (e.g. load) and it can also be configured to recycle so you would not need to manually restart it.

Also worth noting is if your .aspx page does anything else with the query. If your masterpage processes the query or viewstate etc. it is possible that the long query upset something else within your .aspx page.

[Datasmith]

Thanks for the feedback, Ray.
Will be upgrading to the latest build this coming weekend.
By default the app pool is set to shut down with 5 successive failures within 5 minutes.
I am following up with an email containing my log entries and some other info.
I was unable to replicate the info exactly as found in my log files. At least not by inserting the data into any of my test browsers' url windows or on the actual search page's input form. They must have built a custom form to submit for the hack.