A few modifications in this release, most notably a fix for a false positive issue that raised it's ugly head from the Microsoft Tuesday release.
Microsoft Security Advisory (MS09-059):
A vulnerability in the Microsoft Local Security Authority Subsystem Service (LSASS) may allow a remote attacker to cause a Denial of Service (Dos) against an affected system.
A previously released rule to detect attacks targeting this vulnerability has been modified to reduce the incidence of false positive events. It is included in this release and is identified with GID 3, SID 16167.
As always, changelogs: http://www.snort.org/vrt/advisories/2009/10/22/vrt-rules-2009-10-22.html
Thursday, October 22, 2009
Snort 2.8.5.1 Release
Hot on the heels of the Snort 2.8.5 release, a new Snort tarball is now available that fixes a few issues:
- Fixed syslog output when running on Windows.
- Fixed potential segfault when printing IPv6 packets using the -v option. Thanks to Laurent Gaffie for reporting this issue.
- Fixed segfault when additional policies were added during a configuration reload.
Wednesday, October 21, 2009
Rapid7 make bold statement acquiring Metasploit Project
Normally the acquisition of an Open Source product by a commercial product wouldn’t make the VRT blog, but in this case I believe this acquisition is going to cause some interesting developments in the threat landscape and in the vulnerability management space. I also think this is a very bold endeavor for a vulnerability management company like Rapid7, more on that in a bit.
First up a quick Troll shoot.
On the Vulnerability Management side, I think this changes the game for guys like nCircle and Tenable as Rapid7’s NeXpose™ product will be the only Vulnerability Management tool that can actually prove what it is reporting. It also gives Rapid7 the interesting advantage of being able to live test mitigation strategies and defenses. This is something that other vulnerability management solutions can’t do out of the box. That said it is going to be interesting to see how this integration takes place, and how many people are willing to click the “exploit host” button if that is how it is done.
Outside all that, I always loving seeing Open Source products make it into the commercial game as it continues to show the value of Open Source in the enterprise, and that just because software is free doesn’t mean it’s not worth more than the sum of all its license text.
First up a quick Troll shoot.
- The license for Metasploit stays BSD.
- Metasploit continues to be a community driven project.
- When an Open Source project gets commercial backing the developers on that project don’t need day jobs anymore. They also get resources, tools, and budgets. This in my opinion means a lot of new code for this project in a short period of time. I saw exactly this when I started with Sourcefire almost 7 years ago, no more small releases just big old feature releases.
- Faster exploit development. If you have resources and people you can quickly setup development environments, test things, reverse things, and build Metasploit modules. I’m guessing the number of exploits in Metasploit will quickly eclipse CORE and Immunity within a 6-month timeframe. I’m guessing this will follow the same course as with the Sourcefire VRT; go from 3k rules to 5k rules overnight.
- Stability and Reliability. If you buy something you want it to work and if you’ve got resources your Open Source users expect a higher quality product. I’d assume they are going to hit this area first.
On the Vulnerability Management side, I think this changes the game for guys like nCircle and Tenable as Rapid7’s NeXpose™ product will be the only Vulnerability Management tool that can actually prove what it is reporting. It also gives Rapid7 the interesting advantage of being able to live test mitigation strategies and defenses. This is something that other vulnerability management solutions can’t do out of the box. That said it is going to be interesting to see how this integration takes place, and how many people are willing to click the “exploit host” button if that is how it is done.
Outside all that, I always loving seeing Open Source products make it into the commercial game as it continues to show the value of Open Source in the enterprise, and that just because software is free doesn’t mean it’s not worth more than the sum of all its license text.
Tuesday, October 20, 2009
Vulnerability Report now available via iTunes
Yes, that's right, our monthly vulnerability report is now available for your convenience, via iTunes. To subscribe, hit up this link: http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=336370330
Note that the video is large due to it being in high definition, we'll be making adjustments as we move forward to make sure the download size is more reasonable.
Note that the video is large due to it being in high definition, we'll be making adjustments as we move forward to make sure the download size is more reasonable.
Additionally, there is now a Sourcefire application for the iPhone/iPod Touch that will keep you up to date with the happenings on our blog, snort.org and the top 10 malware threats from ClamAV.
Labels:
iTunes,
Vulnerability Report
Rule release for today - October 20th, 2009
A maintenance release this week, with several new rules in web-client, specific-threats, web-misc, oracle, smtp and dos rule sets.
As always, the changelogs are available here:
http://www.snort.org/vrt/advisories/2009/10/20/vrt-rules-2009-10-20.html
As always, the changelogs are available here:
http://www.snort.org/vrt/advisories/2009/10/20/vrt-rules-2009-10-20.html
Thursday, October 15, 2009
October 2009 Vulnerability Report
Sourcefire VRT Vulnerability Report October 2009 from Sourcefire VRT on Vimeo.
Sourcefire VRT Vulnerability Report
This month's report covers the Microsoft Tuesday advisories, including IIS FTP vuln, SMBv2 remote code execution and Adobe patch Tuesday.
Wednesday, October 14, 2009
How does malware know the difference between the virtual world and the real world?
It is no secret that the Information Security industry takes advantage of virtualization software in order to research security threats. VMWare, Sandboxie, Virtual PC, Anubis, CWSandbox, JoeBox, VirtualBox, Parallels, QEMU are just just of few of these virtual machines. The cornucopia of virtual environments gives the security professional the opportunity to observe and analyze malicious software in a convenient and easily reproducible manner. This presents an issue for malware writers and because of this, they often include code in their binaries to make it more difficult for computer security professionals to analyze their executables in those virtual environments. Here are some of the most frequent anti-virtualization techniques:
Check for the presence of virtualized hardware:
Virtual environments have virtual network interfaces. Just like any network interface, they are assigned a unique MAC address that usually includes the manufacturer's identification number. For example, a network interface for VMware Workstation will have a MAC address that starts with 00:50:56 or 00:0C:29 (VMware has more than one organizationally unique identifier or OUI). Malware can check for the presence of certain OUIs and choose to behave differently or not to display any malignant behavior whatsoever in a virtual machine.
It is also possible to check for the presence of GUIDs that give away the fact that it's being run in a virtual environment. Eg: MD5: 0151c5afde070a7b194f492d26e9b3ef (Trojan.Agent-124243 by ClamAV):
The presence of
Each virtual machine is associated with specific device drivers, registry values that give away their nature. For instance:
Hard drive driver (VMware):
Video driver (VMware):
Mouse driver (VMware):
Any of these can be used by a malware writer to detect the presence of a virtual machine.
Descriptor Table Registers check:
There is only one Interrupt Descriptor Table Register (IDTR), one Global Descriptor Table Register (GDTR) and one Local Descriptor Table Register (LDTR) per processor. Since there are two operating systems running at the same time (the host and the guest), the virtual machine needs to relocate the IDTR, GDTR and LDTR for the guest OS to different locations in order to avoid conflicts. This will cause inconsistencies between the values of these registers in a virtual machine and in the native machine. The instructions SIDT, SGDT and SLDT are assembly instructions that can respectively be used to retreive the values of IDTR, GDTR and LDTR.
Eg: MD5: b27d73bfcbaec49a95f23b45e9cf9310 (W32.Virut-54 by ClamAV)
The IDT is at:
Backdoor I/O port:
VMware uses the I/O port
Basically, the magic number
Exit if being debugged:
While this is not, per se, a anti-virtualization technique, it remains a a popular check performed by malware to see if a user-land debugger is present on the operating system. That's because more often than not a debugger will be installed in a virtual image used for malware analysis.
Eg: MD5: 74ab05d1ebdba509fd68711b360c1235 (Trojan.IRCBot-3475 by ClamAv)
For the Windows API function ZwQuerySystemInformation, setting the value of SystemInfoClass to 2 (SystemKernelDebuggerInformation) retrieves system information on the presence of a user-land debugger.
For the Windows API function ZwQueryInformationProcess, setting the value of ProcessInformationClass to 7 (ProcessDebugPort) retrieves the port number for the debugger of the process. A value other than 0 indicates that the process is being run through a user-land debugger.
How to thwart virtual machine detection:
For starters, do not install tools provided by the virtual machine in your guest OS. For example, VMware provides a set of tools called VMware Tools that enhances the overall user experience with the guest OS. The drawback is that installing VMware Tools in a Windows guest OS will leave many clues easily detectable by a piece malware that it is being run in a virtual machine.
The next step is to edit your VMware .vmx file. When you create a new virtual image with VMware, settings about it are stored in a configuration file with the .vmx extension. The file contains information about networking, disk size, devices attached to the virtual machine, etc...and is usually located in the directory where you created your virtual image. With your guest OS stopped, edit the .vmx file and append the following:
Now start your virtual machine. This will allow you to run (with very little effort) more vmware-aware malware than before.
I'll point out that:
Now, what if after all this, your piece of malware still detects that it is being run in a virtual machine? I would go through the code, find where virtual machine checks are being performed and patch the code with NOPs (0x90).
Finally, if that's too hard or not possible for whatever reason, run your sample on a native system! :-) (you can always use system backup and restore software to quickly revert the machine to its original state without reinstalling the OS)
Check for the presence of virtualized hardware:
Virtual environments have virtual network interfaces. Just like any network interface, they are assigned a unique MAC address that usually includes the manufacturer's identification number. For example, a network interface for VMware Workstation will have a MAC address that starts with 00:50:56 or 00:0C:29 (VMware has more than one organizationally unique identifier or OUI). Malware can check for the presence of certain OUIs and choose to behave differently or not to display any malignant behavior whatsoever in a virtual machine.
It is also possible to check for the presence of GUIDs that give away the fact that it's being run in a virtual environment. Eg: MD5: 0151c5afde070a7b194f492d26e9b3ef (Trojan.Agent-124243 by ClamAV):
.text:004012EA jz short loc_40130E .text:004012EC push 104h ; size_t .text:004012F1 push offset a76487644317703 ; "76487-644-3177037-23510" .text:004012F6 lea ecx, [ebp+var_104] .text:004012FC push ecx ; char * .text:004012FD call _strncmp .text:00401302 add esp, 0Ch .text:00401305 test eax, eax .text:00401307 jnz short loc_40130E
The presence of
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\ProductId 76487-644-3177037-23510
shows that the host environment is CWSandbox.Each virtual machine is associated with specific device drivers, registry values that give away their nature. For instance:
Hard drive driver (VMware):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\IDE\DiskVMware_Virtual_IDE_Hard_
Drive___________00000001\3030303030303030303030303030303030303130\FriendlyName VMware Virtual IDE Hard Drive
Video driver (VMware):
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Class\{4D36E968-E325-11CE-BFC1-08002BE10318}\0000\DriverDesc VMware SVGA II
Mouse driver (VMware):
%WINDIR%\system32\drivers\vmmouse.sys
Any of these can be used by a malware writer to detect the presence of a virtual machine.
Descriptor Table Registers check:
There is only one Interrupt Descriptor Table Register (IDTR), one Global Descriptor Table Register (GDTR) and one Local Descriptor Table Register (LDTR) per processor. Since there are two operating systems running at the same time (the host and the guest), the virtual machine needs to relocate the IDTR, GDTR and LDTR for the guest OS to different locations in order to avoid conflicts. This will cause inconsistencies between the values of these registers in a virtual machine and in the native machine. The instructions SIDT, SGDT and SLDT are assembly instructions that can respectively be used to retreive the values of IDTR, GDTR and LDTR.
Eg: MD5: b27d73bfcbaec49a95f23b45e9cf9310 (W32.Virut-54 by ClamAV)
UPX2:3142A03A loc_3142A03A: ; CODE XREF: sub_3142A02E+2 j UPX2:3142A03A push eax UPX2:3142A03B sidt fword ptr [esp+var_6+4] UPX2:3142A040 pop eax UPX2:3142A041 mov eax, [eax+6] UPX2:3142A044 shl eax, 10h UPX2:3142A047 jns short sub_3142A021
The IDT is at:
0x80ffffff in Windows 0xe8XXXXXX in Virtual PC 0xffXXXXXX in VMware
Backdoor I/O port:
VMware uses the I/O port
0x5658
("VX" in ASCII) to communicate with the virtual machine. A piece of malware could detect the presence of that port by doing the following:mov EAX, 564D5868h ; VMXh xor EBX, EBX ; set EBX to anything but 0x564D5868 (in this case 0) mov CX, 0Ah ; Backdoor command. 10: Get VMware version mov DX, 5658h ; VX in EAX, DX ; Read from port VX into EAX cmp EBX, 564D5868h ; EBX should have the magic number VX is VMware is present. If not, EBX=0
Basically, the magic number
0×564D5868
("VMXh") is copied to EAX and EBX is set to anything but 0x564D5868
. A backdoor command is loaded into CX and finally the I/O port number 0x5658
("VX") is loaded into DX. Then the "in" instruction is used to read from port 0x5658
into EAX. Outside of VMware (on a native host), a privilege error occurs. Under VMware, the magic number 0x564D5868
is returned to EBX (yes, in this case EBX is affected by in EAX, DX) hence the CMP instruction.Exit if being debugged:
While this is not, per se, a anti-virtualization technique, it remains a a popular check performed by malware to see if a user-land debugger is present on the operating system. That's because more often than not a debugger will be installed in a virtual image used for malware analysis.
Eg: MD5: 74ab05d1ebdba509fd68711b360c1235 (Trojan.IRCBot-3475 by ClamAv)
.text:004050F8 push offset aZwquerysystemi ; "ZwQuerySystemInformation" .text:004050FD push [ebp+hModule] ; hModule .text:00405100 call ds:GetProcAddress .text:00405106 mov [ebp+var_4], eax .text:00405109 push offset aZwqueryinforma ; "ZwQueryInformationProcess" .text:0040510E push [ebp+hModule] ; hModule .text:00405111 call ds:GetProcAddress .text:00405117 mov [ebp+var_14], eax .text:0040511A cmp [ebp+var_4], 0 .text:0040511E jz short loc_405147 .text:00405120 push 0 .text:00405122 push 2 ; SystemInformationLength .text:00405124 lea eax, [ebp+var_8] .text:00405127 push eax ; SystemKernelDebuggerInformation .text:00405128 push 23h .text:0040512A call [ebp+var_4] ; ZwQueryInformationProcess .text:0040512D test eax, eax .text:0040512F jnz short loc_405147 ; process is being debugged
For the Windows API function ZwQuerySystemInformation, setting the value of SystemInfoClass to 2 (SystemKernelDebuggerInformation) retrieves system information on the presence of a user-land debugger.
NTSTATUS WINAPI ZwQuerySystemInformation( __in SYSTEM_INFORMATION_CLASS SystemInformationClass, __inout PVOID SystemInformation, __in ULONG SystemInformationLength, __out_opt PULONG ReturnLength );
For the Windows API function ZwQueryInformationProcess, setting the value of ProcessInformationClass to 7 (ProcessDebugPort) retrieves the port number for the debugger of the process. A value other than 0 indicates that the process is being run through a user-land debugger.
NTSTATUS WINAPI ZwQueryInformationProcess( __in HANDLE ProcessHandle, __in PROCESSINFOCLASS ProcessInformationClass, __out PVOID ProcessInformation, __in ULONG ProcessInformationLength, __out_opt PULONG ReturnLength );
How to thwart virtual machine detection:
For starters, do not install tools provided by the virtual machine in your guest OS. For example, VMware provides a set of tools called VMware Tools that enhances the overall user experience with the guest OS. The drawback is that installing VMware Tools in a Windows guest OS will leave many clues easily detectable by a piece malware that it is being run in a virtual machine.
The next step is to edit your VMware .vmx file. When you create a new virtual image with VMware, settings about it are stored in a configuration file with the .vmx extension. The file contains information about networking, disk size, devices attached to the virtual machine, etc...and is usually located in the directory where you created your virtual image. With your guest OS stopped, edit the .vmx file and append the following:
isolation.tools.setPtrLocation.disable = "TRUE" isolation.tools.setVersion.disable = "TRUE" isolation.tools.getVersion.disable = "TRUE" monitor_control.disable_directexec = "TRUE" monitor_control.disable_chksimd = "TRUE" monitor_control.disable_ntreloc = "TRUE" monitor_control.disable_selfmod = "TRUE" monitor_control.disable_reloc = "TRUE" monitor_control.disable_btinout = "TRUE" monitor_control.disable_btmemspace = "TRUE" monitor_control.disable_btpriv = "TRUE" monitor_control.disable_btseg = "TRUE"
Now start your virtual machine. This will allow you to run (with very little effort) more vmware-aware malware than before.
I'll point out that:
monitor_control.disable_directexec = "TRUE"
will usually thwart descriptor table registers checks. This setting will make VMware interpret each assembly instruction instead of executing them directly on the processor. Therefore a the result of a sidt instruction will not be an address in the0xffXXXXXX
range as one would get without this setting.isolation.tools.getVersion.disable = "TRUE"
will thwart the backdoor I/O check.
Now, what if after all this, your piece of malware still detects that it is being run in a virtual machine? I would go through the code, find where virtual machine checks are being performed and patch the code with NOPs (0x90).
Finally, if that's too hard or not possible for whatever reason, run your sample on a native system! :-) (you can always use system backup and restore software to quickly revert the machine to its original state without reinstalling the OS)
Tuesday, October 13, 2009
Microsoft Tuesday Coverage for October 2009
Bumper crop of vulnerabilities patched this month by Microsoft and Adobe.
Microsoft Security Advisory (MS09-050):
A vulnerability in the way that Microsoft Windows systems process SMBv2.0 transactions may allow a remote attacker to execute code on a vulnerable system.
A rule to detect attacks targeting this vulnerability is included in this release and is identified with GID 3, SID 16168.
Additionally, a previously released rule to detect attacks targeting this issue has been updated with the appropriate reference information and is included in this release and is identified with GID 1, SID 15930.
Microsoft Security Advisory (MS09-051):
A vulnerability in Windows Media Runtime may allow a remote attacker to execute code on a vulnerable system.
Rules to detect attacks targeting this vulnerability are included in this release and are identified with GID 3, SIDs 16157 and 16158.
Microsoft Security Advisory (MS09-052):
A vulnerability in the Windows Media Player may allow a remote attacker to execute code on an affected system.
A rule to detect attacks targeting this vulnerability is included in this release and is identified with GID 3, SID 16156.
Microsoft Security Advisory (MS09-053):
A vulnerability in the FTP service for Microsoft Internet Information Services may allow a remote attacker to execute code on an affected system.
Previously released rules to detect attacks targeting this issue have been updated with the appropriate reference information and are included in this release, they are identified with GID 1, SIDs 1973, 2374 and 15932.
Microsoft Security Advisory (MS09-054):
Microsoft Internet Explorer contains programming errors that may allow a remote attacker to execute code on an affected system.
Rules to detect attacks targeting these vulnerabilities are included in this release and are identified with GID 3, SIDs 16149 through 16152.
Microsoft Security Advisory (MS09-055):
A vulnerability in the way that ActiveX controls are handled may allow a remote attacker to execute code on a vulnerable system.
Rules to detect attacks targeting this vulnerability are included in this release and are identified with GID 1, SIDs 16159 through 16166.
Microsoft Security Advisory (MS09-056):
A vulnerability in the way that SSL certificates are handled by the Microsoft CryptAPI may allow a remote attacker to spoof a genuine certificate.
Rules to detect attacks targeting this issue are included in this release and are identified with GID 3, SIDs 16180 and 16181.
Microsoft Security Advisory (MS09-057):
A vulnerability in the Internet Explorer indexing service may allow a remote attacker to execute code on an affected system.
A rule to detect attacks targeting this vulnerability is included in this release and is identified with GID 3, SID 16155.
Microsoft Security Advisory (MS09-059):
A vulnerability in the Microsoft Local Security Authority Subsystem Service (LSASS) may allow a remote attacker to cause a Denial of Service (Dos) against an affected system.
A rule to detect attacks targeting this vulnerability is included in this release and is identified with GID 3, SID 16167.
Microsoft Security Advisory (MS09-060):
Multiple vulnerabilities in the Microsoft Active Template Library (ATL) ActiveX controls for Microsoft Office may allow a remote attacker to execute code on an affected system.
Previously released rules to detect attacks targeting this issue have been updated with the appropriate reference information and are included in this release and are identified with GID 1, SIDs 15638, 15639, 15670, 15671, 15904 and 15905.
Microsoft Security Advisory (MS09-061):
Multiple vulnerabilities in the Microsoft .NET Common Language Runtime may allow a remote attacker to execute code on an affected system.
Rules to detect attacks targeting these vulnerabilities are included in this release and are identified with GID 3, SIDs 16179, 16182 and 16183.
Microsoft Security Advisory (MS09-062):
Multiple vulnerabilities in Microsoft GDI+ may allow a remote attacker to execute code on an affected system.
Rules to detect attacks targeting these vulnerabilities are included in this release and are identified with GID 3, SIDs 16153, 16154, 16177, 16178 and 16184 through 16186.
Additionally, previously released rules that also detect attacks targeting these vulnerabilities have been updated with the appropriate reference information and are included in this release, identified with GID 3, SID 13878 and GID 1, SID 6700.
Adobe Vulnerabilities:
Multiple products from Adobe corporation contain vulnerabilities that may allow a remote attacker to execute code on an affected system.
Rules to detect attacks targeting these vulnerabilities are included in this release and are identified with GID 3, SIDs 16172 through 16176.
Changelogs are available here: http://www.snort.org/vrt/advisories/2009/10/13/vrt-rules-2009-10-13.html
Microsoft Security Advisory (MS09-050):
A vulnerability in the way that Microsoft Windows systems process SMBv2.0 transactions may allow a remote attacker to execute code on a vulnerable system.
A rule to detect attacks targeting this vulnerability is included in this release and is identified with GID 3, SID 16168.
Additionally, a previously released rule to detect attacks targeting this issue has been updated with the appropriate reference information and is included in this release and is identified with GID 1, SID 15930.
Microsoft Security Advisory (MS09-051):
A vulnerability in Windows Media Runtime may allow a remote attacker to execute code on a vulnerable system.
Rules to detect attacks targeting this vulnerability are included in this release and are identified with GID 3, SIDs 16157 and 16158.
Microsoft Security Advisory (MS09-052):
A vulnerability in the Windows Media Player may allow a remote attacker to execute code on an affected system.
A rule to detect attacks targeting this vulnerability is included in this release and is identified with GID 3, SID 16156.
Microsoft Security Advisory (MS09-053):
A vulnerability in the FTP service for Microsoft Internet Information Services may allow a remote attacker to execute code on an affected system.
Previously released rules to detect attacks targeting this issue have been updated with the appropriate reference information and are included in this release, they are identified with GID 1, SIDs 1973, 2374 and 15932.
Microsoft Security Advisory (MS09-054):
Microsoft Internet Explorer contains programming errors that may allow a remote attacker to execute code on an affected system.
Rules to detect attacks targeting these vulnerabilities are included in this release and are identified with GID 3, SIDs 16149 through 16152.
Microsoft Security Advisory (MS09-055):
A vulnerability in the way that ActiveX controls are handled may allow a remote attacker to execute code on a vulnerable system.
Rules to detect attacks targeting this vulnerability are included in this release and are identified with GID 1, SIDs 16159 through 16166.
Microsoft Security Advisory (MS09-056):
A vulnerability in the way that SSL certificates are handled by the Microsoft CryptAPI may allow a remote attacker to spoof a genuine certificate.
Rules to detect attacks targeting this issue are included in this release and are identified with GID 3, SIDs 16180 and 16181.
Microsoft Security Advisory (MS09-057):
A vulnerability in the Internet Explorer indexing service may allow a remote attacker to execute code on an affected system.
A rule to detect attacks targeting this vulnerability is included in this release and is identified with GID 3, SID 16155.
Microsoft Security Advisory (MS09-059):
A vulnerability in the Microsoft Local Security Authority Subsystem Service (LSASS) may allow a remote attacker to cause a Denial of Service (Dos) against an affected system.
A rule to detect attacks targeting this vulnerability is included in this release and is identified with GID 3, SID 16167.
Microsoft Security Advisory (MS09-060):
Multiple vulnerabilities in the Microsoft Active Template Library (ATL) ActiveX controls for Microsoft Office may allow a remote attacker to execute code on an affected system.
Previously released rules to detect attacks targeting this issue have been updated with the appropriate reference information and are included in this release and are identified with GID 1, SIDs 15638, 15639, 15670, 15671, 15904 and 15905.
Microsoft Security Advisory (MS09-061):
Multiple vulnerabilities in the Microsoft .NET Common Language Runtime may allow a remote attacker to execute code on an affected system.
Rules to detect attacks targeting these vulnerabilities are included in this release and are identified with GID 3, SIDs 16179, 16182 and 16183.
Microsoft Security Advisory (MS09-062):
Multiple vulnerabilities in Microsoft GDI+ may allow a remote attacker to execute code on an affected system.
Rules to detect attacks targeting these vulnerabilities are included in this release and are identified with GID 3, SIDs 16153, 16154, 16177, 16178 and 16184 through 16186.
Additionally, previously released rules that also detect attacks targeting these vulnerabilities have been updated with the appropriate reference information and are included in this release, identified with GID 3, SID 13878 and GID 1, SID 6700.
Adobe Vulnerabilities:
Multiple products from Adobe corporation contain vulnerabilities that may allow a remote attacker to execute code on an affected system.
Rules to detect attacks targeting these vulnerabilities are included in this release and are identified with GID 3, SIDs 16172 through 16176.
Changelogs are available here: http://www.snort.org/vrt/advisories/2009/10/13/vrt-rules-2009-10-13.html
Thursday, October 8, 2009
Rule release for today - October 8th, 2009
The Sourcefire VRT is aware of a vulnerability affecting Adobe Acrobat and Reader. This is currently being exploited in the wild.
A rule to detect attacks targeting this vulnerability is included in this release and is identified with GID 3, SID 16146.
See here: http://www.snort.org/vrt/advisories/2009/10/08/vrt-rules-2009-10-08.html
A rule to detect attacks targeting this vulnerability is included in this release and is identified with GID 3, SID 16146.
See here: http://www.snort.org/vrt/advisories/2009/10/08/vrt-rules-2009-10-08.html
Tuesday, October 6, 2009
Rule release for today - October 6th, 2009
Lots of additions and modifications to web-client, specific-threats, web-misc, misc, backdoor and spyware-put rule groups in this release.
Check it out here: http://www.snort.org/vrt/advisories/2009/10/06/vrt-rules-2009-10-06.html
Check it out here: http://www.snort.org/vrt/advisories/2009/10/06/vrt-rules-2009-10-06.html
Monday, October 5, 2009
Rocket Pig still images
We also took some still photos of the Rocket Pig launch from last week. Here is Rocket Pig getting launched:

And the construction and firing of the Mk 1 Big Rocket.
Matt Olney, Alex Kambis and Ryan Pentney constructing the rocket:

Matt Olney checking the rocket motors are securely held in place using state of the art sticky tape technology:

Placing the rocket on the launch pad:

Ryan making sure the connections from the firing mechanism to the rocket motors are good:

Ready for launch:

Launch:

In flight, showing the laser straight trajectory:

We'd like to show photos of the rocket after the flight, unfortunately though, we can't do that because, well, we lost it somewhere. It may be in orbit or it may be in someones backyard, we're not sure which. What we do know is that NASA is really jealous of the fact that we can launch rockets into space using one billionth of their budget.

And the construction and firing of the Mk 1 Big Rocket.
Matt Olney, Alex Kambis and Ryan Pentney constructing the rocket:

Matt Olney checking the rocket motors are securely held in place using state of the art sticky tape technology:

Placing the rocket on the launch pad:

Ryan making sure the connections from the firing mechanism to the rocket motors are good:

Ready for launch:

Launch:

In flight, showing the laser straight trajectory:

We'd like to show photos of the rocket after the flight, unfortunately though, we can't do that because, well, we lost it somewhere. It may be in orbit or it may be in someones backyard, we're not sure which. What we do know is that NASA is really jealous of the fact that we can launch rockets into space using one billionth of their budget.
Friday, October 2, 2009
Rocket Pig
Here it is, for your pleasure, Rocket Pig....
BUT WAIT, there's more....
We have bigger plans, stay tuned.
BUT WAIT, there's more....
We have bigger plans, stay tuned.
Subscribe to:
Posts (Atom)