What would you do to get to Shmoo?
Woke up at 4:00 AM
2.5 hours shovelling snow
1 hour to get to train station
1 hour on local commuter rail to BOS
2 minutes to find my train to PVD cancelled
1 hour on on first commuter rail to PVD
Finding my 12:50 train to DC only five minutes late = priceless
In about four hours I will be at Shmoocon and it will to be Epic. This years schedule contains a lot of fresh blood and new faces (which is not a bad thing IMHO). The schedule is so packed with goodness, that I am going to have to make some tough decisions on which sessions to attend. In addition, the after hours action is packed full of awesomesauce. There is the return of Firetalks on both Friday and Saturday evening, Podcasters meetup (including free booze), Jason Scott is previewing his new documentary called Get Lamp on Saturday evening (first computer program I wrote was a text based Adventure game on my TI99-4A), and of course there are the parties and meet-ups that will certainly include scotch and cigars.
On Friday we begin with, Gone in 60 Minutes: Stealing Sensitive Data from Thousands of Systems Simultaneously with OpenDLP with Andrew Gavin. Leveraging enterprise defense products = sexy in my book. Following that there are several cool sessions including a long awaited update from Johnny Long (who is back in the states for the con), and keynote by Peiter "Mudge" Zatko of DARPA.
On Saturday, I am hoping that Jon Oberheide and Zach Lanier has the cure for my much anticipated hangover with their talk; TEAM JOCH vs. Android: The Ultimate Showdown which will highlight their work on subverting the Android OS. I plan to follow-up with Hard Drive Paperweight: Recovery from a Seized Motor! being delivered by Scott Moulton. Scott is a super smart dude who never disappoints. I am guaranteed to learn something there.
Printers Gone Wild! with Ben Smith is in the next slot. Next I need to make some of those tough decisions I mentioned earlier. There is Attacking 3G and 4G mobile telecommunications networks with Enno Rey & Daniel Mende and An Evite from Surbo? Probably an invitation for trouble with Trent Lo aka "Surbo" from i-hacked.comhttp://www.i-hacked.com/. There is no doubt that mobile tech has definetly come of age and consequently will become a target but Trent is also a smart, entertaining dude. Then in at 16:00 there is Defeating mTANs for profit with Axelle Apvrille and Kyle Yang (mTAN = one-time bank password by SMS) and G W Ray Davidson's talk on designing a network for a conferance entitled ShmooCon Labs Goes To College. Both decisions will most likely be down to the wire. On Sunday, the talk that seems to be on averyone's agenda is Georgia Weidman's Transparent Botnet Control for Smartphones Over SMS in which she will release POC for a sms controlled botnet.
Total estimated time to get to the con = 15 hours (and worth it). See you in a few hours Shmoocon
Showing posts with label hacking. Show all posts
Showing posts with label hacking. Show all posts
Thursday, January 27, 2011
Thursday, December 23, 2010
The More Things Change The More They Stay The Same: Reading "The Cuckoo's Egg"
I just finished reading The Cuckoo's Egg: Tracking a Spy Through the Maze of Computer Espionage by Cliff Stoll. The book is based on the true account of Cliff Stoll's experience tracking a hacker through a laboratory computer network at Berkeley in the mid 1980's. The author quickly finds himself in a year long obsession that involved military targets, several US government agencies, and law enforcement from multiple continents.
The story completely sucked me in. The amazing part is more than 25 years later, with the exception of bandwidth and the shear number of targets, not much has really changed. Detective book fans will enjoy it. Security geeks will love it. Incident Responders should be required to read it.
Wednesday, October 13, 2010
Hacking a Fix
There have been many discussions, rants, and commentary on what it means to be a hacker. Many of us in the security community use the term in its original intended use and despise the way the media and popular culture portrays it. Hacking to many of us is about learning and using that knowledge to make improvements upon software and hardware. I have previously posted about the resourcefulness of people that define themselves as hackers. My coding skills are certainly not L337 and I am certainly not dropping 0-day but what I am very skilled at is understanding technical issues and finding unique solutions to them. This post is on one such issue and my obsession to fix it.
The Backstory
I recently exchanged emails with APC support on their use of a self signed certificate for SSL access to the web management interface of Powerchute Network Shutdown (PCNS). Powerchute Network Shutdown is used in conjunction with APC Universal Power Supplies (UPS). The product is used to manage and shutdown servers during power issues and outages. The most recent release is version 2.2.4.
In previous releases, APC did not support SSL for remote access to the web interface of PCNS. Although the current version now defaults to https, it only supports the use of a self signed certificate provided by APC. The risks of self signed certificates are well recognized. Such configurations can make a Man-in-the-Middle attack on an https session trivial.
While using a firewall to limit access to the web application or disabling the web service are certainly viable options in some environments, it may not be in others. Since I have a lot of free time during my commute and I tend to obsess about such things, I decided the fix the issue myself.
Poking the Source Code
By default APC PCNS can be found in the C:\Program Files\APC\PowerChute\group1 directory of a Windows system. The software is also available for several *nix distros, so consult the documentation as needed. The web server runs on port 6547 and is hosted on Jetty (Version 6.0.0). By default, version 1.5.0.18 of the Java Runtime Environment (JRE) is installed in C:\Program Files\AP\jre\jre1.5.0_18 directory.
Although this version of JRE has had its share of vulnerabilities, that is not the focus of this post (although if your reading this APC you may want to consider updating your shit).
I began by decompiling the .jar files associated with the application with Java Decompiler by Emmanuel Dupuy. A nice feature of Java Decompiler is its search capabilities. This is very useful to find what you’re looking for quickly or in my case stumble through the source code awkwardly. I quickly located the WebServerSettings class in the webServer.jar file.
Yes that is the password to the Java keystore hardcoded. Convenient isn’t it?
Certificate Management Hell
So using this newly obtained password we can view the current self signed certificate within the Java keystore with keytool utility included with the runtime environment.
Once found, I removed the current keystore entry, generated a new one, and created a csr for submission to my CA.
After, installation, you must restart the PCNS1 service. Once restarted you can now enjoy your new, shiny, valid certificate. You may also want to consider changing the keystore password. While this is trivial to do using the keytool utility, the webserver.jar file will need to be altered to reflect the change and then recompiled using the JDK. For this reason, most of the Java development forums I read noted that hard coding the password is not practical. From a security perspective, no matter where the password is stored, you must trust the system storing it. Although I would suspect using the same static password across multiple independent systems is not ideal. If you have experience with the development and security of such systems I am interested in hearing your thoughts on this.
The "R" Word
So what is the Risk? As I mentioned earlier, using a self signed certificate is risky in regards to Man-In-The-Middle attacks. Users tend to ignore certificate warnings. Moreover, it is very feasible to pass a victim the legitimate self signed certificate during an attack. Consequently, the use of a self signed certificate is not providing much protection except against passive sniffing. If the web session to APC PCNS is hijacked, then the credentials to the application could become compromised. Once access is gained, one obvious scenario would be a Denial of Service (DOS) attack by shutting down the systems controlled by the application. I wanted to find something a bit more nefarious, however. It so happens that PCNS allows administrators to not only shutdown systems when events are triggered but also run command files.
Note that the command file does not need to be located on the server being attacked. It also should be noted that if running multiple executables from a command file, the following syntax needs to be followed due to a bug in the current release (thank you readme.txt). Note: quotes are only needed if the path contains spaces.
The Backstory
I recently exchanged emails with APC support on their use of a self signed certificate for SSL access to the web management interface of Powerchute Network Shutdown (PCNS). Powerchute Network Shutdown is used in conjunction with APC Universal Power Supplies (UPS). The product is used to manage and shutdown servers during power issues and outages. The most recent release is version 2.2.4.
In previous releases, APC did not support SSL for remote access to the web interface of PCNS. Although the current version now defaults to https, it only supports the use of a self signed certificate provided by APC. The risks of self signed certificates are well recognized. Such configurations can make a Man-in-the-Middle attack on an https session trivial.
While using a firewall to limit access to the web application or disabling the web service are certainly viable options in some environments, it may not be in others. Since I have a lot of free time during my commute and I tend to obsess about such things, I decided the fix the issue myself.
Poking the Source Code
By default APC PCNS can be found in the C:\Program Files\APC\PowerChute\group1 directory of a Windows system. The software is also available for several *nix distros, so consult the documentation as needed. The web server runs on port 6547 and is hosted on Jetty (Version 6.0.0). By default, version 1.5.0.18 of the Java Runtime Environment (JRE) is installed in C:\Program Files\AP\jre\jre1.5.0_18 directory.
Although this version of JRE has had its share of vulnerabilities, that is not the focus of this post (although if your reading this APC you may want to consider updating your shit).
I began by decompiling the .jar files associated with the application with Java Decompiler by Emmanuel Dupuy. A nice feature of Java Decompiler is its search capabilities. This is very useful to find what you’re looking for quickly or in my case stumble through the source code awkwardly. I quickly located the WebServerSettings class in the webServer.jar file.
Yes that is the password to the Java keystore hardcoded. Convenient isn’t it?
Certificate Management Hell
So using this newly obtained password we can view the current self signed certificate within the Java keystore with keytool utility included with the runtime environment.
>keytool -list -v -keystore "C:\Program Files\APC\PowerChute\group1\keystore"
Once found, I removed the current keystore entry, generated a new one, and created a csr for submission to my CA.
>keytool -delete -alias securekey -keystore "C:\Program Files\APC\PowerChute\group1\keystore"Please note the following are the default values for the keytool -genkey option. You may want to change these to suit your requirements.
>keytool -genkey -alias securekey -keystore "C:\Program Files\APC\PowerChute\group1\keystore" -dname CN=win7.securitybraindump.com,OU=Infosec,O=SecurityBraindump,L=Boston,S=Massachusetts,C=US"
>keytool -certreq -alias securekey -keystore "C:\Program Files\APC\PowerChute\group1\keystore" -file securekey.csr
-keyalg "DSA"For the purposes of this post I used a Windows 2003 CA (yes that is as ugly as it sounds but it is what I had readily had available at the time). To submit the csr to the CA, obtain my certificate, and export the CA Root certificate (for the chain) I used certreq.
-keysize 1024
-validity 90
-sigalg (Depends on the key algorithm chosen.) If the private key is "DSA", -sigalg defaults to "SHA1withDSA" or if "RSA", the default is "MD5withRSA".
>certreq -Submit -attrib "CertificateTemplate: WebServer" securekey.csr securekey.cerThe base-64 certificates can then be imported into the keystore using the -import option.
>certutil -ca.cert rootca.cer
>keytool -import -trustcacerts -v -alias rootca -file rootca.cer -keystore "C:\Program Files\APC\PowerChute\group1\keystore"Once imported, verification can be accomplished by using the keytool -list option again.
>keytool -import -v -alias securekey -file securekey.cer -keystore "C:\Program Files\APC\PowerChute\group1\keystore"
After, installation, you must restart the PCNS1 service. Once restarted you can now enjoy your new, shiny, valid certificate. You may also want to consider changing the keystore password. While this is trivial to do using the keytool utility, the webserver.jar file will need to be altered to reflect the change and then recompiled using the JDK. For this reason, most of the Java development forums I read noted that hard coding the password is not practical. From a security perspective, no matter where the password is stored, you must trust the system storing it. Although I would suspect using the same static password across multiple independent systems is not ideal. If you have experience with the development and security of such systems I am interested in hearing your thoughts on this.
The "R" Word
So what is the Risk? As I mentioned earlier, using a self signed certificate is risky in regards to Man-In-The-Middle attacks. Users tend to ignore certificate warnings. Moreover, it is very feasible to pass a victim the legitimate self signed certificate during an attack. Consequently, the use of a self signed certificate is not providing much protection except against passive sniffing. If the web session to APC PCNS is hijacked, then the credentials to the application could become compromised. Once access is gained, one obvious scenario would be a Denial of Service (DOS) attack by shutting down the systems controlled by the application. I wanted to find something a bit more nefarious, however. It so happens that PCNS allows administrators to not only shutdown systems when events are triggered but also run command files.
Note that the command file does not need to be located on the server being attacked. It also should be noted that if running multiple executables from a command file, the following syntax needs to be followed due to a bug in the current release (thank you readme.txt). Note: quotes are only needed if the path contains spaces.
@START "some path\evil.exe" argumentsI'll let the output from my evil.cmd file containing the "whoami > whoami.txt" command speak for itself;
@START "some otherpath\pwn.exe" arguments
nt authority\systemNUM! Happy Hunting!
Tuesday, June 29, 2010
Firefox Add-ons FTW!
Just a quick post on passwords saved in the browser. After my post on credentials stored in the Windows 7 Vault, I started to think about browser passwords and the risks that lurk there. Chris Gates had a similar thought which he posted about yesterday, and Larry Pesce wrote up a detailed analysis last September.
I personally disable this feature in Firefox but a strong master password would certainly be advisable if you do save passwords within Firefox. While I do not use this feature, I do use a lot of Firefox add-on's. Gmail Notifier, Xmarks Bookmarks, and Echofon Twitter add-on's to name a few. So I naturally turned my attention to those.
I pondered where these add-on's were storing saved credentials. The answer is in same place Firefox stores them. What a more ironic way to verify this than to use a Firefox add-on (SQLLite Manager) to query the signons.sqlite database.
As previously covered by Gates and Pesce, conversion of the encrypted passwords is trivial as long as you also have access to the key3.db and there is no master password configured. If you are interested in the details of this, I suggest checking out the documentation here and tool available here.
While this may have been obvious to others, it was not to me. That is one of the many reasons I love this field.
Update August 09, 2010: Jeremiah Grossman presented his work entitled Breaking Browsers: Hacking Auto-Complete at Black Hat last week. The presentation included examples of using XSS to steal saved credentials in the Firefox and Chrome password managers.
I personally disable this feature in Firefox but a strong master password would certainly be advisable if you do save passwords within Firefox. While I do not use this feature, I do use a lot of Firefox add-on's. Gmail Notifier, Xmarks Bookmarks, and Echofon Twitter add-on's to name a few. So I naturally turned my attention to those.
I pondered where these add-on's were storing saved credentials. The answer is in same place Firefox stores them. What a more ironic way to verify this than to use a Firefox add-on (SQLLite Manager) to query the signons.sqlite database.
As previously covered by Gates and Pesce, conversion of the encrypted passwords is trivial as long as you also have access to the key3.db and there is no master password configured. If you are interested in the details of this, I suggest checking out the documentation here and tool available here.
While this may have been obvious to others, it was not to me. That is one of the many reasons I love this field.
Update August 09, 2010: Jeremiah Grossman presented his work entitled Breaking Browsers: Hacking Auto-Complete at Black Hat last week. The presentation included examples of using XSS to steal saved credentials in the Firefox and Chrome password managers.
Wednesday, June 16, 2010
Post Exploitation Pivoting with the Windows 7 Vault
I have been poking around with the updated version of Credential Manager in Windows 7 which has been commonly referred to as "Stored User Names and Passwords" in previous version of Windows. Much like its predecessors, the current version of Credential Manager still uses Data Protection API (DPAPI), but Windows 7 now stores saved credentials within the Windows Vault. Such credentials can include; user names and passwords used to log on to network shares, websites that use Windows Integrated Authentication, Terminal Services, and many third party applications such as Google Talk .
Credential Manager and DPAPI has been under scrutiny in the past. Cain & Able has had a decoder for some time. More recently, researchers from Standford University presented at Black Hat DC 2010 about their DPAPI research.
While breaking the crypto associated with this feature might be useful (i.e. if credentials are re-used elsewhere), it is not always necessary. The purpose of the Credential Manager is to pass saved credentials to resources commonly accessed by the user. Once you have gained access to a host as the unprivileged user (take you pick of code execution bugs, Adobe pdf's seem to be popular these days), then you can certainly leverage this feature to pivot to resources referenced within the Windows Vault. Keeping a low forensics profile would be preferred, so I attempted to find existing command line tools that were already available on the host. After poking at Windows 7 for a while, I found an undocumented utility called vaultcmd.exe in the System32 folder that appeared useful. The following is the output of the supported switches for vaultcmd;
The /list switch allows us to view all Windows Vaults available on the host for the current authenticated user.
It appears in this example, the two default Vaults are the only ones that exist on this host. Also note that since the user is already authenticated, the vaults are in an unlocked state. Running the /listproperties switch against each vault lists some more details, including the number of credentials saved in each location.
Finally, the /listcreds switch gives us our newly found targets.
It appears, our unprivileged user has stored domain administrator credentials for two domain controllers. While this is certainly more secure than running as domain administrator locally, DPAPI adds no added security in this scenario since local access to this host has been gained. Now that we have completed our reconnaissance, we can pivot and access the servers by simply using the installed tools at our disposal. In the following example, I use psexec and the SET command to verify I have domain administrator access to DC-01 without having to specify a user name and password.
I was also able to access the the domain controller's Admin shares via the NET USE command using stored credentials within the Windows Vault.
net use P: \\dc-01\C$In addition, since the Windows Server Administrator tools were also already installed on the host, I also verified that the Windows Vault was passing these credentials to Active Directory Users and Computers and the Remote Desktops Client.
I attempted to change some of the default settings for the vault using the /setproperties switch. For Example; it appears that vaultcmd has the ability to set a password on a vault;
vaultcmd /setproperties:"Windows Vault" /set:AddProtection /value:PasswordBut any attempt I made was met with the error; "The request is not supported.". So I would be interested to see if anyone can find additional documentation on this utility or the Windows Vault. I have not been successful in finding anything to date.
vaultcmd /setproperties:"Windows Vault" /set:DefaultProtection /value:Password
Some have suggested that any password management tool that hooks into the browser or operating system is more of a risk than a stand alone application that requires additional authentication mechanisms. While I generally agree with this, the emerging capabilities of attack and forensic tools that acquire volatile memory from a host (and consequently decrypted credentials), only require a bit more patience. Of course such tools, must be loaded on the compromised host increasing the forensic footprint the intruder leaves behind.
Happy Hunting!
Monday, May 3, 2010
Why Hackers make the Best IT Support Professionals
This is a thought that I have had brewing for some time and I will attempt to not rant too much. Throughout my IT career, I have been watching many IT Support professionals immediately go for a quick fix to technology issues. This is not to say a quick fix isn’t always warranted. The constant barrage of support issues, end users broad siding you as you attempt to grab lunch, and evolving technology is indeed a challenge. I feel your pain. I've been there, I've done that, and I still do it on a daily basis. The beating support people take can cause even the most saintly to lose his/her patience.
However, I feel the trend of the quick fix, seems to be worsening. In InfoSec, the quick fix is often used in conjunction with FUD (fear, uncertainly, and doubt) to sell those magical products with blinking lights that are going to make the latest attack vectors just magically disappear. The problem with this concept is the same in all subsets of Information Technology, however. How many of us have told colleagues, friends, and family to reboot as a solution to an issue? How many of us have told them to do so more than once for the same issue? See the quick fix is not really a fix at all, it is procrastination.
I like to think that we as IT Professionals, whether desktop support, enterprise architects, coders, or InfoSec pursued our career because we all had the common love of technology. Many of us have the inquisitive nature that would rival any scientist. This makes us all brothers and sisters alike. The inquisitive nature that I felt when powering on my TI99-4A in 1981 is still with me today. This is why I chose this career.
Some of the most inquisitive people I have met while working in IT have been those who have self dubbed themselves "hackers". These are not the "hackers" the media would have you believe are hijacking your wireless and stealing your digital valuables. These are self proclaimed geeks who love computers. They are not always InfoSec professionals. They may work on a helpdesk, as a systems administrator, or at the local Radio Shack. They enjoy taking things apart and putting them back together in ways that improve the technology. See hackers understand the concepts of efficiency and availability. These concepts are the foundation of supporting any business. It is what our employee’s pay us our salaries for, regardless of the subset of IT we may fall under.
Efficiency and availability is not about reboots and resets. It is about getting to the root of an issue, learning from it, and improving the system(s) from what you have learned. So take the time to understand the technology issues you come across. It can be fun and productive. If you are not feeling the love for your technology career of choice, then ask the hacker working at the local Radio Shack if he or she is willing to trade careers with you. I suspect they would jump at the chance.
However, I feel the trend of the quick fix, seems to be worsening. In InfoSec, the quick fix is often used in conjunction with FUD (fear, uncertainly, and doubt) to sell those magical products with blinking lights that are going to make the latest attack vectors just magically disappear. The problem with this concept is the same in all subsets of Information Technology, however. How many of us have told colleagues, friends, and family to reboot as a solution to an issue? How many of us have told them to do so more than once for the same issue? See the quick fix is not really a fix at all, it is procrastination.
I like to think that we as IT Professionals, whether desktop support, enterprise architects, coders, or InfoSec pursued our career because we all had the common love of technology. Many of us have the inquisitive nature that would rival any scientist. This makes us all brothers and sisters alike. The inquisitive nature that I felt when powering on my TI99-4A in 1981 is still with me today. This is why I chose this career.
Some of the most inquisitive people I have met while working in IT have been those who have self dubbed themselves "hackers". These are not the "hackers" the media would have you believe are hijacking your wireless and stealing your digital valuables. These are self proclaimed geeks who love computers. They are not always InfoSec professionals. They may work on a helpdesk, as a systems administrator, or at the local Radio Shack. They enjoy taking things apart and putting them back together in ways that improve the technology. See hackers understand the concepts of efficiency and availability. These concepts are the foundation of supporting any business. It is what our employee’s pay us our salaries for, regardless of the subset of IT we may fall under.
Efficiency and availability is not about reboots and resets. It is about getting to the root of an issue, learning from it, and improving the system(s) from what you have learned. So take the time to understand the technology issues you come across. It can be fun and productive. If you are not feeling the love for your technology career of choice, then ask the hacker working at the local Radio Shack if he or she is willing to trade careers with you. I suspect they would jump at the chance.
More Experiments with Master File Table Timestamps
I had an anonymous comment on my Tampering with Master File Table Records post referencing the Timestomp utility available in Metasploit. Timestomp is an anti-forensics utility used to change the date/time metadata stored in the $Standard_Information Attribute of the Master File Table. I experimented with the utility prior to the previous post but had some issues getting it to run properly on Windows 7. Moreover, Timestomp does not edit the $File_Name Attribute (MACE) values. The commenter does point out and interesting workaround noted on the Timestomp wiki however.
Moving a file post manipulation with Timestomp copies all four of the $Standard_Information Attribute time values to the $File_Name Attribute Attribute values. Once moved, you must change the SI attribute values again. Staying with using the existing tools available on Windows 7, I tested using the Move-Item Cmdlet.
Rob T. Lee also recently posted some research he has been doing on Windows 7 $MFT timestamp entries. His findings to date seem to support the aforementioned behavior. It will be interesting to see what additional behavior he finds. Keep the comments coming!
Moving a file post manipulation with Timestomp copies all four of the $Standard_Information Attribute time values to the $File_Name Attribute Attribute values. Once moved, you must change the SI attribute values again. Staying with using the existing tools available on Windows 7, I tested using the Move-Item Cmdlet.
CD C:\Windows\System32I verified again by carving the $MFT out and using analyzeMFT to parse the contents. The following is the output of the $MFT record for our malicious file verifying that all eight date values have been edited;
New-Item malicious.dll -type file
(get-item malicious.dll).creationtime=$(Get-Date "02/11/10 07:30")
(get-item malicious.dll).lastwritetime=$(Get-Date "02/11/10 07:30")
(get-item malicious.dll).lastaccesstime=$(Get-Date "02/11/10 07:30")
set-date -date 02/11/10
set-date -date 07:30:00
rename-item malicious.dll notmalicious.txt
Move-Item notmalicious.txt C:\Users\Public\
CD C:\Users\Public\
(get-item notmalicious.txt).creationtime=$(Get-Date "02/11/10 07:30")
(get-item notmalicious.txt).lastwritetime=$(Get-Date "02/11/10 07:30")
(get-item notmalicious.txt).lastaccesstime=$(Get-Date "02/11/10 07:30")
Rob T. Lee also recently posted some research he has been doing on Windows 7 $MFT timestamp entries. His findings to date seem to support the aforementioned behavior. It will be interesting to see what additional behavior he finds. Keep the comments coming!
Wednesday, April 7, 2010
Tampering with Master File Table Records
I have been spending some time reading File System Forensic Analysis by Brian Carrier which is considered by many to be the primary resource on the subject of file system forensics. Consequently, I began thinking of ways to tamper with the metadata stored within the Master File Table (MFT) of NTFS formatted drives. In NTFS everything is a file and the MFT stores information on these files. Analyzing the MFT is one way of establishing a forensic timeline of all file and folder changes on the system being investigated.
The MFT file contains a unique record for each file or folder which includes several attributes such as the $Standard_Information Attribute and $File_Name Attribute. Each attribute contains metadata on every file and folder ever created, modified, accessed, or removed within NTFS.
The $Standard_Information Attribute contains metadata which includes the Date/Time values that are commonly referenced by the operating system. These are the values one would see when viewing the properties of a file within explorer.exe on a Windows system. The values are sometimes referred to as M.A.C.E. and include;
The $File_Name Attribute contains the name of the file. In Windows there will usually be entries in both the 8.3 DOS and Win32 naming format. The $File_Name Attribute also contains similar date/time (MACE) values as those found in the Standard Information Attribute. These values often reflect the creation time of the file or folder and do not change frequently. There are exceptions to this which I discuss later in this post.
Since the attribute values stored within the MFT are commonly used for generating a timeline during the analysis of Windows NTFS file systems, I started playing around with manipulating the metadata within it. If one wanted to cover one's tracks by doing so, it would be useful to use tools already available on the operating system. Such tools would ideally not track or log the commands run on the system. Irony is, the Windows PowerShell fits this description and has these capabilities. Dave Hull has noted this on his blog here.
By leveraging the Get-Item cmdlet in PowerShell, one can change some of the metadata within the $Standard_Information attribute and consequently the values shown in the properties of the file. For example;
To verify this change within the MFT, I used FTK Imager Lite to export the $MFT and AnalyzeMFT to parse and export the contents into CSV format. AnalyzeMFT is a free tool based on a commercial tool called MFT Ripper by Mark Menz. Once exported, the CSV file can be opened in your favorite spreadsheet program for easy filtering. The following screen shot shows the MFT record for the malicious.dll after I using the Get-Item cmdlet to change the dates (note the dates are stored in UTC format).
As you can see from the export, the problem with this tactic is the Std Info Entry Date (MFT Entry Modified Time) remains unchanged. Moreover, the FN Info ($File_Name Attribute) Dates also remain unchanged. Interesting enough, renaming the file will change both these values but doing so will change them to the current system time. The only real option I have been able to find is to change the system time prior to renaming. This can be accomplished by using the set-date cmdlet in Power Shell.
Unfortunately, this approach is far from perfect. The MFT Entry Modified Date within the $File_Name Attribute remains unscathed (I have not been able to figure out how to change this). Moreover, by default, a System Informational Event is logged within the Windows Event log of a change to the system time. Note the the date of the event however. There is a similar event logged for the time change.
Published a follow-up post on successfully changing the Entry Modified Date within the $File_Name Attribute thanks to an anonymous tip. The followup can be found here.
The MFT file contains a unique record for each file or folder which includes several attributes such as the $Standard_Information Attribute and $File_Name Attribute. Each attribute contains metadata on every file and folder ever created, modified, accessed, or removed within NTFS.
The $Standard_Information Attribute contains metadata which includes the Date/Time values that are commonly referenced by the operating system. These are the values one would see when viewing the properties of a file within explorer.exe on a Windows system. The values are sometimes referred to as M.A.C.E. and include;
Modified Time: Time the folder or file was last modified
Accessed Time: Time the folder or file was last accessed
Creation Time: Time the folder or file was created
Entry Modified Time: Time the MFT entry of a folder or file was last modified (note: cannot be viewed from Windows explorer)
The $File_Name Attribute contains the name of the file. In Windows there will usually be entries in both the 8.3 DOS and Win32 naming format. The $File_Name Attribute also contains similar date/time (MACE) values as those found in the Standard Information Attribute. These values often reflect the creation time of the file or folder and do not change frequently. There are exceptions to this which I discuss later in this post.
Since the attribute values stored within the MFT are commonly used for generating a timeline during the analysis of Windows NTFS file systems, I started playing around with manipulating the metadata within it. If one wanted to cover one's tracks by doing so, it would be useful to use tools already available on the operating system. Such tools would ideally not track or log the commands run on the system. Irony is, the Windows PowerShell fits this description and has these capabilities. Dave Hull has noted this on his blog here.
By leveraging the Get-Item cmdlet in PowerShell, one can change some of the metadata within the $Standard_Information attribute and consequently the values shown in the properties of the file. For example;
(get-item malicious.dll).creationtime=$(Get-Date "02/11/10 07:30")
(get-item malicious.dll).lastwritetime=$(Get-Date "02/11/10 07:30")
(get-item malicious.dll).lastaccesstime=$(Get-Date "02/11/10 07:30")
To verify this change within the MFT, I used FTK Imager Lite to export the $MFT and AnalyzeMFT to parse and export the contents into CSV format. AnalyzeMFT is a free tool based on a commercial tool called MFT Ripper by Mark Menz. Once exported, the CSV file can be opened in your favorite spreadsheet program for easy filtering. The following screen shot shows the MFT record for the malicious.dll after I using the Get-Item cmdlet to change the dates (note the dates are stored in UTC format).
As you can see from the export, the problem with this tactic is the Std Info Entry Date (MFT Entry Modified Time) remains unchanged. Moreover, the FN Info ($File_Name Attribute) Dates also remain unchanged. Interesting enough, renaming the file will change both these values but doing so will change them to the current system time. The only real option I have been able to find is to change the system time prior to renaming. This can be accomplished by using the set-date cmdlet in Power Shell.
set-date -date 02/11/10Now we have the following export from the MFT.
set-date -date 07:30:00
rename-item malicious.dll notmalicious.dll
Unfortunately, this approach is far from perfect. The MFT Entry Modified Date within the $File_Name Attribute remains unscathed (I have not been able to figure out how to change this). Moreover, by default, a System Informational Event is logged within the Windows Event log of a change to the system time. Note the the date of the event however. There is a similar event logged for the time change.
Log Name: SystemOther considerations, include .lnk files being stored within the MFT due to the "Recent Document History" feature being turned on by default within Windows. This feature would create a malicious.dll.lnk file in the C:\Users\Username\AppData\Roaming\Microsoft\Windows\Recent folder on Windows Vista and 7 and consequently create an MFT entry for this file with metadata. This certainly would also be a red flag for the forensic investigator. Thus an attacker may want to turn this feature off prior to performing any tasks on the host. With PowerShell this can be accomplished by using the New-ItemProperty cmdlet to create the appropriate registry values and then by using Stop-Process cmdlet to force the reload of the explorer.exe shell for the current user.
Source: Microsoft-Windows-Kernel-General
Date: 2/10/2010 12:00:00 AM
Event ID: 1
Task Category: None
Level: Information
Keywords: Time
User: User
Computer: CompromisedHost
Description:
The system time has changed to ?2010?-?02?-?11T04:00:00.000000000Z from ?2010?-?04?-?07T18:49:38.251360400Z.
mkdir HKCU:\software\microsoft\windows\currentversion\policies\explorerThe explorer process reloading will also generate an information event log.
New-ItemProperty HKCU:\software\microsoft\windows\currentversion\policies\explorer -name norecentdocshistory -propertytype DWord -value 1
Stop-Process -name explorer -force
Log Name: ApplicationStopping the eventlog service prior to actions being taken on the compromised host may be prudent, but I will save the manipulation of other forensic timeline sources for a later post.
Source: Microsoft-Windows-Winlogon
Date: 2/11/2010 7:34:12 AM
Event ID: 1002
Task Category: None
Level: Information
Keywords: Classic
User: N/A
Computer: CompromisedHost
Description:
The shell stopped unexpectedly and explorer.exe was restarted.
Updated May 3, 2010:
Published a follow-up post on successfully changing the Entry Modified Date within the $File_Name Attribute thanks to an anonymous tip. The followup can be found here.
Monday, October 12, 2009
Lessons Learned: Vulnerability and Expectations Management
As an information security professional, a large portion of my work day is spent with vulnerability and patch management. So when I saw a security advisory addressing multiple vulnerabilities in both Symantec's Corporate Antivirus and Endpoint Security Solution products last June, I immediately investigated. You can read the security advisory here. I became concerned because other Vendors also use the Intel File Transfer service so I thought it be prudent to investigate.
I began looking around and noted that Tenable Network Solutions had a Nessus plugin. You can find the plugin here. So like any true geek with nothing to do on a Saturday evening, I began scanning. I was surprised at what I found.
The systems running the Intel File Transfer service from other vendors were not vulnerable but systems patched with Symantec 10.1 MR8 were still be vulnerable. The solution table in Symantec’s Advisory states that the issue with AMS2 was fixed in this version.
I contacted someone I knew at Tenable and asked for assistance in verifying the vulnerability. The plugin actually contains remote execution code but it is commented out by default. With instruction from Tenable I uncommented the cmd = "calc"; line in the NASL script and ran a nessusd -R to perform a reload of the Nessus Database. Sure enough, the next scan verified that cmd.exe would execute without authentication on the vulnerable machines.
So what gives? Is Symantec's advisory incorrect? Not entirely, although it may be misleading. This became a case of reading the fine print. Further down the advisory we find this information:
"AMS2 is installed by default with Symantec Antivirus Server 9.0. AMS2 is an optional component in Symantec Antivirus Server 10.0 or 10.1. These vulnerabilities will only impact systems if AMS has been installed."
And further down, under mitigation section:
"Reporting has replaced AMS2 as the recommended method of alerting. Symantec Endpoint Protection Central Quarantine Server 11.0 MR3 and later no longer include AMS2. Symantec recommends that customers who are still using AMS2 switch to Reporting to manage alerts in their environments. If the customer is unable to switch to reporting immediately then Symantec recommends that the customer either disables AMS2 as a temporary mitigation or completely uninstall AMS2."
All the systems vulnerable had all been upgraded from an earlier version of Symantec Antivirus Corporate Edition 9.X. During the remote upgrade process there seemed to be no way to specify if AMS2 was to be installed or not. Symantec support seemed unable to instruct me on how to remove or disable AMS2 from the affected systems and I have spent the last several months trying to get them to change the advisory so that the solution table listed at the top of the document noted this tidbit at the bottom. To say the least I have not been successful in this endeavor and feel a bit frustrated. Although the Sales Executive has been nice enough to try and sell me their Endpoint Protection v11 product and recommended I start with a fresh install.
If you do want to mitigate the vulnerability, I determined disabling the Intel File Transfer service works well and does not seem interfere with my configuration. I recommend you test this in your own environment however.
So Lessons Learned:
Read Security Advisories carefully.
Scanning is an important part of any vulnerability management plan.
Manage your expectations when dealing with vendors.
Updated December 29, 2009
Posted two updates on the release of the POC for this vulnerability and a report of the exploit being used in the wild by SANS ISC.
I began looking around and noted that Tenable Network Solutions had a Nessus plugin. You can find the plugin here. So like any true geek with nothing to do on a Saturday evening, I began scanning. I was surprised at what I found.
The systems running the Intel File Transfer service from other vendors were not vulnerable but systems patched with Symantec 10.1 MR8 were still be vulnerable. The solution table in Symantec’s Advisory states that the issue with AMS2 was fixed in this version.
I contacted someone I knew at Tenable and asked for assistance in verifying the vulnerability. The plugin actually contains remote execution code but it is commented out by default. With instruction from Tenable I uncommented the cmd = "calc"; line in the NASL script and ran a nessusd -R to perform a reload of the Nessus Database. Sure enough, the next scan verified that cmd.exe would execute without authentication on the vulnerable machines.
So what gives? Is Symantec's advisory incorrect? Not entirely, although it may be misleading. This became a case of reading the fine print. Further down the advisory we find this information:
"AMS2 is installed by default with Symantec Antivirus Server 9.0. AMS2 is an optional component in Symantec Antivirus Server 10.0 or 10.1. These vulnerabilities will only impact systems if AMS has been installed."
And further down, under mitigation section:
"Reporting has replaced AMS2 as the recommended method of alerting. Symantec Endpoint Protection Central Quarantine Server 11.0 MR3 and later no longer include AMS2. Symantec recommends that customers who are still using AMS2 switch to Reporting to manage alerts in their environments. If the customer is unable to switch to reporting immediately then Symantec recommends that the customer either disables AMS2 as a temporary mitigation or completely uninstall AMS2."
All the systems vulnerable had all been upgraded from an earlier version of Symantec Antivirus Corporate Edition 9.X. During the remote upgrade process there seemed to be no way to specify if AMS2 was to be installed or not. Symantec support seemed unable to instruct me on how to remove or disable AMS2 from the affected systems and I have spent the last several months trying to get them to change the advisory so that the solution table listed at the top of the document noted this tidbit at the bottom. To say the least I have not been successful in this endeavor and feel a bit frustrated. Although the Sales Executive has been nice enough to try and sell me their Endpoint Protection v11 product and recommended I start with a fresh install.
If you do want to mitigate the vulnerability, I determined disabling the Intel File Transfer service works well and does not seem interfere with my configuration. I recommend you test this in your own environment however.
So Lessons Learned:
Read Security Advisories carefully.
Scanning is an important part of any vulnerability management plan.
Manage your expectations when dealing with vendors.
Updated December 29, 2009
Posted two updates on the release of the POC for this vulnerability and a report of the exploit being used in the wild by SANS ISC.
Thursday, August 20, 2009
All’s Fair in Love, War, and Hacking.
Last Month, I had to opportunity to participate in the NYC Infraguard Capture the Flag event provided by WhiteWolf Security and sponsored by Tenable Network Security .
The Capture the Flag (CTF) was made up of two teams. The red team (attackers) and the blue team (defenders). The Blue team was given an unprotected network with unpatched hosts and was asked to defend them to the best of their ability. To complicate matters, business injects were used to simulate the real world (i.e. – The CEO wants a website up and running by the end of business). A mock FBI field office was available to report a compromise and loss of data. The blue team was not allowed to use commercial products during the event. The red team's goal is to gain access to those systems and steal the data. Points are given for each compromise and data theft. As you might expect the odds are in the attackers favor. One could argue that this is true in the real world too.
The winning competing blue team was organized, well versed, and remained calm. Each team member seemed to have expertise in a particular area or operating system. They coordinated their defense and when they did get compromised they went into incident response mode, and gathered the logs and proof they needed for reporting the compromise to the FBI field office. By the afternoon of the first day, they were completely locked out of their own systems. They chose to restore their systems from backup and all of their systems were up and running again within an hour. Because of this they won the competition.
It demonstrated the importance of not only defense in depth but having good Incident Response and Disaster Recovery plans in place. It is not a question of if the attackers get in, it is a question of when, so be ready!
It was a great experience and learning opportunity. If you have not had the opportunity to participate in a CTF, I fully recommend it!
The Capture the Flag (CTF) was made up of two teams. The red team (attackers) and the blue team (defenders). The Blue team was given an unprotected network with unpatched hosts and was asked to defend them to the best of their ability. To complicate matters, business injects were used to simulate the real world (i.e. – The CEO wants a website up and running by the end of business). A mock FBI field office was available to report a compromise and loss of data. The blue team was not allowed to use commercial products during the event. The red team's goal is to gain access to those systems and steal the data. Points are given for each compromise and data theft. As you might expect the odds are in the attackers favor. One could argue that this is true in the real world too.
The winning competing blue team was organized, well versed, and remained calm. Each team member seemed to have expertise in a particular area or operating system. They coordinated their defense and when they did get compromised they went into incident response mode, and gathered the logs and proof they needed for reporting the compromise to the FBI field office. By the afternoon of the first day, they were completely locked out of their own systems. They chose to restore their systems from backup and all of their systems were up and running again within an hour. Because of this they won the competition.
It demonstrated the importance of not only defense in depth but having good Incident Response and Disaster Recovery plans in place. It is not a question of if the attackers get in, it is a question of when, so be ready!
It was a great experience and learning opportunity. If you have not had the opportunity to participate in a CTF, I fully recommend it!
Subscribe to:
Posts (Atom)