Nytro

[h=3]Creating a simple and fast packet sniffer in C++[/h]I have seen several articles on the web about writing packet sniffers using C and C++ which suggest using raw sockets and dealing with protocol headers and endianness yourself. This is not only very tedious but also there are libraries which already deal with that for you and make it extremely easy to work with network packets. One of them is libtins, a library I have been actively developing for the past two years. It has support for several protocols, including Ethernet II, IP, IPv6, TCP, UDP, DHCP, DNS and IEEE 802.11, and it works on GNU/Linux, Windows, OSX and FreeBSD. It even works on different architectures such as ARM and MIPS, so you could go ahead and develop some application which could be executed inside routers and other devices. Let's see how you would sniff some TCP packets and print their source and destination port and addresses: #include <iostream>#include <tins/tins.h> using namespace Tins; bool callback(const PDU &pdu) { const IP &ip = pdu.rfind_pdu<IP>(); const TCP &tcp = pdu.rfind_pdu<TCP>(); std::cout << ip.src_addr() << ':' << tcp.sport() << " -> " << ip.dst_addr() << ':' << tcp.dport() << std::endl; return true; } int main() { // Sniff on interface eth0 // Maximum packet size, 2000 bytes Sniffer sniffer("eth0", 2000); sniffer.sniff_loop(callback); } This is the output I get when executing it: As you can see, it's fairly simple. Let's go through the snippet and see what it's doing: The callback function is the one that libtins will call for us each time a new packet is sniffed. It returns a boolean, whch indicates whether sniffing should go on or not, and takes a parameter of type PDU, which will hold the sniffed packet. This library represents packets as a series of Protocol Data Units(PDU) stacked over each other. So in this case, every packet would contain an EthernetII, IP and TCP PDUs. Inside callback's body, you can see that we're calling PDU::rfind_pdu. This is a member function template which looks for the provided PDU type inside the packet, and returns a reference to it. So in the first two lines we're retrieving the IP and TCP layers, and then we're simply printing the addresses and ports. Finally, in main an object of type Sniffer is constructed. When constructing it, we indicate that we want to sniff on interface eth0 and we want a maximum packet capture size of 2000 bytes. After that, Sniffer::sniff_loop is called, which will start sniffing packets and calling our callback for each of them. Note that this example will run successfully on any of the supported operating systems(as long as you use the right interface name, of course). The endianness of each of the printed fields is handled internally by the library, so you don't even have to worry about making your code work in Big Endian architectures. Now, you may be wondering whether using libtins will make your code significantly slower. If that is your concern, then you should not worry about it at all! This library was designed keeping efficiency in mind at all times. As a consequence it's the fastest packet sniffing and interpretation library I've tried out. Go ahead and have a look at these benchmarks to see how fast it actually works. If you want to learn more about libtins, please visit this tutorial, which covers everything you should know before starting to develop your network sniffing application! Posted by Matias Fontanini at 12:41 Sursa: Average coder: Creating a simple and fast packet sniffer in C++

Date: Mon, 4 Nov 2013 06:11:22 +0400 From: Solar Designer <solar@...nwall.com> To: announce@...ts.openwall.com Subject: [openwall-announce] php_mt_seed went beyond PoC Hi, With the functionality added in October, our php_mt_seed PHP mt_rand() seed cracker is no longer just a proof-of-concept, but is a tool that may actually be useful, such as for penetration testing. It is now a maintained project with its own homepage: php_mt_seed - PHP mt_rand() seed cracker Changes implemented in October, leading up to version 3.2, include addition of AVX2 and Intel MIC (Xeon Phi) support, and more importantly support for advanced invocation modes, which allow matching of multiple, non-first, and/or inexact mt_rand() outputs to possible seed values. The revised README file provides php_mt_seed usage examples (both trivial and advanced), as well as benchmarks on a variety of systems (ranging from quad-core CPU to 16-core server and to Xeon Phi): php_mt_seed: README With the new AVX2 support, php_mt_seed searches the full 32-bit seed space on a Core i7-4770K CPU in 48 seconds. On Xeon Phi 5110P, it does the same in 7 seconds. In advanced invocation modes, the running times are slightly higher, but are still very acceptable. For example, let's generate 10 random numbers in the range 0 to 9: $ php5 -r 'mt_srand(1234567890); for ($i = 0; $i < 10; $i++) { echo mt_rand(0, 9), " "; } echo "\n";' 6 6 4 1 1 2 8 4 5 8 and find the seed(s) based on these 10 numbers using our HPC Village machine's CPUs (2x Xeon E5-2670): [solar@...er php_mt_seed-3.2]$ GOMP_CPU_AFFINITY=0-31 time ./php_mt_seed 6 6 0 9 6 6 0 9 4 4 0 9 1 1 0 9 1 1 0 9 2 2 0 9 8 8 0 9 4 4 0 9 5 5 0 9 8 8 0 9 Pattern: EXACT-FROM-10 EXACT-FROM-10 EXACT-FROM-10 EXACT-FROM-10 EXACT-FROM-10 EXACT-FROM-10 EXACT-FROM-10 EXACT-FROM-10 EXACT-FROM-10 EXACT-FROM-10 Found 0, trying 1207959552 - 1241513983, speed 222870766 seeds per second seed = 1234567890 Found 1, trying 4261412864 - 4294967295, speed 222760735 seeds per second Found 1 615.57user 0.00system 0:19.28elapsed 3192%CPU (0avgtext+0avgdata 3984maxresident)k 0inputs+0outputs (0major+292minor)pagefaults 0swaps We found the correct seed (and there turned out to be only one such seed) in under 20 seconds. What if we did not know the very first mt_rand() output (had only 9 known values out of 10, in this example)? Let's specify "0 0 0 0" to have php_mt_seed skip the first output: [solar@...er php_mt_seed-3.2]$ GOMP_CPU_AFFINITY=0-31 time ./php_mt_seed 0 0 0 0 6 6 0 9 4 4 0 9 1 1 0 9 1 1 0 9 2 2 0 9 8 8 0 9 4 4 0 9 5 5 0 9 8 8 0 9 Pattern: SKIP EXACT-FROM-10 EXACT-FROM-10 EXACT-FROM-10 EXACT-FROM-10 EXACT-FROM-10 EXACT-FROM-10 EXACT-FROM-10 EXACT-FROM-10 EXACT-FROM-10 Found 0, trying 469762048 - 503316479, speed 203360193 seeds per second seed = 485860777 Found 1, trying 637534208 - 671088639, speed 203036371 seeds per second seed = 641663289 Found 2, trying 1073741824 - 1107296255, speed 202975770 seeds per second seed = 1091847690 Found 3, trying 1207959552 - 1241513983, speed 203018412 seeds per second seed = 1234567890 Found 4, trying 3388997632 - 3422552063, speed 203177316 seeds per second seed = 3414448749 Found 5, trying 4261412864 - 4294967295, speed 203117867 seeds per second Found 5 675.08user 0.00system 0:21.14elapsed 3192%CPU (0avgtext+0avgdata 4000maxresident)k 0inputs+0outputs (0major+291minor)pagefaults 0swaps We found 4 extra seeds, and the speed is slightly lower (by the way, there's much room for optimization in handling of cases like this - maybe later). The original seed value was found as well. Other (and possibly more) mt_rand() outputs could be specified and/or skipped as well, and/or ranges of possible values could be specified. The mt_rand() output range does not have to be 0 to 9, too - any other range supported by PHP's mt_rand() is also supported in php_mt_seed. Enjoy, and please spread the word. Alexander Sursa: announce - [openwall-announce] php_mt_seed went beyond PoC

[h=1]Hei, Google! Sunt eu, utilizatorul. M? mai ?ii minte?[/h] Liviu Mihai - 5 nov 2013 Drag?, Google, îmi pare r?u s?-?i spun, dar, de data asta, Bill Gates a avut dreptate. ?tiu, o mai d? ?i-n garduri, ca atunci, în 2004, când ne-a promis c? în doi ani sc?p?m definitiv de spam. Dar, legat de tine, cu p?rere de r?u î?i spun, a nimerit-o. Tot prin dou? mii ?i ceva, chiar atunci când începeai s? fii favoritul nostru ?i antiteza a tot de nu ne pl?cea la Microsoft. A spus Bill Gates atunci, ?i am sperat cu to?ii s? fie doar înc? o previziune e?uat?, c? treci prin a?a-numita er? de aur, pe care orice mare companie o traverseaz? la un moment dat, dar c? va veni o vreme când vei fi ?i tu blamat. P?rea de neconceput atunci, dar iat?-ne 10 ani mai tarziu cum ne for?ezi s?-i d?m dreptate. Ai început mai mult decât promi??tor, ca un motor de c?utare mult mai bun decât concuren?a anemic?. De-a lungul timpului ?i-ai îmbun?t??it constant algoritmul ?i ai ad?ugat numeroase func?ii auxiliare c?ut?rii. Apoi ai început marele asalt. 1 aprilie 2004. A p?rut o glum? la început ?i, probabil c? a?a au crezut ?i Microsoft ?i Yahoo!. Ai lansat Gmail pentru un num?r limitat de utilizatori, care, mai târziu, aveau s? trimit? (sau s? vând?) invita?iile dup? care toat? lumea p?rea s? râvneasc?. 1 GB pentru stocarea mail-urilor, ce nebunie! Când Yahoo! ?i Microsoft î?i d?deau 2 MB am?râ?i!?! Ai lansat ?i cump?rat servicii pe band? rulant?. Ai luat Writley ?i l-ai transformat în Google Docs. Ai lansat Google Reader cu o interfa?? monstruoas?, dar care, la primul ?i ultimul facelift, s-a dovedit un pariu câ?tig?tor. YouTube. Picasa. Feed Burner. Blogger ?i multe altele. Ai lansat chiar ?i un browser web, Chrome, de?i ai sus?inut mereu c? nu e?ti o companie de software. Apoi, o dat? cu Android, ai început asaltul pe mobile. Apple ?i-a deschis apetitul dar ?i tu ai avut destule merite proprii. Ne pl?cea de tine. Î?i p?sa de noi. ?i, dintr-o dat?, a încetat s?-?i mai pese. Ai devenit plin de tine. Ai devenit Microsoft. Sau mult mai r?u. Ai început s? închizi servicii, surd la plângerile noastre. Ai închis Wave, Answers, iGoogle, Buzz, Dictionary ?i ai culminat cu Reader. Înc? te mai boscorodesc pentru Reader. Dar nu-i asta problema. Înteleg, e vorba de bani. Afacerea ta, deciziile tale. Problema e ca nu-?i mai pas?, e?ti lipsit de orice scrupule fa?? de mine. Nu-?i mai îmbun?t??e?ti serviciile a?a des cum o f?ceai sau chiar deloc. Nu mai ai de ce. Nu ai un rival care s? te motiveze. Iar asta e r?u pentru tine, e mai r?u pentru noi. Ai ajuns s? faci schimb?ri care m? afecteaz? direct, f?r? s? mai ?ii deloc cont de nevoile ?i r?spunsul meu. Pentru c? po?i, pentru c? e?ti mare ?i tare ?i nu te mai doare de mine. Pentru c? esti r?u. Tocmai tu, cel care se d?dea bun. Nu mai e?ti Google care ne f?cea s? ciulim urechile de fiecare dat? când se scria de tine. Nu mai e?ti cel care ne f?cea s? exclam?m: "wow, ai vazut, m?, ce chestie tare a scos Google?". Acum e mai mult: “b?i, iar? ne-a tras-o Google”. Ne superi din ce în ce mai des ?i ajungem s? regret?m c? te-am ajutat s? fii în pozi?ia actual?. Începem s? c?utam alternative la serviciile tale, doar pentru c? ne deranjeaz? politica ta. Începem s? ne s?tur?m. Înainte s? ne desp?r?im definitiv, î?i mai dau o ?ans?. Pentru mine, o speran??. Doi ani, maxim trei s?-?i revii. S?-?i aduci aminte de mine. S?-?i aduci aminte de tine, cum erai cand erai tu. S? m? faci s?-mi pese din nou de tine, ca acum 10 ani. Ca atunci cand erai corect cu mine. Cand erai Google. Sursa: Hei, Google! Sunt eu, utilizatorul. M? mai ?ii minte? Mi s-a parut interesant.

[h=1]BitDefender Internet Security 2014 – licenta GRATUITA![/h] By Radu FaraVirusi(com) on November 5, 2013 BitDefender domina de cativa ani testele de specialitate, uimind prin detectia excelenta si impactul minim asupra resurselor sistemului. Acum puteti avea BitDefender Internet Security 2014 cu licenta GRATUITA printr-o promotie speciala. Accesati site-ul urmator pentru a beneficia de un an licenta gratuita: Product Page Sursa: BitDefender Internet Security 2014 – licenta GRATUITA!

Aciiiiii

"Hello World" For Windbg This post is an introductory to Windbg from an Ollydbg user's perspective. It contains an example of the "Hello World" of malware analysis; which is unpacking UPX and bypassing IsDebuggerPresent. I'm still learning Windbg but I'm hoping this post will be useful to others. I assume the reader has the Debugging Tools for Windows installed and symbols setup. The quickest way to verify that the symbols are setup properly is to try the following in Windbg File > Open Executable > notepad.exe. Once the executable loads execute !peb from the command line. We can see the symbols are not properly set up by the warning in the banner. If this is the case, the following link can be helpful in setting up the symbols and fixing them. If the symbols are setup properly we would see the following output. One of the difficult parts of learning Windbg is enumerating useful commands. Ollydbg is great because you can see all the useful commands by selecting a drop down. This isn't the case for Windbg. The best place to look up commands is Windbg Help file. It's surprisingly useful. Belowis a list of commands that I enumerated that are commonly used in debugging malware. .tlist list all running processes [*]lm list all loaded modules [*]lmf list all loaded modules - full path [*]!dlls list all loaded modules - more detailed [*]!dh address displays the headers for the specified image [*]!dh -options address no options, display all -f display file headers -s display sections headers -a display all header [*]@$exentry location of entry point [*]u unassemble [*]!SaveModule startaddress path [*]~ thread status for all threads [*]| proces status [*]!gle get last error [*]r dump registers [*]r reg=value assign register value [*]rF dump Floating point [*]k display call stack for current thread [*]!peb dump process block [*]!address [*].lastevent [*].imgscan dump al [*]bl list breakpoints [*]bc clear breakpoint, * or # [*]bd disable breakpoints [*]bp breakpoint [*]ba r/write/execute (r,w,e) size addr [*]sxe cpr break on process creation [*]sxe epr break on process exit [*]sxe ct break on thread creation [*]sxe et break on thread exit [*]sxe ld break on loading of module [*]sxe ud break on unloading of module [*]$$ print string [*]p step over [*] t step into [*]restart restarts the debugging of the executable process [*]q quit Let's explore these commands on some UPX packed C code. #include <windows.h>#include <stdio.h> int main(int argc, char *argv[]) { if (IsDebuggerPresent() == TRUE) { MessageBox(NULL, TEXT("Please close your debugging application and restart the program"), TEXT("Debugger Found!"), 0); ExitProcess(0); } MessageBox(NULL, TEXT("Hello World!"), TEXT("Bypassed"), 0); ExitProcess(0); return 0; } Source The compiled code can be downloaded from here (MD5: 4F6B57487986FD7A40CFCFA424FDB7B8). The first thing to do is File > Open Executable.. to load the sample into the debugger. Do not use the folder icon via the menu to load the executable. This will only open the executable as if we were opening it in Notepad.exe. Windbg will not break at the entry point of the executable but at what OllyDbg labels as the system breakpoint. Except Windbg breaks one instruction before OllyDbg sets it's system breakpoint. To get the address of the entry point we can read it from the portable executable (PE) header but in order to get it we have to know the base address of the executable. This is a common theme when using Windbg. In order to run one command, we have to calculate or parse the results of another command and then us as an argument. The base address is present in the output (as seen above) when the executable is first loaded in windbg. If we accidentally cleared the screen with the command.cls, the easiest way to get the base address is to execute lm (list modules) or lmf (list module with file path). To read the PE header we can use the command dh (dump headers) with an argument of the base address. The entry point of the executable will be found in the OPTIONAL HEADER VALUES. Since we have the base address (012c0000) and the entry point (79A0) we can add the two and print the assembly of the entry point using u with an argument of the address. A much quicker approach to access the address of entry point is @$exentry. Since we are at the system breakpoint, we need to set a breakpoint using the command bp with an address as the argument and then execute until the breakpoint is hit by pressing g and then enter in the command window. It is sometimes useful to dump out the register to have an idea of where we are at. Dumping the registers can be done using the command r. The pushad instruction is a good indicator that we are at the entry point of UPX. Let's dump the section headers using !dh -s address. The -s is short for section. For safe practice we should remove the breakpoint. To remove a breakpoint we first show a list of all breakpoints by using the command bl (break list) and to remove it we use command bc (break clear) with an argument of the index of the breakpoint. UPX is very easy to unpack. The classic technique is to step over pushad, set a break on access on the contents of ESP, execute till breakpoint, set a breakpoint on the jump after the restoring of the stack (SUB ESP -0x80), then execute until breakpoint and single step into the jump. Stepping into is executed by the command t. To create a break on access we use the command ba with an argument of r/w/x, size and address. To execute till the breakpoint the g command is used. Note: base address has changed to 01330000 due to restarting At address 01337b54 we can see the JMP to the original entry point of the executable. First we need to remove the breakpoint via the the bl and bc combinations of commands. Once removed we will set a breakpoint by using the command bp, execute g till breakpoint, step into t and we will be at the original entry point. Now it's time to bypass IsDebuggerPresent. The technique I'm going to use is from mmmmmm blog. Once you grasp the concepts presented in this post I'd highly recommend reading his post Games for Windows – Live. It's an excellent article on exploring anti-debugging using Windbg. What would happen if we executed our compiled code? Quick recap to unpack UPX and get back to the original entry point. .restart bp @$exentry g t bl bc 0 ba r 4 @esp bl bc 0 bp address of JMP g bl bc 0 t IsDebuggerPresent can be easily bypassed by patching the second byte of the PEB with 0. typedef struct _PEB { BYTE Reserved1[2]; BYTE BeingDebugged; BYTE Reserved2[1]; PVOID Reserved3[2]; PPEB_LDR_DATA Ldr; PRTL_USER_PROCESS_PARAMETERS ProcessParameters; BYTE Reserved4[104]; PVOID Reserved5[52]; PPS_POST_PROCESS_INIT_ROUTINE PostProcessInitRoutine; BYTE Reserved6[128]; PVOID Reserved7[1]; ULONG SessionId; } PEB, *PPEB; To patch the byte we can use eb (edit byte) with an argument of the address and the value . We can see the BeingDebugged has a value of No. If we press g to execute we can see we bypass IsDebuggerPresent(). As previously mentioned I'm still learning if you have any recommends on commands or examples please leave a comment or ping me on Twitter. Cheers. Resources windbg | mmmmmm http://www.codeproject.com/Articles/29469/Introduction-Into-Windows-Anti-Debugging http://www.codeproject.com/Articles/6084/Windows-Debuggers-Part-1-A-WinDbg-Tutorial http://windbg.info/doc/1-common-cmds.html http://www.exploit-db.com/download_pdf/18576/ Sursa: Hooked on Mnemonics Worked for Me: "Hello World" For Windbg

[h=2]Sample Code – Dictionary Zip Cracker[/h] Posted by Adam on November 4, 2013 Leave a comment (0) Go to comments After reading Violent Python, I decided to try my hand at making a basic dictionary zip cracker just for fun. Some of the other free open source tools out there are great but it does work. I’m primarily posting it for fun and to test the blog’s new syntax highlighting. It can generate a biographical dictionary from a specified file’s ASCII strings as well as populate it with a recursive directory listing. Got the idea while studying for my AccessData cert. Their Password Recovery Toolkit does this in hopes of increasing the likelihood that the dictionary will contain a relevant password. The idea is that a user either used the word in the past or that it can be found elsewhere on his or her computer. A very cool idea that’s helped me on forensics challenges. I’ve designed the code below for Python 2.7.5 on Windows 7. It uses the Strings binary from Picnix Utils. You can also click here to download a copy. import argparseimport zipfile import subprocess import os print ''' SYNTAX: Dictionary: zipdict.py -f (zip) -d (dict) Bio Dictionary Generator: zipdict.py -f (zip) -s (file with desired strings) ''' parser = argparse.ArgumentParser(description='Zip file dictionary attack tool.') parser.add_argument('-f', help='Specifies input file (ZIP)', required=True) parser.add_argument('-d', help='Specifies the dictionary.', required=False) parser.add_argument('-s', help='Build ASCII strings dictionary.', required=False) args = parser.parse_args() zipfile = zipfile.ZipFile(args.f) print '{*} Cracking: %s' % args.f print '{*} Dictionary: %s' % args.d def biodictattack(): print '{*} Generating biographical dictionary...' stringsdict = open('stringsdict', 'w') stringsout = subprocess.Popen(['strings', args.f], stdout=subprocess.PIPE, stderr=subprocess.STDOUT) for string in stringsout.stdout: stringsdict.write(string) stringsout.wait() walkpath = raw_input("Directory listing starting where? [ex. C:\] ") for root, dirs, files in os.walk(walkpath): for name in files: filenames = os.path.join(name) stringsdict.write(filenames + '\n') for root, dirs, files in os.walk(walkpath): for name in dirs: dirlisting = os.path.join(name) stringsdict.write(dirlisting + '\n') print '{*} Done. Re-run to crack with zipdict.py -f (zip) -d stringsdict' def dictattack(): dict = open(args.d, 'r') with open(args.d, 'r') as dict: for x in dict.readlines(): dictword = x.strip('\n') try: zipfile.extractall(pwd=dictword) print '{*} Password found = ' + dictword + '\n' print '{*} File contents extracted to zipdict path.' exit(0) except Exception, e: pass if args.s: biodictattack() else: dictattack() My next post will be on analyzing Volume Shadow Copies on Linux and some cool methods that I used on the 2013 DC3 Forensic Challenge. Sursa: Sample Code - Dictionary Zip Cracker | fork()

Understanding Session Fixation 1. Introduction Session ID is used to identify the user of web application. It can be sent with the GET method. An attacker can send a link to the user with predefined session ID. When the user logs in, the attacker can impersonate him, because the user uses the predefined session ID, which is known to the attacker. This is how session fixation works. As we can see, there is no need to guess the session ID because the attacker just chooses the session ID that will be used by the victim. 2. Environment Let’s analyze session fixation step by step in one of the lessons available in WebGoat [1]. WebGoat is a web application that is intentionally vulnerable. It can be useful for those who want to play with web application security stuff. The goal of WebGoat is to teach web application security lessons. WebGoat is part of the Samurai Web Testing Framework [2]. The Samurai Web Testing Framework is a Linux-based environment for web penetration testing. This aforementioned lesson is entitled “Session Fixation” (part of “Security Management Flaws”). It was created by Reto Lippuner and Marcel Wirth. 3. Session Fixation Lesson from WebGoat The attacker first sends a mail to a victim with a predefined session ID (SID). It has the value 12345 for the purpose of demonstration. The attacker has to convince the user to click the link. The victim gets the mail and is going to click the link to log in. As we can see, the link has a predefined session ID. The victim logs into the web application and is recognized by the attacker’s predefined session ID. The attacker knows the predefined session ID and is able to impersonate the user. 4. Summary Users can be impersonated when they use links with predefined session ID values chosen by the attacker. Session fixation was described and the lesson from WebGoat (“Session Fixation” from “Session Management Flaws” created by Reto Lippuner and Marcel Wirth) was presented to analyze session fixation step by step. The mitigation for session fixation would be session ID regeneration after successful log in of the user. Then the predefined session ID wouldn’t be helpful any longer to the attacker. References: [1] WebGoat https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project (access date: 22 October 2013) [2] Samurai Web Testing Framework Samurai Web Testing Framework (access date: 22 October 2013) By Dawid Czagan|October 31st, 2013 Sursa: Understanding Session Fixation - InfoSec Institute

Reverse Engineering with OllyDbg Abstract The objective of writing this paper is to explain how to crack an executable without peeping at its source code by using the OllyDbg tool. Although, there are many tools that can achieve the same objective, the beauty behind OllyDbg is that it is simple to operate and freely available. We have already done much reverse engineering of .NET applications earlier. This time, we are confronted with an application whose origin is unknown altogether. In simple terms, we are saying that we don’t have the actual source code. We have only the executable version, which is a tedious task of reverse engineering. Essentials The security researcher must have a rigorous knowledge of assembly programming language. It is expected that the machine is configured with the following tools: OllyDbg Assembly programming knowledge CFF explorer Patching Native Binaries When the source code is not provided, it is still possible to patch the corresponding software binaries in order to remove various security restrictions imposed by the vendor, as well as fixing the inherent bugs in the source code. A familiar type of restriction built into software is copy protection, which is normally forced by the software vendor in order to test the robustness of the software copy protection. In copy protection, the user is typically obliged to register the product before use. The vendor stipulates a time restriction on the beta software in order to avoid license misuse and to permit the product to run only in a reduced-functionality mode until the user registers. Executable Software The following sample shows a way of bypassing or removing the copy protection in order to use the product without extending the trial duration or, in fact, without purchasing the full version. The copy protection mechanism often involves a process in which the software checks whether it should run and, if it should, which functionality should be allowed. One type of copy protection common in trial or beta software allows a program to run only until a certain date. In order to explain reverse engineering, we have downloaded the beta version of software from the Internet that is operative for 30 days. As you can see, the following trial software application is expired and not working further and it shows an error message when we try to execute it. We don’t know in which programming language or under which platform this software is developed, so the first task is to identify its origin. We can engage CFF explorer, which displays some significant information such as that this software is developed by using VC++ language, as shown below. We can easily conclude that this is a native executable and it is not executing under CLR. We can’t use ILDASM or Reflector in order to analyze its opcodes. This time, we have to choose some different approach to crack the native executable. Disassembling with OllyDbg When we attempt to load the SoftwareExpiration.exe file, it will refuse to run because the current date is past the date on which the authorized trial expired. How can we use this software despite the expiration of the trial period? The following section illustrates the steps in the context of removing the copy protection restriction: The Road Map Load the expired program in order to understand what is happening behind the scenes. Debug this program with OllyDbg. Trace the code backward to identify the code path. Modify the binary to force all code paths to succeed and to never hit the trial expiration code path again. Test the modifications. Such tasks can also be accomplished by a powerful tool, IDA Pro, but it is commercial and not available freely. OllyDbg is not as powerful as IDA Pro, but it is useful in some scenarios. First download OllyDbg from its official website and configure it properly on your machine. Its interface looks like this: Now open the SoftwareExpiration.exe program in OllyDbg IDE from File à open menu and it will decompile that binary file. Don’t be afraid of the bizarre assembly code, because all the modifications are performed in the native assembly code. Here the red box shows the entry point instructions of the program, referred to as 00401204. The CPU main thread window displays the software code in form of assembly instructions that are executed in top-to-bottom fashion. That is why, as we stated earlier, assembly programming knowledge is necessary when reverse engineering a native executable. Unfortunately, we don’t have the actual source code, so how can we inspect the assembly code? Here the error message “Sorry, this trial software has expired” might help us to solve this problem because, with the help of this error message, we can identify the actual code path that leads to it. While the error dialog box is still displayed, start debugging by pressing F9 or from Debug menu. Now you can find the time limit code. Next, press F12 in order to pause the code execution so that we can find the code that causes the error message to be displayed. Okay. Now view the call stack by pressing the Alt+ K. Here, you can easily figure out that the trial error text is a parameter of MessageBoxA as follows: Select the USER32.MessageBoxA near the bottom of the call stack, right click, and choose “Show call”: This shows the starting point in which the assembly call to MessageBoxA is selected. Notice that the greater symbol (>) next to some of the lines of code, which indicates that another line of code jumps to that location. Directly before the call to MessageBoxA (in red color right-pane), four parameters are pushed onto the stack. Here the PUSH 10 instruction contains the > sign, which is referenced by another line of code. Select the PUSH 10 instruction located at 004011C0 address, the line of code that references the selected line is displayed in the text area below the top pane in the CPU windows as follows: Select the text area code in the above figure and right click to open the shortcut menu. It allows you to easily navigate to the code that refers to a selected line of code as shown: We have now identified the actual line of code that is responsible for producing the error message. Now it is time to do some modification to the binary code. The context menu in the previous figure shows that both 00401055 and 00401063 contains JA (jump above) to the PUSH 10 used for message box. First select the Go to JA 00401055 from the context menu. You should now be on the code at location 0×00401055. Your ultimate objective is to prevent the program from hitting the error code path. This can be accomplished by changing the JA instruction to NOP (no operation), which actually does nothing. Right click the 0×00401055 instruction inside the CPU window and select “Binary” and click over Fill with NOPs as shown below: This operation fills all the corresponding instruction for 0×00401055 with NOPs: Go back to PUSH 10 by pressing hyphen (~) and repeat the previous process for the instruction 0×00401063, as follows: Now save the modifications by right-clicking in the CPU window, clicking Copy to Executable, and then clicking All Modifications. Then hit the Copy all button in the next dialog box, as shown below: Right after hitting the “Copy all” button, a new window will appear named “SoftwareExpiration.exe.” Right-click in this window and choose Save File: Finally, save the modified or patched binary with a new name. Now load the modified program; you can see that no expiration error message is shown. We successfully defeated the expiration trial period restriction. Final Note This article demonstrates one way to challenge the strength of the copy protection measure using OllyDbg and to identify ways to make your software more secure against unauthorized consumption. By attempting to defeat the copy protection of your application, we can learn a great deal about how robust the protection mechanism is. By doing this testing before the product becomes publically available, we can modify the code to make circumvention of copy protection more difficult before its release. By Ajay Yadav|November 1st, 2013 Sursa: Reverse Engineering with OllyDbg - InfoSec Institute

Android 4.4 arrives with new security features - but do they really matter? Stefan Tanase Kaspersky Lab Expert Posted November 04, 15:53 GMT Last week, Google has released the 4.4 (KitKat) version of their omni-popular Android OS. Between the improvements, some have noticed several security-related changes. So, how much more secure is Android 4.4? When talking about Android 4.4 (KitKat) major security improvements, they can be divided into 2 categories: 1. Digital certificates Android 4.4 will warn the user if a Certificate Authority (CA) is added to the device, making it easy to identify Man-in-the-Middle attacks inside local networks. At the same time, Google Certificate Pinning will make it harder for sophisticated attackers to intercept network traffic to and from Google services, by making sure only whitelisted SSL certificates can connect to certain Google domains. 2. OS hardening SELinux is now running in enforcing mode, instead of permissive mode. This helps enforce permissions and thwart privilege escalation attacks, such as exploits that want to gain root access. Android 4.4 comes compiled with FORTIFY_SOURCE set at level 2, making buffer overflow exploits harder to implement. Privilege escalation and buffer overflows are techniques used for rooting mobile phones, so this makes it harder for Android 4.4 users to get root access on their device. On the bright side, it also makes it harder for malware to do the same, which is an important step in the infection of Android based terminals. From the point of view of malware threats, these enhancements do not really make a big difference. The most common Android infection source remains the same: unofficial apps downloaded from third-party stores. Nothing has changed here. One of the biggest problems in the Android ecosystem is the big amount of different versions of the OS, including ancient ones, that are still running on users’ mobile devices - this is known as version fragmentation. For instance, more than 25% of the users are still running Android 2.3, which has been released years ago. This between other things, represents a big security issue. Therefore, perhaps the most important change from KitKat is the lowered resource usage. Android 4.4 can run on devices with just 512MB of RAM, which for high end hardware means faster operation and better battery life, while for devices with less resources, the chance to use a modern, more secure OS. Power users have always wanted to use the latest versions of Android on their devices - that's why phone rooting has become so popular and that's why community projects such as CyanogenMod have evolved into fully-fledged companies. The real problem here, is the fact that most non-technical users will have to rely on hardware vendors to get an Android update. For instance, I have an old smartphone from a leading mobile phone maker from South Korea, that stopped receiving updates at Android 2.3.3. Sadly, many mobile phone makers prefer to withhold updates as a method of forcing users to purchase newer terminals. At the same time, this is effectively increasing the risk across their entire user base. It’s a pity this problem is not discussed in a wider manner. Sursa: https://www.securelist.com/en/blog/208214116/Android_4_4_arrives_with_new_security_features_but_do_they_really_matter

Notacon 10 - Encryption For Everyone Dru Streicher (_Node) Description: Encryption protects your privacy and is essential for communication. However encryption is sometimes complicated and hard to use. I want to discuss what encryption is, how it is used, and make it easy for everyone to use. This will be a very n00b friendly talk about how to actually use encryption in email, in websurfing, and on your hard drive. Bio I am a hardware hacker, chiptune musician (_node), and a system admin. I am a system administrator for Hurricane Labs (www.hurricanelabs.com), an information security company based in Cleveland. I am interested in security and all things opensource. I attended notacon last year for the first time and performed at pixeljam. I really had a good time last year and I would enjoy presenting a paper this year. For More Information please visit : - Notacon 11: April 10-13, 2014 in Cleveland, OH Notacon 10 (2013) Videos (Hacking Illustrated Series InfoSec Tutorial Videos) Sursa: Notacon 10 - Encryption For Everyone Dru Streicher (_Node)

Blackhat Eu 2013 - The Sandbox Roulette: Are You Ready For The Gamble? Description: What comes inside an application sandbox always stays inside the sandbox. Is it REALLY so? This talk is focused on the exploit vectors to evade commercially available sandboxes Las Vegas-style: We'll spin a "Sandbox Roulette" with various vulnerabilities on the Windows Operating System and then show how various application sandboxes hold up to each exploit. Each exploit will be described in detail and how it affected the sandbox. There is a growing trend in enterprise security practices to decrease the attack surface of vulnerable endpoints through the use of application sandboxing. Many different sandbox environments have been introduced by vendors in the security industry, including OS vendors, and even application vendors. Lack of sandboxing standards has led to the introduction of a range of solutions without consistent capabilities or compatibility and with their own inherent limitations. Moreover some application sandboxes are used by malware analysts to analyze malware and this could impose risks if the sandbox was breached. This talk will present an in-depth, security focused, technical analysis of the application sandboxing technologies available today. It will provide a comparison framework for different vendor technologies that is consistent, measurable, and understandable by both IT administrators and security specialists. In addition we will explore each of the major commercially available sandbox flavors, and evaluate their ability to protect enterprise data and the enterprise infrastructure as a whole. We will provide an architectural decomposition of sandboxing to highlight its advantages and limitations, and will interweave the discussion with examples of exploit vectors that are likely to be used by sophisticated malware to actively target sandboxes in the future. For More Information please visit : - Black Hat | Europe 2013 - Briefings Sursa: Blackhat Eu 2013 - The Sandbox Roulette: Are You Ready For The Gamble?

Error Based SQL Injection - Tricks In The Trade Trigger an error In this article I am going to describe some simple tips and tricks, which are useful to find and/or exploit error based on SQL injection. The tips/tricks will be for MySQL and PHP, because these are the most common systems you will encounter. Detect if database errors are displayed: Knowing if some database errors are displayed is a really valuable information, because it simplifies the process to detect injection points and exploiting a SQL vulnerability, we will discuss more of it later. But how do you provoke a error, even if everything is escaped correctly? Look for the integers: example: http://vulnsite.com/news.php?id=1 Let the assume id to be used internally as a integer in a MySQL query. Using testing vectors like id=1' or id=2-1 will not provoke any errors nor does the vector seem to be vulnerable to an injection. To provoke an error you can use the following values for id: 1) ?id=0X01 2) ?id=99999999999999999999999999999999999999999 The first example is a valid integer in PHP but not in MySQL, because of the uppercase X (there are even more difference, check PHP: Integers - Manual vs !!!). That's why this value provokes an error in the database. The second example will be converted by PHP to INF (which is also a integer in PHP , but it is definitely not a valid integer in the MySQL database. As an example, the query will look like this: SELECT title,text from news where id=INF By using this method, it is easy to determine if error reporting is enabled. This method will only work if the value is used internally as a integer. It won't provoke a database error if the value is used as a string! Using error reporting to our advantage: After getting the information that database errors are displayed, how can we use them for our advantage. In MySQL, it is not that easy in comparison to other DBMS to extract information via error reports. But there are two methods to do so: o) UPDATEXML and extractValue o) insane select statement Personally, I prefer using UPDATEXML( it is available since MySQL v. 5.1.5). Like its name suggest that it is used to modify a xml fragment, by specifying a XPATH expression. It has three parameters, the first one is the xml fragment, the second one the XPATH expression and the third one specifies the new fragment which will be inserted. A “normal” example: SELECT UpdateXML('<a><b>ccc</b><d></d></a>', '/b', '<e>fff</e>') Output: <a><b>ccc</b><d></d></a> What do you think will happen, if you specify a illegal xpath expression, like the @@version? Lets take a real life example to see what happens. Let us assume that the num parameter in the following url: http://example.com/author.php?num=2 ends up unescaped in the following query: SELECT name,date,username from author where number=2 Normally you would try to find the number of columns to construct a valid UNION SELECT. But lets assume none of the data are passed back to the webpage. You would need techniques like time based(sleep) or off-band (DNS etc.) to extract information. If error reporting is enabled, UPDATEXML can shorten this process a lot. To extract the version of the database, the following value for num would be enough: http://example.com/author.php?num=2 and UPDATEXML(null,@@version,null) ==> SELECT name,date,username from author where number=2 and UPDATEXML(null,@@version,null) This will produce an XPATH Syntax Error: `version´ It is also possible to create a complete select statement: UPDATEXML(null,(select schema_name from information_schema.schemata),null) Although UPDATEXML seems like a really awesome function it has a drawback too. It can only extract the last 20 bytes at a time. If you want to extract more bytes and still use error based extraction, you have to use the second method. The next example will create a query, which will create duplicate entry error. The duplicate entry will be the name of a table: select 1 from dual where 1=1 AND(SELECT COUNT(*) FROM (SELECT 1 UNION SELECT null UNION SELECT !1)x GROUP BY CONCAT((SELECT table_name FROM information_schema.tables LIMIT 1 OFFSET 1),FLOOR(RAND(0)*2))) That's all for now, but if you want to read on, here are some interesting links regarding SQL injection: -) The SQL Injection Knowledge Base (? Examples where taken from there, really the best sql injection cheat sheet IMHO) -) Methods of Quick Exploitation of Blind SQL Injection -) SQLi filter evasion cheat sheet (MySQL) | Reiners' Weblog About The Author Alex Infuhr is an independent security researcher, His core area of research includes Malware analysis and WAF bypassing. Sursa: Error Based SQL Injection - Tricks In The Trade | Learn How To Hack - Ethical Hacking and security tips

Raspunsul e simplu: Un hacker NU este infractor. Sunt 2 tipuri de persoane: 1. Persoanele care descopera/creaza lucruri noi: hackeri 2. Persoanele care le folosesc: altii Cu alte cuvinte: - ai descoperit o noua metoda de SQL Injection: time based, error based... Esti hacker. - ai folosit o astfel de metoda sa obtii acces si sa te lauzi ca esti smecher: esti o pula bleaga Faptul ca un personaj descopera o noua metoda de exploatare, sa zicem time based SQLI, sau creaza ceva util, sa zicem Metasploit/nmap... nu il face infractor, il face hacker. Faptul ca un alt personaj se foloseste de acea descoperire pentru a obtine adrese de mail, useri si parole, nu il face hacker, ci il face infractor. La fel, faptul ca un personaj foloseste Metasploit pentru a obtine ceva ilegal (generic vorbind), nu il face hacker ci infractor. Asta e pe scurt ideea.

Sunt banii tai?

Mori tigane.

PHP trebuie sa fie instalat ca cgi. Si nu prea e. Si daca e, e pe servere foarte vechi.

Poate o sa par prost, dar ce sunt "Joint Ventures"?

Nu arata rau deloc

As prefera sa dati adresele de mail pe PM daca se poate. Spre binele vostru zic. Apoi, poate nu va dati si voi adresa de mail "personala". Spre binele vostru zic.

Da, bravo, esti printre putinele persoane care mai fac cate ceva... Daca ai timp, chiar daca gasesti sursa pentru o anumita functionalitate, incearca sa o faci tu singur. Chiar daca intelegi perfect o sursa, nu este de ajuns pana nu scrii tu linie cu linie. Iti mai sugerez sa incerci C# sau chiar C++.

Si zici ca ai facut tu "Remote Desktop"?

E mult prea mic intervalul, pune cel putin cateva milisecunde, nu microsecunde. E foarte posibil ca mecanismul de thread schedueling sa dureze mai mult (task switch-ul, salvarea registrilor si schimbarea pe un alt thread). De asemenea: usleep(3) - Linux man page [h=2]Errors[/h] EINTR Interrupted by a signal; see signal(7). EINVAL usec is not smaller than 1000000. (On systems where that is considered an error.) 4.3BSD, POSIX.1-2001. POSIX.1-2001 declares this function obsolete; use nanosleep(2) instead. POSIX.1-2008 removes the specification of usleep(). Cel mai probabil system call-ul dureaza mai mult decat sleep-ul propriu-zis. Radem, glumim, dar suntem si seriosi

Meet “badBIOS,” the mysterious Mac and PC malware that jumps airgaps Like a super strain of bacteria, the rootkit plaguing Dragos Ruiu is omnipotent. by Dan Goodin - Oct 31 2013 Aurich Lawson / Thinkstock Three years ago, security consultant Dragos Ruiu was in his lab when he noticed something highly unusual: his MacBook Air, on which he had just installed a fresh copy of OS X, spontaneously updated the firmware that helps it boot. Stranger still, when Ruiu then tried to boot the machine off a CD ROM, it refused. He also found that the machine could delete data and undo configuration changes with no prompting. He didn't know it then, but that odd firmware update would become a high-stakes malware mystery that would consume most of his waking hours. In the following months, Ruiu observed more odd phenomena that seemed straight out of a science-fiction thriller. A computer running the Open BSD operating system also began to modify its settings and delete its data without explanation or prompting. His network transmitted data specific to the Internet's next-generation IPv6 networking protocol, even from computers that were supposed to have IPv6 completely disabled. Strangest of all was the ability of infected machines to transmit small amounts of network data with other infected machines even when their power cords and Ethernet cables were unplugged and their Wi-Fi and Bluetooth cards were removed. Further investigation soon showed that the list of affected operating systems also included multiple variants of Windows and Linux. "We were like, 'Okay, we're totally owned,'" Ruiu told Ars. "'We have to erase all our systems and start from scratch,' which we did. It was a very painful exercise. I've been suspicious of stuff around here ever since." In the intervening three years, Ruiu said, the infections have persisted, almost like a strain of bacteria that's able to survive extreme antibiotic therapies. Within hours or weeks of wiping an infected computer clean, the odd behavior would return. The most visible sign of contamination is a machine's inability to boot off a CD, but other, more subtle behaviors can be observed when using tools such as Process Monitor, which is designed for troubleshooting and forensic investigations. Another intriguing characteristic: in addition to jumping "airgaps" designed to isolate infected or sensitive machines from all other networked computers, the malware seems to have self-healing capabilities. "We had an air-gapped computer that just had its [firmware] BIOS reflashed, a fresh disk drive installed, and zero data on it, installed from a Windows system CD," Ruiu said. "At one point, we were editing some of the components and our registry editor got disabled. It was like: wait a minute, how can that happen? How can the machine react and attack the software that we're using to attack it? This is an air-gapped machine and all of the sudden the search function in the registry editor stopped working when we were using it to search for their keys." Over the past two weeks, Ruiu has taken to Twitter, Facebook, and Google Plus to document his investigative odyssey and share a theory that has captured the attention of some of the world's foremost security experts. The malware, Ruiu believes, is transmitted though USB drives to infect the lowest levels of computer hardware. With the ability to target a computer's Basic Input/Output System (BIOS), Unified Extensible Firmware Interface (UEFI), and possibly other firmware standards, the malware can attack a wide variety of platforms, escape common forms of detection, and survive most attempts to eradicate it. But the story gets stranger still. In posts here, here, and here, Ruiu posited another theory that sounds like something from the screenplay of a post-apocalyptic movie: "badBIOS," as Ruiu dubbed the malware, has the ability to use high-frequency transmissions passed between computer speakers and microphones to bridge airgaps. Bigfoot in the age of the advanced persistent threat At times as I've reported this story, its outline has struck me as the stuff of urban legend, the advanced persistent threat equivalent of a Bigfoot sighting. Indeed, Ruiu has conceded that while several fellow security experts have assisted his investigation, none has peer reviewed his process or the tentative findings that he's beginning to draw. (A compilation of Ruiu's observations is here.) Also unexplained is why Ruiu would be on the receiving end of such an advanced and exotic attack. As a security professional, the organizer of the internationally renowned CanSecWest and PacSec conferences, and the founder of the Pwn2Own hacking competition, he is no doubt an attractive target to state-sponsored spies and financially motivated hackers. But he's no more attractive a target than hundreds or thousands of his peers, who have so far not reported the kind of odd phenomena that has afflicted Ruiu's computers and networks. In contrast to the skepticism that's common in the security and hacking cultures, Ruiu's peers have mostly responded with deep-seated concern and even fascination to his dispatches about badBIOS. "Everybody in security needs to follow @dragosr and watch his analysis of #badBIOS," Alex Stamos, one of the more trusted and sober security researchers, wrote in a tweet last week. Jeff Moss—the founder of the Defcon and Blackhat security conferences who in 2009 began advising Department of Homeland Security Secretary Janet Napolitano on matters of computer security—retweeted the statement and added: "No joke it's really serious." Plenty of others agree. "Dragos is definitely one of the good reliable guys, and I have never ever even remotely thought him dishonest," security researcher Arrigo Triulzi told Ars. "Nothing of what he describes is science fiction taken individually, but we have not seen it in the wild ever." Been there, done that Triulzi said he's seen plenty of firmware-targeting malware in the laboratory. A client of his once infected the UEFI-based BIOS of his Mac laptop as part of an experiment. Five years ago, Triulzi himself developed proof-of-concept malware that stealthily infected the network interface controllers that sit on a computer motherboard and provide the Ethernet jack that connects the machine to a network. His research built off of work by John Heasman that demonstrated how to plant hard-to-detect malware known as a rootkit in a computer's peripheral component interconnect, the Intel-developed connection that attaches hardware devices to a CPU. It's also possible to use high-frequency sounds broadcast over speakers to send network packets. Early networking standards used the technique, said security expert Rob Graham. Ultrasonic-based networking is also the subject of a great deal of research, including this project by scientists at MIT. Of course, it's one thing for researchers in the lab to demonstrate viable firmware-infecting rootkits and ultra high-frequency networking techniques. But as Triulzi suggested, it's another thing entirely to seamlessly fuse the two together and use the weapon in the real world against a seasoned security consultant. What's more, use of a USB stick to infect an array of computer platforms at the BIOS level rivals the payload delivery system found in the state-sponsored Stuxnet worm unleashed to disrupt Iran's nuclear program. And the reported ability of badBIOS to bridge airgaps also has parallels to Flame, another state-sponsored piece of malware that used Bluetooth radio signals to communicate with devices not connected to the Internet. "Really, everything Dragos reports is something that's easily within the capabilities of a lot of people," said Graham, who is CEO of penetration testing firm Errata Security. "I could, if I spent a year, write a BIOS that does everything Dragos said badBIOS is doing. To communicate over ultrahigh frequency sound waves between computers is really, really easy." Coincidentally, Italian newspapers this week reported that Russian spies attempted to monitor attendees of last month's G20 economic summit by giving them memory sticks and recharging cables programmed to intercept their communications. Eureka For most of the three years that Ruiu has been wrestling with badBIOS, its infection mechanism remained a mystery. A month or two ago, after buying a new computer, he noticed that it was almost immediately infected as soon as he plugged one of his USB drives into it. He soon theorized that infected computers have the ability to contaminate USB devices and vice versa. "The suspicion right now is there's some kind of buffer overflow in the way the BIOS is reading the drive itself, and they're reprogramming the flash controller to overflow the BIOS and then adding a section to the BIOS table," he explained. He still doesn't know if a USB stick was the initial infection trigger for his MacBook Air three years ago, or if the USB devices were infected only after they came into contact with his compromised machines, which he said now number between one and two dozen. He said he has been able to identify a variety of USB sticks that infect any computer they are plugged into. At next month's PacSec conference, Ruiu said he plans to get access to expensive USB analysis hardware that he hopes will provide new clues behind the infection mechanism. He said he suspects badBIOS is only the initial module of a multi-staged payload that has the ability to infect the Windows, Mac OS X, BSD, and Linux operating systems. Dragos Ruiu Julia Wolf "It's going out over the network to get something or it's going out to the USB key that it was infected from," he theorized. "That's also the conjecture of why it's not booting CDs. It's trying to keep its claws, as it were, on the machine. It doesn't want you to boot another OS it might not have code for." To put it another way, he said, badBIOS "is the tip of the warhead, as it were." “Things kept getting fixed” Ruiu said he arrived at the theory about badBIOS's high-frequency networking capability after observing encrypted data packets being sent to and from an infected laptop that had no obvious network connection with—but was in close proximity to—another badBIOS-infected computer. The packets were transmitted even when the laptop had its Wi-Fi and Bluetooth cards removed. Ruiu also disconnected the machine's power cord so it ran only on battery to rule out the possibility it was receiving signals over the electrical connection. Even then, forensic tools showed the packets continued to flow over the airgapped machine. Then, when Ruiu removed internal speaker and microphone connected to the airgapped machine, the packets suddenly stopped. With the speakers and mic intact, Ruiu said, the isolated computer seemed to be using the high-frequency connection to maintain the integrity of the badBIOS infection as he worked to dismantle software components the malware relied on. "The airgapped machine is acting like it's connected to the Internet," he said. "Most of the problems we were having is we were slightly disabling bits of the components of the system. It would not let us disable some things. Things kept getting fixed automatically as soon as we tried to break them. It was weird." It's too early to say with confidence that what Ruiu has been observing is a USB-transmitted rootkit that can burrow into a computer's lowest levels and use it as a jumping off point to infect a variety of operating systems with malware that can't be detected. It's even harder to know for sure that infected systems are using high-frequency sounds to communicate with isolated machines. But after almost two weeks of online discussion, no one has been able to rule out these troubling scenarios, either. "It looks like the state of the art in intrusion stuff is a lot more advanced than we assumed it was," Ruiu concluded in an interview. "The take-away from this is a lot of our forensic procedures are weak when faced with challenges like this. A lot of companies have to take a lot more care when they use forensic data if they're faced with sophisticated attackers." Sursa: Meet “badBIOS,” the mysterious Mac and PC malware that jumps airgaps | Ars Technica

The Teredo Protocol: Tunneling Past Network Security and Other Security Implications Dr. James Hoagland Principal Security Researcher Symantec Advanced Threat Research Contents Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 Overview: How Teredo works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 Teredo components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 Teredo setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9 Teredo addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10 Origin data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10 Qualification procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 Secure qualification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 Bubble packets and creating a NAT hole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13 Packet relaying and peer setup for non-Teredo peers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 Finding a relay from IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 Ping test and finding a relay from IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 Packet relaying and peer setup for Teredo peers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 Trusted state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 Required packet filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17 Teredo security considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 Security of NAT types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 Teredo’s open-ended tunnel (a.k.a. extra security burden on end host) . . . . . . . . . . . . . . . . . . . . . .19 Allowed packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 Teredo and IPv6 source routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 IPv4 ingress filtering bypass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22 Teredo and bot networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22 Teredo implications on ability to reach a host through a NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . .22 Information revealed to third parties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 Symantec Advanced Threat Research The Teredo Protocol Tunneling Past Network Security and Other Security Implications Contents (cont’d) Teredo anti-spoofing measures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 Peer address spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 Server spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 Denial of Teredo service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 Storage-based details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 Relay DOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 Server DOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 Scanning Teredo addresses compared with native IPv6 addresses . . . . . . . . . . . . . . . . . . . . . . . . . .28 Finding a Teredo address for a host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 Finding any Teredo address for an external IPv4 address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29 Finding any Teredo address on the Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29 Scanning difficulties compared . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30 The effect of Teredo service on worms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30 Attack pieces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31 Getting Teredo components to send packets to third parties . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31 Inducing a client to make external connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31 Selecting a relay via source routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32 Finding the IPv4 side of an IPv6 node’s relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32 Teredo mitigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36 Download: http://www.symantec.com/avcenter/reference/Teredo_Security.pdf