Search This Blog

Wednesday, July 3, 2013

The Implications of Office 365 in Digital Forensics and eDiscovery – part 1

The Implications of Office 365 in Digital Forensics and eDiscovery – part 1

A couple of years ago Microsoft began to embrace cloud technology and launched Office 365 for Business, in direct competition with solutions being developed by Google and others. This was followed more recently with a home user edition: Office 365 Home Premium. The Office 365 suite is an evolution of the standard Office package and introduces, amongst other things, a cloud-based aspect called SkyDrive, which allows for greater online collaboration on documents. In the first of two posts, we will look at how Office 365 works, and provide an overview of the forensic artefacts that may be retrieved.
Users must have a registered Microsoft Account in order to download Office 365, which comes bundled with SkyDrive and the Office 2013 Upload Center. By default, all three applications are installed, and a SkyDrive folder is created for the user’s account at ~\Users\Username\SkyDrive.
When setting up SkyDrive on a new PC, the user has two main setup options. They can either use the default express settings, which will download any files currently associated with that account, or they can customise the setup and sync specific files and folders with the PC. They can also specify a different location for the SkyDrive folder.
The Windows Registry holds some useful Office 365 and SkyDrive configuration data. We can verify that Office 365 is installed, and determine the version in use by examining the following keyHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\15.0\ClickToRun\propertyBag\productreleaseid. The value generated for this key in a typical Office 365 Home Premium setup is “O365HomePremRetail”, and it is expected that a similar naming convention will be used to represent other licensing models.
Each Microsoft account grants the user five Office 365 licences, which are managed online. Each licensed PC is given a unique identifier that is listed online and can be matched to a value in the registry, located atHKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Registration. This ID is actually the name that the user has given the computer (for example, WIN-UJMBC6MS5HB).
 The PC ID can also be retrieved from the SkyDrive system folder at C:\Users\Username\AppData\Local\Microsoft\SkyDrive\setup\logs. This folder contains one or more text files, which store the event logs for all synchronisation events and application updates, however only the logs that reference when SkyDrive was installed or updated will contain the PC ID. The line in the log containing the ID can be found relatively easily by searching for “X-Computer”.
Further information can be gleaned from the SkyDrive settings folder located at C:\Users\Username\AppData\Local\Microsoft\SkyDrive\settings. First, there is a text file which is named using a GUID (e,g. 130cf147b5dzxd4c), which is assigned to the SkyDrive account, and also forms part of the URL when the user logs in through a web browser.
The aforementioned settings file contains significant data about the SkyDrive account, including what Microsoft call the last ‘refresh’ time (i.e. the last time the account synchronised with the cloud server), the number of sync requests sent to the online server since Office 365 was installed, and the total bytes transferred. The last refresh time is also found as a Windows 64-bit little endian file time in the registry hive underHKEY_CURRENT_USER\Software\Microsoft\SkyDrive.
Uploads and downloads of Office 365 files to and from the SkyDrive account are managed by the Office 2013 Upload Center. When a new file is created using an Office 365 application, the user can either save only locally, or to their SkyDrive folder, which creates a local copy and a cloud copy. The latter creates a local version in the user’s SkyDrive folder, but also allows the Upload Center to sync the file with the cloud server. Providing the PC is online and uploads have not been paused, this sync happens almost instantaneously. Otherwise, the file is queued for upload to the cloud at the next opportunity.
While the file is only being accessed from one PC, the created, modified and accessed times behave like a normal Office file. However, if the file is accessed from another PC linked to the SkyDrive account, then there are slight differences. Firstly, the created date on the second PC is that of when the file was first uploaded to the cloud server. This is not necessarily the same as when it first came into existence on the original PC, or when it was downloaded to the additional PC. This is demonstrated in figure 1 below, which shows the created time differences for the same file on two PCs. Although in this example the difference is relatively small, if SkyDrive wasn’t synced as regularly the difference could be much bigger.
With respect to the modified date stamps, a direct comparison of between the first and second PC after synchronisation shows that this information stays the same during the sync, rather than reflecting the fact that the file has been downloaded to another PC. However, the last accessed time is updated as a result of this event and, in the example below, the accessed date on PC 2 actually reflects the time the file was downloaded from SkyDrive (although this may not always be the case).
Figure 1: A file created on PC 1 (left) and the same file on PC 2 with new created and accessed times (right).
office-365
Once synchronised, the file times then behave much as they would on an offline system. When a change is made and the file is saved, the modified and accessed times update on the local PC and, as long as synching takes place regularly, are also updated with the cloud account, so that this metadata is the same for all versions of the file on PCs associated with the account.
It is clear that Office 365 adds an extra dimension to the collection of Microsoft Office documents. While imaging a PC will capture any documents synced with SkyDrive, there may be further files sitting in the cloud that have never touched that particular device. Furthermore, the time and date information is not as reliable, and behaves differently to a standard Office document. As a result, considerable discrepancies could arise if they are not synced regularly.
Keep an eye out for part 2 of this Office 365 series, which will look at the back end that powers Office 365, and the extra information that can be uncovered from it.
Source: http://www.millnet-consulting.com/2013/05/27/office365-in-forensics-ed-1/#more-1047

Intercepting Blackberry Application Traffic

Intercepting Blackberry Application Traffic


Intercepting mobile traffic is one of the key areas of mobile application penetration testing and Blackberry mobile applicatiosn are no different. In this post, we will look at methods of intercepting blackberry application traffic.

It is important to note that the standalone blackberry simulator does not offer any mechanism to route HTTP traffic over a web proxy. To use a web proxy for traffic interception, one has to use blackberry device simulator + MDS and email simulator. Assuming you have both installed, following steps will allow you to intercept blackberry web traffic.

Case 1: Routing HTTP traffic via web proxy:

  1. Browse to "\Program Files\Research In Motion\BlackBerry Email and MDS Services Simulators #.#.#\MDS\config"
  2. Open the rimpublic.property file
  3. Under the HTTP HANDLER section, add your web proxy configuration information:
application.handler.http.proxyEnabled=true
application.handler.http.proxyHost=<your proxy address>
application.handler.http.proxyPort=<your proxy port>

The following image shows the rimpublic.property file HTTP HANDLER section for fiddler running on port 8888 on localhost.

Web Proxy Configuration
More details on proxy configuration can be seen here. Once you save these settings and launch MDS simulator, you will be able to monitor, intercept and modify all HTTP traffic. However, we still need to put in some extra work for SSL traffic.


Image shows HTTP traffic captured for google.com


Case 2: Routing HTTPS traffic via web proxy:
The above mentioned configuration was not successful when attempted on SSL traffic. It was time for some workaround and I thought of using a reverse proxy. The idea of using reverse proxy had some limitations but it worked seamlessly and allowed me to intercept SSL traffic for a particular domain. To demonstrate this concept, I will be using Charles Proxy's Reverse Proxy. You can use any reverse proxy of your own choice. Lets configure the Charles proxy now.
  1. Obtain the IP address to which the application/browser talks
  2. Obtain the IP for the target domain. nslookup for mail.google.com revealed four DNS entries(74.125.226.184, 74.125.226.182, 74.125.226.181, 74.125.226.183) and one of them was chosen to be destination for reverse proxy settings. See the screenshots below for Charles Reverse Proxy settings.
  3. In the hosts file make an entry to forward all the target domain address to the IP at which reverse proxy is hosted. In our case, I entered the following for mail.google.com
    127.0.0.1 mail.google.com
  4. Now launch your browser and access https://mail.google.com
  5. The blackberry simulator will issue a certificate error. Choose the "Trust Certificate" option, provide certificate store password and  the save your settings.
  6. All the traffic will be routed via Charles now. Enjoy!

To summarize reverse proxy settings (Two sets of entries):
Entry 1: To ensure that all SSL traffic is forwarded to mail.google.com:443
Listening on : 127.0.0.1:443
Forwarding to: 74.125.226.181:443 #one

Entry 2: To ensure that all plain HTTP is forwarded too
Listening on : 127.0.0.1:80
Forwarding to: 74.125.226.181:80
Image shows reverse proxy settings in Charles

Image shows the certificate error issued when https://mail.google.com is access via reverse proxy. Choosing the "Trust Certificate" options allows SSL traffic to be intercepted.


Source: http://gursevkalra.blogspot.in/2011/06/intercepting-blackberry-application.html

Thursday, May 16, 2013

Internship for 2 months

Internship for 2 months (VAPT Tester, Cyber Security Professional) Freelance

at Valency Networks in Pune (Published at 07-05-2013)
We have 2 vacancies for Internship for collage students who want to eventually pursue career in cyber security domain. Candidate will get hands-on experience and knowledge. No salary will be offered.
Internship period of 2-3 months depending on your collage schedule. Female candidates will be given preference to promote their presence in this field.

BIOS LOG

Accessing BIOS for Windows

  • Turn on the computer. As the computer is booting up, look toward the bottom of the screen. You will notice directions that read "BIOS = F2, Boot System = F12" or something similar to those commands. Again, this will vary according to the manufacturer. Press the button indicated for BIOS.
  • Press the button for "System Log" or "Event Log" on the menu that appears. The menu will offer you a variety of options that are accessed by pressing the indicated buttons.
  • View the system log. If you do not see any of the prompts instructed in the previous steps, you may have to contact the BIOS manufacturer. To find the BIOS manufacturer for your system, go to the Search area on the desktop and type in "System Information." Click "System Information" in the result, then view "System summary." The BIOS manufacturer will be listed.

Accessing BIOS for Mac

  • Turn on the computer and wait for the desktop screen to load.
  • Go to "Applications," "Utilities," then "Console" or type "Console" in the Spotlight area.
  • Go to "system.log" to view the BIOS system log.