Bad Actors Story

Bad actors are not the ones on television or movies, although I can quite name a few since I am a "B" movie junkie. But I digress a little bit. Bad actors as explained in this article are the ones trying to breach your webserver not matter what kind of firewall you have. Once in your system, they want to steal your data and or encrypt your files. Then, because they are bad actors, they want to charge you also called ransomware to get your data back and or system unencrypted. Or if they are really bad actors they may release your data on the internet or send it to your competitors. Some of these bad actors do what they say and return your system back the way it was. Some of these bad actors do not encrypt your system after you paid and demand more payments before they might decrypt your system. Some of these bad actors take your money sell your information on the web for more profit. Unfortunately, you cannot tell what type of bad actor will take over your system and whether you will have a positive outcome from them no matter what action you take. Since I am the cloud site network administrator of ill repute. I see a lot of these attacks and a daily basis. WordPress, PHP, and many others are easy vectors into your webserver. Just recently I had to update our webserver 4 times because of the log4j vulnerability. It seems log4j version 2.14, our original version needed to be replaced by version 2.15. Then log4j version 2.15 need to be replaced by version 2.16. Then log4j version 2.16 needed to be replaced by version 2.17. And finally, version 2.17 needed to be replaced by version 2.17.1. I did not see the article that described the log4j vulnerability until Dec 11, 2021, two days after the problem was announced. By then I had recorded 11 failed attempts by bad actors on our web server. I am constantly restricting IP addresses based on what I see them doing or trying to do. Whether these bad actors are from China, Russia, India, Singapore, North Korea, or even the United States, my external-facing website must be protected from these bad actors. So one holiday night not long ago, it was dark and gloomy from my workstation window. For some reason, the office light was not to be shinning on my back today, but I was fully illuminated from the glow of my two 27 inch monitors when I spotted these log entries from our external facing website. I edited them to fit this snippet box: [02/Jan/2022:17:28:10] "HEAD /?xHAPPY-NEW-YEAR-FROM-DC8044.COM HTTP/1.1" 302 [02/Jan/2022:17:28:10] "HEAD /?x.............................. HTTP/1.1" 302 [02/Jan/2022:17:28:10] "HEAD /?x..............A............... HTTP/1.1" 302 [02/Jan/2022:17:28:10] "HEAD /?x.............dXb.............. HTTP/1.1" 302 [02/Jan/2022:17:28:10] "HEAD /?x..........dXiXXdXXb........... HTTP/1.1" 302 [02/Jan/2022:17:28:10] "HEAD /?x........dXXOXXXXdXXib......... HTTP/1.1" 302 [02/Jan/2022:17:28:10] "HEAD /?x.............dXb.............. HTTP/1.1" 302 [02/Jan/2022:17:28:10] "HEAD /?x..........dXOXXXXXOb.......... HTTP/1.1" 302 [02/Jan/2022:17:28:10] "HEAD /?x......dXXXXiXXXdXXXXXXb....... HTTP/1.1" 302 [02/Jan/2022:17:28:10] "HEAD /?x.............III.............. HTTP/1.1" 302 [02/Jan/2022:17:28:10] "HEAD /?x.............III.............. HTTP/1.1" 302 [02/Jan/2022:17:28:10] "HEAD /?x.............................. HTTP/1.1" 302 [02/Jan/2022:17:28:10] "HEAD /?x...Follow.us....t.me/DC8044... HTTP/1.1" 302 [02/Jan/2022:17:28:10] "HEAD /?x...WEB...........dc8044.com... HTTP/1.1" 302 [02/Jan/2022:17:28:10] "HEAD /?x.............................. HTTP/1.1" 302 [02/Jan/2022:17:28:10] "HEAD /?x HTTP/1.1" 302 [02/Jan/2022:17:28:10] "HEAD /?x HTTP/1.1" 302 -- I don't to whether to commend this person and or company who wasted a lot of time sending me a "Christmas" tree 7 days after Christmas. Or maybe I should commend myself for actually looking at the logs and deciphering what was sent? I am very conflicted on this, but these are definitely bad actors because their website has the words: "Hack All The Things". Or should I be surprised that dc8044 is a hex color composed of red, green, and blue? This should be a warning to all of the companies and personnel to be very careful about who has access to your website. This stunt by this company may look innocuous but its players are "Bad Actors".

XLr8Tools Update to fix zero-day exploit.

 There was a zero-day exploit of a Java library we use call log4j in our XLr8 Tools for Unidata and Universe databases. We have been using that library without incident for 17 years give or take for logging our Java errors. Nonetheless, here is an article that explains this exploit better than I can from PCMAG, enjoy.

Here is our changelog:

v4.17.2 - Dec 12, 2021

  XLr8Developer removed window.changed option since it is not used in Webix

  XLr8Developer added textarea height and width option to size boxes for this Webix control

  log4j update from 2.14 to 2.15

  

v4.17.1 - Nov 18, 2021

  XLr8Installer an option was added to force the creation of a directory file if the file does not exist.

  XLr8Commander right-click option was grayed out in error and is now working.

  

v4.17.0 - Nov 10, 2021

  XLr8Dictionary option added to display on the console dictionary editor reads, writes and compiles.

  XLr8Dictionary editor "Save and Compile Selected" button and menu option failed to write selected items and has been fixed.

  

v4.16.7 - Nov 08, 2021

  XLr8Commandinterpreter was renamed to XLr8Commander in all Java source points.

  XLr8Dictionary editor will no longer show null ids items that were causing errors in display and removal.

  

v4.16.6 - Nov 04, 2021

  XLr8Dictionary editor did not show I-descr that did not match internal values.

It was a good idea at the time

 Creating an HTML page with embedded JavaScript was and is still more art than science. Invariably we ask ourselves many questions:

• Does the page render fast enough?
• Do we have too many images that are slowing the load time?
• Have used the correct code and syntax that runs optimally?
• Does this form enhance the user experience or detract from it?

Having created code back in the early 2000s when HTML and JavaScript were very new, a lot of the syntax and the way things were done back then have changed. But the real question to ask is are we adapting to the new syntax or stuck in our ways?

We unfortunately until COVID-19 reared its ugly head most of us did not have the chance to evaluate if we need to change our coding style and syntax. With an unlimited amount of time and clients that no longer asked for constant changes, we changed our Javascript library from what we had been using for about 8 years to another one called Webix.

About 400 forms need to be updated to use the new library. Our code is program generated, so our driver program needed to be updated to generate Webix code. Moreover, all of the custom code written for the other library had to be adapted to the current library. A lot of code is dynamic so there are many things we need to do with the HTML DOM tree to finagle it so that we get the result we are looking for.

After getting all of these things changed, tested, and released to our customers we thought life was good. Then one of our clients pointed out that they were getting Violations in Google Chrome: "[Violation] Avoid using document.write()." Sure enough, when we turned on the developer tools it was there with this link. The thing we took away from the article was: "With this data in mind, Chrome, starting with version 55, intervenes on behalf of all users when we detect this known-bad pattern by changing how document.write() is handled in Chrome...[t]he script in the document.write() is parser-blocking..."

This technique is how we were able to add dynamic code to our static pages. For instance, if you were using the material UI and wanted to change to Webix contrast UI, we would have to change the form code to the correct cascading style sheets to handle those color and interface changes. On average, we had about 3 document.write() per form. The total hit for rendering the page was about 100 milliseconds according to Chrome. That means we are waiting for 1/10 of a second for Chrome to handle 3 dynamic code links. That is really bad.

It took a few days to digest what this meant for our code generator changes and updating all of our custom code where needed. Next, we need to figure out what code would work since our "Pacer" code would have to be replaced. We search the internet and found this JavaScript code. Of course, we did not use it exactly as they had but someone our staff had already written a dynamic link load code in our standard toolset. Our code generated has been updated to call the JavaScript function and the code has been tested and released to our clients.

Although we are pretty proud of our come, our clients did not notice that the forms loaded any faster. Nonetheless, we celebrated with another toast to code from the 2000s that should have been updated and removed as least in the year 2016 instead of 2021. Oh, by the way, our CEO owned a Pacer back in the day!