Uniface application(s) and CryptoLocker or derivative infection(s)

Author: gianni.sandigliano@unifacesolutions.com (gianni)

During latest months we faced with a couple of situations where local (Microsoft based) network at customer site were infected with CryptoLocker virus or one of its derivative. One of those customer is asking to put in place a project to minimize potential effects of a new infection of this kind, minimizing implementation costs as much as possible. So far I came up with 5 technical solutions: 1 - Rewriting application going to 3 or more tiers 2 - Uniface Anywhere 3 - Small readonly disk share with Uniface Polyserver 4 - Microsoft Terminal Server 5 - Readonly disk share The order of listed solutions is not casual but it is based on (probably) costs, from higher to lower. Solutions #1 and #2 are definitively not feasible because of higher related costs. Solutions #3 and #4 are more or less on same level (about #4 the customer owns already a good number of MS TS CAL licenses because (part of) the application is already delivered this way). Work efforts to be applied for solution #3 and #5 are technically similar but solution #3 is involving also Polyserver (sorry...Exclusive UServer) costs. The more affordable choices are somehow going in the direction of a readonly share...but: putting Uniface files in a readonly share is really applicable? My first thinking is: - Whole Uniface C/S (sorry Desktop) deployment environment could be defined as readonly?   YES (hope so...never tried really...) - In a Uniface application directory tree is it possible to separate readonly from readwrite directories?   Generally YES; only LOG files and TEMP files should be de facto writable on file system at runtime while real data go into database. - ASN files are never rewritten at Uniface runtime? - INI files are never rewritten at Uniface runtime? - INI files are (very often) including logical printers related to each specific workstation/workplace...how about them? Generally speaking which part of config files (INI / ASN) is specific for each workstation? Any further feedback is appreciated. Gianni

5 Comments

  1. Hi Gianni, A quick search learns dat read-only files on NTFS file systems should indeed not be vulnarable to Cryptolocker. Unifacewise, from the top of my head I'd say: .ASN files are not written to .INI files, probably IDF writes to some during use (?) Uniface likes to be able to write to log and transcript files (if defined that way in ASN) Uniface debugger likes to write into UDBG.cnf So for run-time environment you will get far in making everything read-only, for the development environment probably not. One other thing not to overlook: your Uniface application itself (if programmed that way) could do all kinds of file dumps, even write into sections of any Windows .INI file through a signature and the Windows API. You could consider a "\Workdir" sub directory as part of your Uniface app tree. Shortcuts would have the path to the "\Workdir" sub directory as value for the "Start in" directory. Only the Workdir subdirectory would be writeable and then gets the role of a "garbage collector" directory. It will also collect file types that are not properly redirected in your ASN files. I've used this kind of set up for year for production environments.  All the best, Arjen


    Author: Arjen van Vliet (arjen.van.vliet@uniface.com)
  2. Arjen van Vliet said ... You could consider a "\Workdir" sub directory as part of your Uniface app tree. Shortcuts would have the path to the "\Workdir" sub directory as value for the "Start in" directory. Only the Workdir subdirectory would be writeable and then gets the role of a "garbage collector" directory. It will also collect file types that are not properly redirected in your ASN files. I've used this kind of set up for year for production environments.  ...

    Me too! I've always suggested that structure to ALL Ucustomer I had the chance to work with... My current case (I feel) has a degree of complexity (3 separate Uniface applications, one of them with a Java front-end, Tomcat as a separately installed product but used somehow from all Uapplications and from the Java one...) to be managed. Defining a clear separation line between readonly and readwrite for each application will require few more efforts and probably a few tricks ;-) Anyhow thanks for your input: I do not need to protect development environment but only deployment and I was forgetting the need (sometimes) to debug at enduser workplace. Gianni


    Author: gianni (gianni.sandigliano@unifacesolutions.com)
  3. Hello, just a quick info... we deploy our application like this: Everything is on a network share. I mean, there is the Uniface runtime with all necessary files (.ini, .asn, our own .dll files...), all (Uniface) resources (basically the whole resources directory), Oracle instant client and so on. And then, there is our own .exe file - kind of downloader or installer or launcher or whatever you call it. All that user needs to run is that simple .exe file (the launcher) and it does everything. The share is readonly for all users (except admin of course) and our launcher checks for new versions, modified .dll or anything. There is also a check for vcredist to be installed locally and so on. Then the Uniface runtime is copied to the local disk, resources are kept on network share. If there is a virus (it has already happened), then user has to get rid of it and then just run the launcher with the "new install" option, which removes everything from local disc and copies it again. Since the net share is read-only, it should not be infected by any virus. If admin gets virus then... OMG. :-) Nevertheless... with this approach it's very easy to run our application on any computer. Kind regards, Zdeněk Socha


    Author: sochaz (zdenek.socha@fullsys.cz)
  4. Hi guys, first tries today with following configuration: A) a readwrite local directory where all new or temp files should be written B) a readonly share on a network disk where Uniface runtime as well as all Uniface application objects resides Using a non administrator domain account Uniface Application is starting (hurrah!) but: - executing some application functions is remaining locked for minutes (1-2...) before showing the form layout - in other application functions is remaining locked for minutes (1-2...) executing a retrieve When the application is remaining locked for minutes: - mouse cursor is in waiting mode - application screen is becoming sometimes white, sometimes dimmed The question is: what the Uniface application is waiting for such long time ??? ...but also: is it an application issue or a Uniface issue ??? ...and next: how can I solve it ??? Any hint or help is welcomed... :-) Gianni


    Author: gianni (gianni.sandigliano@unifacesolutions.com)
  5. gianni said ... Using a non administrator domain account Uniface Application is starting (hurrah!) but: - executing some application functions is remaining locked for minutes (1-2...) before showing the form layout - in other application functions is remaining locked for minutes (1-2...) executing a retrieve When the application is remaining locked for minutes: - mouse cursor is in waiting mode - application screen is becoming sometimes white, sometimes dimmed ... 

    OK, nothing related to Uniface but a misconfigured database access was causing those issues... Next bunch of test tomorrow! Gianni


    Author: gianni (gianni.sandigliano@unifacesolutions.com)