Have you ever seen traffic looking like this against your networK?
The protocol is SIP, the Destination Port is 5060, UDP, it's a Request. From what?
If you look at the UDP Stream you'll see more details.
In the stream you see key information like 'From: "sipvicious"', User-Agent: friendly-scanner, etc
My understanding is that this is essentially the script-kiddie version of VoIP hacking. sipvicious is a tool (watch this video) where you can scan a network for VoIP servers and then try to brute-force authenticate into them and wreak havoc. If SIP is setup poorly or insecurely, you could have big problems from sipvicious.
Why care? If you're the good guy then you need to know about tools like this if you're supporting VoIP / SIP so that you can protect against it and secure it.
General reminder that this demonstration was for educational and awareness purposes and should not be used for malicious activities.
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Monday, October 12, 2015
SIP (VoIP) Packets from sipvicious
Labels:
5060,
friendly-scanner,
SIP,
sipvicious,
VoIP
Finding Windows Files that Changed
Many times in the information security world it's necessary to see what files changed on a system. One possible way to do that is comparing the hashes of files (SHA1, MD5, etc.) before and after the incident. One tool that could accomplish this is the free Microsoft File Checksum Integrity Verifier
It starts with a baseline. So you'll need to have run this against a clean image originally. To do so run it against a folder of your choosing (or the entire C:\ drive for that matter). Notice in the command below you choose what file types you want to look for (instead of just doing every file).
fciv.exe -xml hashdb-original.xml -r c:\windows\temp\SuspiciousFiles -type *.dll -type *.zip -type *.png
Let's say in this folder there were originally 3 untouched files
Now the malware touched 1 of them and compromised it's integrity
Let's say in this folder there were originally 3 untouched files Then after an incident run this command to compare the original hashdb against the current state of the system. As you see below it identified the change, original hash and new hash.
fciv.exe -xml hashdb-original.xml -v -bp c:\windows\temp\SuspiciousFiles
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.
It starts with a baseline. So you'll need to have run this against a clean image originally. To do so run it against a folder of your choosing (or the entire C:\ drive for that matter). Notice in the command below you choose what file types you want to look for (instead of just doing every file).
fciv.exe -xml hashdb-original.xml -r c:\windows\temp\SuspiciousFiles -type *.dll -type *.zip -type *.png
Let's say in this folder there were originally 3 untouched files
Now the malware touched 1 of them and compromised it's integrity
Let's say in this folder there were originally 3 untouched files Then after an incident run this command to compare the original hashdb against the current state of the system. As you see below it identified the change, original hash and new hash.
fciv.exe -xml hashdb-original.xml -v -bp c:\windows\temp\SuspiciousFiles
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Find Hidden Website Folders
Here's a simple tool that can find Hidden/Common Website Folders that might not have a link directly to them from the main page.
Download a brute force website scanner like dirs3arch
Run it against an ASP website
python.exe dirs3arch.py -u mywebsitethatiownandcontrol.com -e asp
Or Run it against a PHP website
python.exe dirs3arch.py -u mywebsitethatiownandcontrol.com -e php
Watch as it discovers several pages that may or may not be of interest
Why might this be useful? Well, if you're a bad guy you probably want to know if there's administrator pages hidden, or you can use this to determine based on the existance of certain folders what Operating System, Web Environment, Programming Service, Version, etc. it's running so you know how to target it. If you're a good guy (like us) then you want to know what the bad guy's going to find so you can secure it and properly protect your website.
General reminder that this demonstration was for educational and awareness purposes and should not be used for malicious activities.
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Download a brute force website scanner like dirs3arch
Run it against an ASP website
python.exe dirs3arch.py -u mywebsitethatiownandcontrol.com -e asp
Or Run it against a PHP website
python.exe dirs3arch.py -u mywebsitethatiownandcontrol.com -e php
Watch as it discovers several pages that may or may not be of interest
Why might this be useful? Well, if you're a bad guy you probably want to know if there's administrator pages hidden, or you can use this to determine based on the existance of certain folders what Operating System, Web Environment, Programming Service, Version, etc. it's running so you know how to target it. If you're a good guy (like us) then you want to know what the bad guy's going to find so you can secure it and properly protect your website.
General reminder that this demonstration was for educational and awareness purposes and should not be used for malicious activities.
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Entropy - Encryption, Compression, etc.
Entropy in computer science can be as simple as counting how many times each character appears in a file. If the file is written in plain English sentences, there are predictable percentages for which certain letters will appear. For example the letter 'e' will appear way more often than the letter 'z' when viewing a written piece of work. Now what gets interesting is that you can use tools to calculate entropy and also be able to determine whether a file is for example compressed, or even encrypted. How? Let's see.
Download an entropy calculating tool such as binwalk
Run that tool against a file
binwalk -E
Notice in the example below that the entropy is pretty flat, but has consistent deviations. It's a fare assumption to make that this file might be compressed because of that layout seen. Actually this file was a '.zip' compressed file.
Notice in the example below that the entropy is pretty flat, flatter than the previous. It's a fare assumption to make that this file might be encrypted because of that layout seen. Actually this file was a '.gpg' encrypted file.
Notice in the example below that the entropy is all over, no flatness at all. It's a fare assumption that this is not encrypted or compressed, but instead some more standard file or text. Actually this file was '.bmp' image file.
Finally notice in the example below that the entropy is also all over, no flatness at all. It's a fare assumption that this is not encrypted or compressed, but instead some more standard file or text. Actually this file was '.html' web page with the text from a story.
Why is this useful? In computer science, and especially in the information security realm, you run across unknown data all the time. It becomes very helpful then to learn whether that data is perhaps encrypted, or compressed, so that you can make attempts to reverse engineer it and get back to the original malicious content.
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Download an entropy calculating tool such as binwalk
Run that tool against a file
binwalk -E
Notice in the example below that the entropy is pretty flat, but has consistent deviations. It's a fare assumption to make that this file might be compressed because of that layout seen. Actually this file was a '.zip' compressed file.
Notice in the example below that the entropy is pretty flat, flatter than the previous. It's a fare assumption to make that this file might be encrypted because of that layout seen. Actually this file was a '.gpg' encrypted file.
Notice in the example below that the entropy is all over, no flatness at all. It's a fare assumption that this is not encrypted or compressed, but instead some more standard file or text. Actually this file was '.bmp' image file.
Finally notice in the example below that the entropy is also all over, no flatness at all. It's a fare assumption that this is not encrypted or compressed, but instead some more standard file or text. Actually this file was '.html' web page with the text from a story.
Why is this useful? In computer science, and especially in the information security realm, you run across unknown data all the time. It becomes very helpful then to learn whether that data is perhaps encrypted, or compressed, so that you can make attempts to reverse engineer it and get back to the original malicious content.
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Memory Dump Collection & Analysis
Here is a quick run-down of basic Memory Dump collection and analysis on a Windows 7 machine.
First download a memory dump tool like DumpIt.
Then generate a memory dump by running the tool against the desired machine.
DumpIt.exe
Move the memory dump to your analysis vm.
Determine what Image type you're going to use.
python.exe vol.py imageinfo -f WIN7-20151012-174426.raw
Run queries against the dump like "pslist" (process list)
python.exe vol.py --profile=Win7SP0x86 -f WIN7-20151012-174426.raw pslist
"pstree" (process tree)
python.exe vol.py --profile=Win7SP0x86 -f WIN7-20151012-174426.raw pstree
"netscan" (connections)
python.exe vol.py --profile=Win7SP0x86 -f WIN7-20151012-174426.raw netscan
Find all registry hives and query one for a key
python.exe vol.py --profile=Win7SP0x86 -f WIN7-20151012-174426.raw hivelist
python.exe vol.py --profile=Win7SP0x86 -f WIN7-20151012-174426.raw printkey -o 0x90839008 -K "Google\Update"
Find all the amazing volatility commands here!
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.
First download a memory dump tool like DumpIt.
Then generate a memory dump by running the tool against the desired machine.
DumpIt.exe
Move the memory dump to your analysis vm.
Determine what Image type you're going to use.
python.exe vol.py imageinfo -f WIN7-20151012-174426.raw
Run queries against the dump like "pslist" (process list)
python.exe vol.py --profile=Win7SP0x86 -f WIN7-20151012-174426.raw pslist
"pstree" (process tree)
python.exe vol.py --profile=Win7SP0x86 -f WIN7-20151012-174426.raw pstree
"netscan" (connections)
python.exe vol.py --profile=Win7SP0x86 -f WIN7-20151012-174426.raw netscan
Find all registry hives and query one for a key
python.exe vol.py --profile=Win7SP0x86 -f WIN7-20151012-174426.raw hivelist
python.exe vol.py --profile=Win7SP0x86 -f WIN7-20151012-174426.raw printkey -o 0x90839008 -K "Google\Update"
Find all the amazing volatility commands here!
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Thursday, September 24, 2015
The Intranet of things
The "intranet" of things is real, it's here, beware!
Why am I saying intranet and not internet?
Read this Krebs Target article.. The best and scariest quote is "able to communicate directly with cash registers in checkout lanes after compromising a deli meat scale located in a different store"
Uh-oh!
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Why am I saying intranet and not internet?
Read this Krebs Target article.. The best and scariest quote is "able to communicate directly with cash registers in checkout lanes after compromising a deli meat scale located in a different store"
Uh-oh!
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.
TLS Best Practices Guide Summary
The TLS Deployment Best Practices from SSL Labs is a good read. Thought it might be good to summarize some of it.
Private Key Strength - In order of strength it's 1024bit RSA (low, should be replaced) , then 2048bit RSA ( should be safe for a while ) , and then 256bit ECDSA (best right now if you have support).
Private Key Protection - Guard it with your life, password protect, minimal access, and revoke if compromised.
Private Key Source - Get your keys from a reputable large CA that has strong security posture and services available like simple revocation.
Hash Function - SHA1 is week and should be replaced immediately, SHA2 is the current standard as long as your users can support it.
Protocols - SSL (v2 and v3) are considered broken and should not be used. TLS v1.0 is considered but v1.1 and v1.2 have their advantages that will soon lead to the decom of v1.0
Cipher Suites - You should only be using suites with 128bit encryption or stronger. Also not Anon key exchange suites provide no authentication, NULL suites provide no encryption, Export key exchanges are broken and should not be used, and RC4 is broken and should not be used.
Cipher Suite Selection - Clients submit a list of supported suites and the server chooses one. Having the suites ordered by strength on the server is important so the highest security available is utilized.
Forward Secrecy - This is a feature that makes TLS not use the server's private key but instead a different key each time. The benefit is that if the server's key is compromised, historical traffic cannot be decrypted because the key was not the same.
Renegotiation - It's ok for a Server to initiate a re-negotiation of TLS settings, but there is no reason a Client should. Thus configure the server to ignore Client re-negotiation requests.
TLS & HTTP Compression - They're insecure and most clients don't support TLS Compression, so disable it.
Mixed Content and HSTS - Avoid mixed content of HTTP and HTTPS. Go all or nothing to HTTPS. Otherwise it leads to user confusion, mis-trust, and also some known vulnerabilities related to mixes. Use HSTS (Strict Transport) which tells the browser your site is only ever HTTPS.
Cookies - Cookies must be secured properly by the developer or else it can render your HTTPS ineffective in protecting session and other sensitive information.
EV Certs - You can go one step beyond and get an Extended Verification certificate which goes through extra tests and is harder to forge.
Public Key Pinning - Another above and beyond step that specifies which CAs can issue certificates for your websites.
ECDSA Certs - Elliptical curve certificates provider more strength from smaller key sets which increases performance.
Validate your settings - Run re-occuring tests like ssl labs to ensure your settings are secure.
Keep in mind this information is accurate as of the Dec 2014 publishing of the best practice guide and new information may have surfaced since then that changes some of these stances.
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Private Key Strength - In order of strength it's 1024bit RSA (low, should be replaced) , then 2048bit RSA ( should be safe for a while ) , and then 256bit ECDSA (best right now if you have support).
Private Key Protection - Guard it with your life, password protect, minimal access, and revoke if compromised.
Private Key Source - Get your keys from a reputable large CA that has strong security posture and services available like simple revocation.
Hash Function - SHA1 is week and should be replaced immediately, SHA2 is the current standard as long as your users can support it.
Protocols - SSL (v2 and v3) are considered broken and should not be used. TLS v1.0 is considered but v1.1 and v1.2 have their advantages that will soon lead to the decom of v1.0
Cipher Suites - You should only be using suites with 128bit encryption or stronger. Also not Anon key exchange suites provide no authentication, NULL suites provide no encryption, Export key exchanges are broken and should not be used, and RC4 is broken and should not be used.
Cipher Suite Selection - Clients submit a list of supported suites and the server chooses one. Having the suites ordered by strength on the server is important so the highest security available is utilized.
Forward Secrecy - This is a feature that makes TLS not use the server's private key but instead a different key each time. The benefit is that if the server's key is compromised, historical traffic cannot be decrypted because the key was not the same.
Renegotiation - It's ok for a Server to initiate a re-negotiation of TLS settings, but there is no reason a Client should. Thus configure the server to ignore Client re-negotiation requests.
TLS & HTTP Compression - They're insecure and most clients don't support TLS Compression, so disable it.
Mixed Content and HSTS - Avoid mixed content of HTTP and HTTPS. Go all or nothing to HTTPS. Otherwise it leads to user confusion, mis-trust, and also some known vulnerabilities related to mixes. Use HSTS (Strict Transport) which tells the browser your site is only ever HTTPS.
Cookies - Cookies must be secured properly by the developer or else it can render your HTTPS ineffective in protecting session and other sensitive information.
EV Certs - You can go one step beyond and get an Extended Verification certificate which goes through extra tests and is harder to forge.
Public Key Pinning - Another above and beyond step that specifies which CAs can issue certificates for your websites.
ECDSA Certs - Elliptical curve certificates provider more strength from smaller key sets which increases performance.
Validate your settings - Run re-occuring tests like ssl labs to ensure your settings are secure.
Keep in mind this information is accurate as of the Dec 2014 publishing of the best practice guide and new information may have surfaced since then that changes some of these stances.
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Subscribe to:
Posts (Atom)