I was reading through my email a couple of days ago and noticed an interesting item in a newsletter I subscribe to from SANS institute, a digital security training organization for information technology professionals. It was listed in the “Top of the News” section of the email newsletter and is titled “Malicious JavaScript Detected on US Tax filing Website (April 3 & 4, 2023). Below is a copy of the notice and some editorial comments in the newsletter:
“Malicious JavaScript Detected on US Tax-filing Website (April 3 & 4, 2023) For at least the last two weeks, the IRS authorized e-filing provider eFile.com's website has been compromised and occasionally offering malware to its customers. The website is serving a modified JavaScript file that includes content from the attacker's website. This content is used to direct the site’s customers to a fake error page which will instruct them to install a browser update that turns out to be a remote access trojan.
“Editor's Note
“[Ullrich]
Despite multiple attempts to contact efile.com after we found the issue with their site, the malware is still present as of this morning.“[Neely] As Johannes states in his analysis, it can be really difficult to detect when a trusted partner site gets compromised. Because of that existing trust, users are less likely to contemplate content carefully. This is where your boundary protections, EDR, and other layered defenses come into play. Leverage the IOCs in the ISC posting to ensure none of your users were captured. Consider reaching out to your CPA to make sure they are aware of this issue so they can take steps to mitigate the risks.”
What surprises me still about the hacks and attacks common in deployed information systems is that if the software were designed and implemented competently, using standard foundational theoretical computer science, such problems should be relatively straight-forward to at least detect before they cause any significant damage. Unfortunately, economic expedient governs the business world and the short term functional goals of organizations of any kind dominate their decision making processes. Applying the standard theoretical foundations of computer science could eliminate information system insecurity, but application of such principles, the models and rules which gave birth to the technology and its industry, simply is not mandatory in the field. This incident, arriving at my email inbox entirely without my influence on its reporting, is an illustrative example.
The Deterministic Finite State Automata, or DFA, used as model for developing lexical analyzers of programming language parsers, is the foundational computer science usable in prevention and early detection of information system malfunction due to the introduction of malware. Applied to programming statement parsing, DFA theory states that each state possible in the parsing process defined by the the language's grammar can be ruled either legal or not based on the grammar rules defining the language.
When characters in a programming language statement or expression are read into the parser, the state of the parser’s static representation of the expression changes. When ‘a’ and then ‘n’ are read in, for instance, the parser has not yes recorded any ‘key word recognized state. Then the next character read it a ‘d’, the parser matches the sequence with the keyword ‘and’. Since it is possible that there are variable names which start with ‘and’, the parser needs the next character to determine whether this is the matching keyword. If a space character is read next, then a legal state transition from ‘possible keyword recognized’, to ‘keyword recognized’ takes place. If some other character is read and the parser finds no partial matches in its table of valid function, method, class, or data reference strings, then it has detected an illegal attempted state transition. This process of using each character to attempt to transition to a new valid state, and of course reporting invalid ones, is the general process of what is called ‘lexical analysis’ or ‘tokenization’ of the statement, the token being recognized in this case is the keyword ‘and’.
As tokens are recognized, a token sequence is constructed, and as long as legal tokens are present in the character sequence, the current internal state of the program statement recognizer, the parser, is legal. In addition to ordinary words, tokens can include terminal characters like ‘;’, token dividing characters like ‘,’, grouping characters like ‘(‘, and ‘)’, and numerous others. This is why a simple ‘split on white space’ operation on the entire text will not result in a legal tokenization. It fails to enforce the grammar rules of the language. Assume for a moment that only tokenization occurs on the reading of a program statement text file. The only grammar rule applied is that the sequence of character be recognizable as a sequence of tokens. Only one syntax rule needs to be enforced: that providing for delimiting or separating characters in the text. Almost any character sequence is a valid token in this case, since the parser is not applying the syntax rules yet that determine which tokens are legal. The token which is not a keyword could be any user supplied name of, for instance, a function, method, class, or variable. The unrecognized tokens can be placed into a symbol table, however, and their legality determined later when the grammatical rules of the language are applied. This happens when the token sequence is processed in order, each token either contributing to a more complete expression, or being recognized as not producing any legal state transition as defined in the language’s grammar.
Sequential processing of items in the text is the method used for both lexical, or character sequence, analysis, and for syntax, or token sequence analysis. The next item in the sequence can either be seen as not changing the current recognition state, changing it to some other legal state, or being illegal, i.e. a token that is not allowed in the currently recognized state. If at any point the currently developing state, the state which at any point is comprised of a developing legal expression comprised of a sequence of tokens that were recognized, the next token cannot legally be included next in an expression in the language, an illegal state transition is being attempted in the token sequence. Note that all legally recognized states can only be reached from other defined and therefore legal states, and can only be reached using the next character or token in the sequence. This is the essence of the Deterministic Finite State Automata, or DFA, the theoretical model used by computer science for program statement analysis generally, and the one which made programming languages possible.
A DFA is the collection of all valid states that a system can be in, meaning all stored data in the case of an information system, plus all of the legal state transition rules applied in any state context when a new event arrives. It’s state transitions are driven by events, the events in this case being the characters in the text or the tokens in the token sequence constructed from them. The DFA implementation which works as a grammar recognizer reads a sequence of characters and for each character event decides which state to transition to next, if any. If no legal state can be reached, then there is an error in the character stream. The same process is applied to the token sequence constructed in the initial reading of the text.
More generally, the word "state" simply refers to all of the values stored in a single snapshot of a finite, bounded information system. The snapshot is done between events, which in the case of a compiler are the arriving characters in the character sequence. What isn’t obvious is that every information storage and processing system is a DFA which has filtered and ordered state changing events arriving in a time ordered sequence, generally known as input, each of which can change the state in ways that either comply with the intended design or don't. Theoretically, therefore, every invalid state is detectable and should at least cause the production of an exception message to the appropriate party.
In the case of the security breach case described in the SANS newsletter, invalid state transitions include:
The JavaScript file was modified by a means which is not included in that used to modify this file in the operations of the host organization.
The code of the modified JavaScript file produces user visible content not in the design which instructs the user to visit a page not in the designed URL set of the online application.
This content, a fake error page, instructs them to install a browser update that turns out to be a remote access Trojan. The input from the user in this invalid state is also itself not in the design of the software this page appears to have been produced by.
With user input allowing installation, the browser's internal state is violated by installation of an extension which allows remote monitoring. According the browser sand-boxing rules, a web page is allowed to connect to one server and one server only, the particular server that is was downloaded from, which is identified by a particular IP address and port number. Any time an external link is clicked, a separate session with a separate server is should be constructed, and the two separate sessions should not be permitted to communicate with each other. In theory, they are encapsulated with no “surface area” between them. Monitoring requires communication between sessions, a system behavior which is not allowed in the definition of "browser sand-box." Communication with any other server for monitoring simply should not happen.
It is obvious that multiple invalid states were introduced to accomplish this modification of the information system's behavior. If a correct and sufficiently complete model of the system's behavior existed and was used as a comparison while monitoring the deployed system's behavior, defined as it's sequence of state changes determined by input events, all of the illegal states could have been detected. Developers do frequently build in monitoring and state integrity checking techniques into their programs, type checking of arguments passed to methods being one simple form included in the definition of the Java Programming Language. Semantic checking of the contents of related information entities is more powerful but more difficult, and therefore is less frequently done. These pale in contrast to the power of checking a resulting state any time a unit of input is processed for validity. This is a DFA based technique and will detect erroneous behavior in real time, generally before any real damage results. It is based on computer science foundations which are not hard to grasp, and yet it is not generally taught or required in the College level computer science curricula.
One primary method hackers use to accomplish their goals and to evade detection is to use unmonitored mutability of the data storage of the information system to alter system behavior. One example on the Linux operating system is the plethora of user alterable configuration files, and this is just the most obvious. A single altered value in storage, especially of a configuration setting, can cause a program or system level threads to choose a hacker's goal rather that the designer's. The state which controls the application of legal state change logic itself is changed, and no error is detected until many steps down the stream of information processing done routinely every day.
Security using DFA theory as its basis therefore requires that as much information as possible stored on a storage device, and especially that which affects system software behavior, be made immutable, which means read-only, and only by its owner. 99% of files in the user's space in a bootable partition will never change, and yet the default access rights allow modification by the owner user and their groups. Probably 90% of all storage referenced in a program never changes after it is initialized. I know because I have checked my own coding designs which I create with my very standard training. Again, immutability is not taught as a security goal, or better, requirement, in software development curricula, and would not restrict the programmer’s design liberty in the least if it was. The user can still protect their files in this context by restricting their access rights to read-only by the owner only, and can further protect their files against successful malware attacks with hashed indexing and archiving.
Another interesting entry in the SANS newsletter email I received reads:
‘Why are security leaders betting on automation? According to a new study, 80% of organizations indicated that they plan to increase Cybersecurity automation investments in 2023. Automation can help fill SOC talent gaps, mitigate business and technology risks, and lead to financial gains. Ready to automate? Get our Buyer’s Guide for Intelligent Security Automation.’
Hopefully this indicates that there is a growing market for application of foundational computer science along with an ounce of common sense to design of information technology products.