Anatomy of an Attack

Example of a script attack on web application server

During a two minute period a mass of requests were sent to a server of the Secrets web application. This rapidity is not consistent with accessing the site with a normal application. Also, the requests were of substantial variety but none of them were consistent with paths to correctly access the application. It seems that some of the paths were attempts to retrieve data that would assist in further penetration into the server ecosystem. Also, unlike a browser, subsequent requests did not include a cookie that was sent so as to establish a session between the requestor and the service. And, some of the behavior was closing the socket before substantial interaction was achieved. All is behavior inconsistent with a genuine enduser and normal request methods.

Location

The IP address of the machine used to perpetrate the attacks was 34.158.36.72. The location of this address can be researched at sites like ipinfo.com which maintains a database of information about each IP address in the world. Asking them for information for this address revealed the machine is hosted in Singapore as shown in the initial graphic.

Requests

About 100 requests were sent. They were varied in their paths. Some examples are "/etc/passwd", "/app/.env", "/media../.env", "/wp-config.php.old", and "/.npmrc". It can be discerned that they are trying to gain important information about the application server. But, the server that they contacted will only serve back pages that have been properly addressed and are part of the application.

Response

The server analyzes the incoming request. It first tries to establish a session so that ongoing communications will have context. It does this with return of a cookie that is a JWT. A JWT ensures timeliness and authenticity of the requestor. But, this requestor did NOT adopt the cookie and resend it with subsequent requests. So, the server knows instantly that it is not dealing with a standard genuine enduser. After a few failed attempts to establish this context with the enduser, the server stops returning data and fast fails subsequent requests. But, requests keep coming about 100 times and so they are logged for analysis.

Logs

As handling of requests proceeds, logs are written to files and a database. This information is meant to help identifying and locating code for any flaws that might exist in the application. They also help determine how handling of attacks is being handled. In the logs, the timestamp is recorded. The location the logging code is identified by 'severity'. Some textual information is formatted and included. Finally, the IP address of the requestor is recorded. During this attack a total of 472 logs were written. The first 46 are depicted in the following graphic showing how things proceed until the address is flagged.

Impact

The server had to handle 100 requests in two minutes. This flood, if continued, would stop the server's ability to handle other enduser's requests thus denying them service, ie DOS. Ignoring them mitigates this negative consequence. But, due to the messy nature of the requests, many sockets closed by the attacker before a request could make progress, some sockets on the server side didn't close normally. They had to be rehandled by corrective logic. If they weren't eventually handled, the server would run out of sockets to respond to other endusers, causing another form of DOS. There are 472 rows of pollution in the database and lines in log files.

Conclusion

A rogue operator running a script can cause some trouble to a web application service if not handled effectively. The attacker runs a script that floods the server with attempts to gain data and/or impede its operation. Identifying such an attack early and filtering out ongoing requests is vital to service opertion. Logging it aids further analysis.