Nytro

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

[h=1]WordPress Pingback Vulnerability Can Be Abused for DDOS Attacks[/h]December 18th, 2012, 14:15 GMT · By Eduard Kovacs A security hole in WordPress’ Pingback system – a mechanism utilized by web authors to know when someone links to one of their documents – can be leveraged by cybercriminals to launch distributed denial-of-service (DDOS) attacks. According to Bogdan Calin of Acunetix, the WordPress XMLRPC API, which can be accessed via the xmlrpc.php file, can be abused not only for DDOS attacks, but also to find out if a host exists on the internal network, to port scan hosts inside the network, and even to reconfigure an internal router. The expert reveals that users can only protect themselves by renaming or deleting the xmlrpc.php file. The vulnerability was reported to Automattic, the developers of WordPress, around 6 years ago, but the ticket was closed at the time after someone argued that “there are so many ways to orchestrate a DDOS attack.” Five days ago, the ticket was re-opened after a script that took advantage of the Pingback API was released. Sursa: http://news.softpedia.com/news/WordPress-Pingback-Vulnerability-Can-be-Abused-for-DDOS-Attacks-315722.shtml

[h=1]ExploitShield Browser Edition[/h]by Black on December 17, 2012 ExploitShield Browser Edition is the first ever install and forget vulnerability-agnostic anti-exploit solution. The type of malicious behavior we are interested in testing is basically malicious drive-by download infections from exploit kits (Blackhole Exploit Kit, Phoenix, Incognito, Eleonore, Sakura, etc.). These type of exploit kits incorporate a variety of exploits for different vulnerable applications such as the browsers themselves, Java, Acrobat Reader, etc. Usability testing encompasses using a shielded application while ExploitShield is running and using all its features to make sure no adverse effect is noticed. Testers should click and use all possible options of the shielded application, especially updating and upgrading of the applications. The list of applications we are interested in testing are the following: - Web browsers (Internet Explorer, Firefox, Chrome, Opera) - Media players (Windows Media Player, VLC, QuickTime, Winamp) - Microsoft Office (Word, Excel and Powerpoint) - PDF readers (Adobe Acrobat, Reader & Foxit Reader) [h=2]Tutorial on ExploitShield Browser Edition[/h] [h=3]Download ExploitShield Browser Edition:[/h] ExploitShield Browser Edition 0.8.1 beta – ExploitShield-Setup.exe Sursa: http://www.pentestit.com/exploitshield-browser-edition/

[h=1]Virtualization Security[/h]Terry Komperda December 17, 2012 ABSTRACT Virtualization has made a huge impact in a very short time in the IT and networking worlds and has already provided huge cost savings and returns on investments for data centers, enterprises and the Cloud. What seems to be less substantial and lagging is the understanding of virtualization and virtualized environments from a security point of view. Some people think that virtualization is more secure than traditional environments because they’ve heard of isolation between virtual machines (VMs) and because they haven’t heard of any successful attacks on hypervisors. Others think that the new virtualized environment needs security just like traditional physical environments and therefore apply the same long standing approaches to securities that are already in place. The bottom line is that the new environment is more complex, and virtualization approaches added to current networks creates a new network that needs a new approach to security. This should include traditional security as well as additional security for virtualization. This paper attempts to identify the differences, issues, challenges, risks, etc. caused by virtualization, and looks to provide sound recommendations and best practices to make sure that this addition to the network is just as secure as the network before the addition of virtualization. INTRODUCTION Virtualization has taken off and is here to stay. Although it is a concept that goes back some fifty years, the technology will still grow and advance for applications that present themselves now and into the future. In fact, half of all server loads run on VMs today1. IDC predicts that 70% of all workloads will run on VMs by 20142. What needs to keep up with the technology advances and the widespread deployment is the security of virtualization components and virtualized environments. Let’s take a look at some of the security benefits that are present thanks to virtualization. SECURITY BENEFITS DUE TO VIRTUALIZATION The following are some of the benefits to security once virtualization is introduced into the environment: Centralized storage used in virtualized environments prevents a loss of important data if a device is lost, stolen or compromised. When VMs and applications are properly isolated, only one application on one OS is affected by an attack. When configured properly, a virtual environment provides flexibility in that it allows the sharing of systems without necessarily having to share critical information across the systems. If a VM is infected, it can be rolled back to a prior “secure” state that existed before the attack. Hardware reductions that occur due to virtualization improve physical security since there are fewer devices and ultimately fewer data centers. Desktop virtualization can be deployed to better control the user environment. An administrator can create and control a “golden image” that can be sent down to users’ computers. This technology provides better control of the OS to ensure that it meets organizational requirements as well as security policies. Server virtualization can lead to better incident handling since servers can revert back to a previous state in order to examine what occurred before and during an attack. The system and network administration’s access control as well as separation of duties can be improved as certain individuals may be assigned to only control VMs within the network while others only deal with VMs in the DMZ. You can also have certain administrators deal with Windows servers only for example, while others deal with Linux servers. Hypervisor software is small and not really complex and this provides for a smaller attack surface on the hypervisor itself. The smaller the attack surface and things running, the less potential vulnerabilities. Virtual Switches (vswitches) don’t perform the dynamic trunking necessary to conduct Inter-switch link tagging attacks. They also drop double encapsulated packets so double encapsulation attacks aren’t effective. Vswitches also don’t allow packets to leave their assigned broadcast domain so they nullify the multicast brute force attacks that rely on overloading switches to let packets broadcast to other VLAN domains. Notice that I’ve qualified a number of the above benefits with statements like “if configured or set up properly.” Virtualization is very complex so it must be secures properly to gain the above benefits. SECURITY CHALLENGES, RISKS AND ISSUES WITH VIRTUALIZATION Now that we have seen some of the possible security benefits to virtualization, we can look at some of the challenges, risks and issues related to virtualization. 4.1 File Sharing Between Hosts and Guests - When file sharing is used, a compromised guest can access the host file system and modify or change the directories that are used for sharing. - When clipboard sharing and drag and drop are used by the guest and host, or when APIs are used for programming, substantial bugs in these areas can end up compromising the whole infrastructure. 4.2 Snapshots - When snapshots are reverted, any configuration changes that you made are lost. If you changed security policy, things may now be accessible. Audit logs can also be lost, which would eliminate any record of changes that you may have made on the server. These unfortunate results can make it difficult to meet compliance requirements. - Images and snapshots contain proprietary data like personally identifiable information (PII) and passwords, much like a physical hard drive would. Any unnecessary or additional images could really be a cause for concern. Any snapshots that were stored that had undetected malware could be reloaded at a future date and cause havoc. 4.3 Network Storage - Fibre Channel and iSCSI are clear text protocols and could be vulnerable to man-in-the-middle attacks. Sniffing tools could be used to read or record storage traffic and this could be used to do some re-assembly in the future at the attacker’s convenience. - There tends to be a tradeoff between Fibre Channel performance and its security. Encryption can be used on the host bus adapters used in Fibre channel implementations, but many times it’s not used due to the negative performance issues that occur. 4.4 Hypervisor - If the hypervisor is compromised, any attached VMs will also be compromised, and the default configuration on the hypervisor isn’t always the most secure. - The hypervisor controls everything and provides a single point of failure in the virtual environment. A single breach can put the whole environment in jeopardy. - Bare metal hypervisors usually have access control included while hosted virtualization (hypervisor placed onto a physical server OS) doesn’t. Hosted virtualization exposes the system to more threats due to the presence of the host OS. - An administrator on the hypervisor can do just about anything (has “all the keys to the kingdom”). Hypervisors typically have password provisions but these can easily be shared among admins so you don’t truly know who did what. - Hypervisors can allow VMs to communicate amongst themselves, and this communication won’t even go onto the physical network. This ends up acting like a private network for the VMs. This traffic can’t always be seen as it’s carried by the hypervisor, and you can’t secure what you don’t know about! 4.5 Virtual Machines - VMs are small enough and easy enough to copy to a remote computer or portable storage device. Loss of the data on the VM would be equivalent to breaking into a data center, bypassing the physical security, and stealing a physical server. - User installed VMs don’t always comply with an organization’s security policy and may not have any security software on them. Product trials and games are now being offered on free VM players and these get installed and enter the corporate network with possible vulnerabilities. - VMs that are created typically start with ports open and numerous protocols available. - Every time a VM is created, another OS is added that needs to be protected, patched, upgraded and maintained. Additional OS with related issues can increase risk. - Inactive VMs or VMs no longer used (Dormant VMs) can still contain important data like credentials and configuration information. - Any clipboard functionality that allows for data to be shared between VMs and the host can be an entrance ramp for malware to be transferred to VMs in different security domains. - VMs that are not isolated can have full access to host resources. Any compromise of the VM can lead to a compromise of the resources. - VMs can be created by users without the knowledge of the IT organization. If these VMs are not noticed, they are not going to be protected. - Infecting a VM can lead to infecting data stores, and other VMs may be using these same data stores. - VMs can grow very quickly, and this can put a strain on the security systems. If not effectively automated, the admin burden can increase in relation to upgrades, patches, etc. - Infected VMs can appear, infect other VMs then disappear before they’re noticed. 4.6 Separation of Duties and Administrator Access - In typical physical networks, server admins handle management of servers, while network admins handle network management. Security personnel typically work with both of these admins. In virtualized environments, server and network management can occur on the same management console and this presents new challenges for effective separation of duties. - By default, many virtualization systems give full access to all virtual infrastructure activity. These defaults don’t always get changed, and a breach of this admin access can provide full control of the virtual infrastructure. 4.7 Time Synchronization - VM clocks can drift, and when this is combined with other normal clock drift, tasks can run early or late that would cause logs to lose any semblance of accuracy. Inaccurate time tracking will provide insufficient data for any future forensic investigations. 4.8 VLANs - Using VLANs requires routing VM traffic out of the host to a firewall, for example. This can lead to latency and complex networking that can cause problems with performance. - Inter-VM communication isn’t secured or inspected on a VLAN. Also, when many VMs are on the same VLAN, the spread of malware from one VM to the others can’t be stopped. 4.9 Partitions - It’s perceived that when multiple VMs are running on the same host, they are isolated and can’t be used to attack other VMs. Technically, the VMs may be separated, but the partitions on the VMs share resources like memory, CPU and bandwidth. If a partition consumes an inordinate amount of one of these resources, because of a virus for example, a denial of service can occur on the other partitions3. 4.10 Other Issues - At times, security is kept in the heads of security personnel or in checklists, and if this is the prevalent approach, it will be hard to keep up with virtualization security due to the speed of VM creation, moves, etc. - Virtualization is heavily software based, and this provides more potential software vulnerabilities and attack surfaces for attackers to prey on. - Virtual disks are typically stored as unencrypted files on a host and gaining access to them is just like having legitimate access to them. - Workloads with different trust levels may be placed on the same server or vswitch and the security of these workloads will only be as secure as the least secure workload. If sensitive data resides on this server, it may not be very secure. Despite the myriad issues identified above, virtualization isn’t inherently unsecure, but the way it’s being deployed may be through an unsecure nature. Immature security policies and processes, as well as lack of training, may be the bigger cause of issues and vulnerabilities which may lead to greater risk. Now that we know something about security issues related to virtualization, we can look at some of the common attacks. COMMON VIRTUALIZATION ATTACKS The following are some of the common, known attacks with virtualization: 5.1 Denial of Service (DoS) A successful DoS attack here can lead to a shutdown of the hypervisor. This can lead to the ability to add a backdoor to allow access to the VMs underneath the hypervisor. 5.2 VM Jumping If a security hole in the hypervisor occurs and is found, a user logged into one VM can hop over to another VM and gain access to it to look at information or acquire it. 5.3 Host Traffic Interception Vulnerabilities in the hypervisor can allow for tracking of system calls, paging files, and monitoring of memory and disk activity. APPLYING TRADITIONAL PHYSICAL ENVIRONMENT SECURITY APPROACHES TO VIRTUALIZATION Many of the issues and attacks encountered in virtualization can be addressed by employing existing people, processes and technology. But, what can’t be protected with existing solutions is the virtual fabric composed of hypervisors, management systems and virtual switches. The following are some of the traditional approaches applied to virtualization and their related shortcomings: 6.1 Firewalls Some IT groups send traffic between VMs to standard firewalls that will inspect the traffic and send it back to the VMs. Traditional firewalls were designed before virtualization was deployed in data centers and enterprises, and are therefore not necessarily tailored to the virtual infrastructure and related management systems. This can lead to manual deployment and administration which can then lead to errors. These standard firewalls also won’t provide protection if or when VMs move. 6.2 Network Based Intrusion Detection/Intrusion Prevention Systems These devices don’t work well when multiple VMs reside on a host. It’s mainly because the IDS/IPS systems can’t monitor the traffic between the VMs. They also can’t access any data when applications are moved. 6.3 Limiting the Number of VMs per Host/Assigned to Physical NICs This approach not only limits the number of VMs to be placed on a host, but also assigns a physical NIC to each VM. Although this may end up being a secure approach and has the right security intent in mind, it doesn’t allow the firm to gain all of the cost benefits and ROI related to virtualization. 6.4 VLANs VLANs are used extensively whether you’re talking non-virtualized environments or environments with a good degree of virtualization. The problem here is that as the number of VLANs grow, it gets harder to manage complexities related to access control lists, and the compatibility of the network security policy between the non-virtualized and virtualized aspects of the environment. 6.5 Agent Based Anti-Virus Approaches This entails loading a complete copy of anti-virus software on each VM. This approach can provide good protection, but at an enormous cost for all of the anti-virus copies across all of the VMs in the environment. This fully featured software can also impact memory, storage and the CPU in a negative manner, as it increases hardware utilization which therefore leads to a decrease in performance. Despite the above mentioned drawbacks to applying traditional security, 60% of respondents indicated that they use traditional security solutions to secure virtual environments4. Virtualized environments are dynamic and change quickly, and it’s hard for traditional security approaches alone to keep up, move and change accordingly. A better approach is to keep the good aspects of current security approaches while looking at the following additional best practices and recommendations for virtualization. 7. RECOMMENDATIONS AND BEST PRACTICES FOR SECURE VIRTUALIZATION 7.1 Administrator Access and Separation of Duties - Provide server admins with on/off rights for their servers only and no others. - You may want to give admins the right to deploy new VMs but not modify existing VMs. Other admins can then be able to modify existing VMs but not create new ones. - Separate authentication should be in place for each guest OS unless there’s a good reason for two or more guest OS to share credentials. - It may seem contrary to common thought, but the larger the environment, the easier it is to separate duties across functions. One admin can’t manage storage, domains, the virtualized infrastructure and the network all at once. 7.2 Desktop Virtualization and Security The following are five effective measures for making sure that unauthorized and unsecured virtualization doesn’t exist in the environment5: Update Acceptable Use Policy Spell out the exact conditions under which virtualization software can be installed and define what approvals are required. State what software can be run and how it should be protected. Spell out the repercussions that employees can expect if they don’t follow the rules. Limit the Use of VMs to the Users That Need Them Most users won’t need VMs on their desktops. Forbid the installation of freely downloadable software on corporate desktops and laptops. Limit permissions to a small group of developers and testers for virtual tools and VMs, and help them understand that they still have to conform to corporate security policies. Keep Virtualization and Security Software Up to Date Ensure all of the VMs contain the same firewalls, anti-virus and IDS/IPS as the physical desktops and laptops. Choose Security Policies That Support Virtualization Make sure that there aren’t any known security policy conflicts with existing virtualization platforms. Create and Maintain a Library of Secure VM Builds Maintain a repository of VM builds containing all of the configuration settings, security software and patches that users can download, use and re-use. 7.3 Network Security - Disconnect any unused NICs so that there isn’t an easy way to get onto the network. - Make sure that the host platform that connects the hypervisor and guests to the physical network is secure by setting file permissions, putting things in place to control users and groups, and setting up logging and time synchronization. - Encrypt all traffic between clients and hosts, between management systems and the hypervisor, and between the hypervisor and hosts using SSL. - Secure IP communications between two hosts by using authentication and encryption on each IP packet. - Do not use default self-signed certificates as they’re vulnerable to man-in-the-middle attacks. - Place virtual switches into promiscuous mode for monitoring purposes and enable MAC address filtering to prevent MAC spoofing attacks. 7.4 Storage Networks - iSCSI and NFS should be placed on dedicated storage networks or non-routable VLANs. - Use IPSec to encrypt iSCSI traffic to prevent snooping. - iSCSI supports Challenge Handshake Authentication Protocol (CHAP) and this should be used to force authentication prior to granting access. - When using iSCSI or NFS, use physical switches to detect and disallow IP or MAC address spoofing. - NFS is easy to set up but is the least secure storage choice. Configure the NFS server to restrict access to specific IP addresses related to your hypervisors or use a firewall to restrict traffic to specific hosts. If the NFS server supports IPSec, use it to secure traffic between the NFS server and the hypervisors. - All traffic to and from storage repositories needs to be isolated from non-storage traffic. - Do not send Fibre Channel traffic over Ethernet (FCOE) as this combines data storage traffic with other data types. - Security for Fibre Channel uses zoning, which is basically access control at the switch level and is similar to VLANs. Although numerous topologies are available, its simplest secure form is single initiator zoning. This involves a host bus adapter in its own zone with a target device to prevent initiators from trying to communicate with each other. 7.5 Disaster Recovery - Maintain your production firewall, security posture and IPS/IDS at your disaster recovery (DR) site. If your firewall is disabled at the DR site, until a disaster occurs or if the rules on the firewall are different from the main site, audit the firewall regularly. - Implement proper change control so that your backup site and main site are kept as identical as possible. - Any logging and monitoring at the DR site should be treated as if it is at your primary site. - Audit and PEN test your DR site separate from your main site with the same frequency and importance. - Any replications to your backup site should be encrypted. - Place a copy of your business recovery plan at your offsite location. - Rotate your backup media and keep it in offsite storage. 7.6 Auditing and Logging - Use centralized logging to determine whether guests have gone offline. These guests can get out of sync in regards to patches and updates. Log any VM power events (such as On, Off, Suspended or Resumed), changes in hardware configurations or any login events related to those with elevated privileges. VMs that are copied, moved or deleted should also be logged. - Audit files should be read only and should only be read by those in an auditing role to ensure forensic integrity. Unauthorized and authorized login attempts to the audit files and other virtual resources should be logged. - Conduct regular audits of the environment including the virtual network, storage, the hypervisor, the VMs and the management systems. - Send log files securely to a remote log server. 7.7 Virtual Machine Security - VMs shouldn’t be placed on storage, backup or management networks that are connected to the hypervisor. - Screensavers don’t serve a purpose on VMs. Also, don’t use processor intensive screensavers on physical servers as they can overwhelm the processor that’s needed to serve the VMs. - VMs shouldn’t be able to access or view the resources used by the kernel or host. These resources include storage networks and networking responsible for moving VMs. - Don’t create more VMs than is necessary. Keep track of all of your running VMs to track potential entry points for attacks. Limit use of VMs to critical staff only. - Turn off any unused VMs. - Unused hardware ports like USB on VMs should be disabled. - Use IPSec or other forms of encryption between the host and VM. - Set a comprehensive preparation in place to plan, deploy, patch and backup your VMs. - Physical devices like CD-ROM and floppy drives can be controlled by VMs indirectly or directly on the host. Configure this capability on a per VM basis and disable this connection to hosts by default on all VMs. If this is not done, a VM can request access to the host during boot and other VMs can be blocked until devices are released, thus delaying the boot up process. - You may want to consider employing VLANs within a single vswitch to segment traffic. - When VMs move, active memory and state are sent over the network to the new host in clear text. Isolate this motion traffic from the production network on an isolated segment that is non-routable and configured with a separate vswitch or VLAN. - Any suspended VMs should be started up in a test or lab environment so that any configuration changes are tested to prevent breaking a guest in the production environment. - VMs should not directly access a VM data store or repository. - Consider using a virtual appliance to provide anti-virus protection for your VMs. The appliance provides an agent-less approach. Performance is improved since the processing doesn’t burden the individual VMs. The drawback to some of these appliances is that they only provide anti-virus protection and not the additional application control, IDS/IPS, firewalls and web filtering contained in more traditional appliances. - Consider placing a virtual appliance on the host connecting the VMs with a small driver that takes the scanning and updating processes off the individual VMs. A central signature database makes sure that protection is always up to date even if a VM was previously offline. Security also follows the workload as it moves from host to host. This approach can also apply protection to certain VM groups or perform deep scanning on certain select VMs. - Security policy can be used to make sure that a new VM is not allowed to join a VM group or cluster unless it has a specific configuration and has related updates installed. - Do not place workloads with different trust levels in the same security domain or on the same physical server. The chance of mixing trust levels is great when users can create and deploy their own VMs. - Some organizations limit the number of VMs per physical server or assign physical NICs to each VM for isolation purposes. Other firms also don’t allow VMs to move to other hosts. Although secure, make sure you realize that you will not be reaping all of the benefits of virtualization with these strategies. - Be careful in taking one VM or a small group of VMs and assigning them to a VLAN for separation and isolation. This can lead to VLAN growth and complexity and can create a major admin burden. - Restrict access to dormant VMs. - Any VMs placed in the DMZ are exposed to the Internet and are open to attack. Do not allow a VM in the DMZ to access the storage system or networks. - When two or more VMs are on the same VLAN and vswitch, the traffic between the VMs is not protected. Consider placing virtual firewalls on these VMs for protection. - Place a CPU limit on any VMs that can access the Internet. This is so that if a VM is compromised, the resources are limited to launch attacks on other hosts. - If users are allowed to create VMs, consider allowing them to create VMs from an authorized template. - Consider deploying a security VM to eliminate an agent on each VM. This can eliminate anti-virus storms and any bottlenecks that would occur when all hosts and VMs start their malware scans simultaneously. - Check the OS on VMs with a script and a user login to make sure that the VMs have been updated. If the VM is not compliant with the updates, the script can log the user off and alert the help desk. Or, a non-compliant VM can be kept in the DMZ or test environment and not allowed to access the network until it’s properly updated. - Disable any copy- paste functionality to protect the confidentiality of the data and the integrity of the hypervisor and VMs. - A virtual firewall attached to a VM travels with it at all times to ensure that security policy is enforced before, during and after any moves. - A security gateway (firewall and IDS/IPS) can be employed to inspect traffic between VMs. - Make sure that any VMs that process protected information are isolated from other VMs so that the data isn’t combined with other data or is accessible through other VMs. 7.8 Management Systems - Secure your communications between management systems and the hosts to prevent data loss, eavesdropping and any chance for man-in-the-middle attacks. Enable one or more of the available SSH, IPSec and SSL protocols for this purpose. - Employ a single management system and security policy to cover both physical and virtual environments. Not implementing this approach will mean double the work for generating reports and conducting analysis for any issues that present themselves. - Do not allow a management server to be accessible from all workstations. Compromising this server could affect VMs and data stores. To prevent this, place the management server on a separate VLAN from the user computers’ subnet and then place behind a firewall. These are two completely different security zones. Define access control lists on the network switches and set appropriate rules on the firewall. Change the default permissions on these servers so that the admin doesn’t have access to the entire environment. - Separate management servers from database servers. 7.9 Hypervisor Security - Install vendor supplied patches and updates to the hypervisor as they’re released. Support this with a sound patch management process to mitigate the risk of hypervisor vulnerabilities. Place the latest service packs on guests and hosts and remove any applications with a history of vulnerabilities. - Disable any unused virtual hardware that connects to the hypervisor. - Disable unneeded services like clipboard or file sharing. - Perform constant monitoring of the hypervisor for any potential signs of compromise. Monitor and analyze the hypervisor logs on a consistent basis. - Do not expose the management interface to the hypervisor to your LAN. - Disable all local administration of the hypervisor and require use of a centralized management application. - Require multi-factor authentication for any admin functions on the hypervisor. 7.10 Snapshots and Images - No guest OS images should have write access. - Protect VMs by the snapshot capability of the hypervisor as the snapshot captures the current state of the VM. The snapshot captures the OS, configuration settings, data and application state contained in the VM at that point in time. 7.11 Time Synchronization - Network Time Protocol (NTP) should be enabled and configured to synchronize with a time server close to your network and NTP should run on a host. Guest VMs should either use the same server as the host or use the host itself as the NTP server. If the VM layer allows a guest OS to sync time directly from the host, then this should be used as this is the simplest to implement. - Hashing authentication should be used between NTP peers to prevent tampering. 7.12 Remote Access - Some firms use Virtual Network Computing (VNC) as a cross platform remote desktop function. Communications aren’t always encrypted when using this. Encryption may be provided in the vendor’s settings or through a third party plug-in. Don’t expose these VNC connections to the Internet whether they’re encrypted or not. Control these connections through a VPN or SSH tunneling. - Remote access management should be limited to a small set of authorized management system IP addresses. - Any remote access should ask for a username as well as a password backed up with a strong password policy. For strong security environments, use two factor authentication or one time use passwords. - Remote communication to any management tools should be encrypted and authenticated. - When using SSH, disable the version 1 protocol, disable the admin or root SSH login and require users to use role-based access control or their individual user accounts. Use a tool like Sudo as it allows activity to be written to a log that indicates what was done, when it was done and by whom?. - Do not allow any remote access to the host or hypervisor. 7.13 Backups - Encrypt any backup data streams in case a server image is stolen. Data at rest should have access control lists to control copying or mounting of images. - Network level protections like VLANs and access control lists should be in place to protect backup data whether at rest or in transit. - Do not allow root accounts to be used for backup. - Any backups that are sent to a disaster recovery site over the network should be securely encrypted. - Backup the OS and data on a daily basis and perform a full backup once a week. Complement these backups with remote storage solutions and offsite storage of backup media. - With virtual computing, disk backups are just as important as in traditional environments. Backups of virtual storage should be included in your backup policies. 7.14 Configuration and Change Management - Make sure that any physical or virtual servers are hardened before putting them into deployment. Monitor any configuration changes to detect any unauthorized changes or deviations from compliance in regards to updates and patches. - Harden physical and virtual switches and virtual appliances and gateways before deployment. - Do not allow changes to the infrastructure without documentation and testing in a lab environment that is as identical to the production environment as possible. Answer these questions before making any changes7: - What are the implications of the change? - Who and what will be affected? - How much of a risk does the change represent? - Can the change be reversed if necessary? - How long will it take to roll back a change? - Track VM configurations and issue alerts for any changes to a desired configuration. - Make sure that any existing patch management products support virtual offerings and platforms. 7.15 Server Pools and Virtual Service Offerings - Segment server pools in case they contain different server tiers like web servers that are public facing and database servers that contain personally identifiable information (PII). Put protections in place so that servers are protected from the Internet and from themselves. Not implementing segmentation in the server pools could mean that a single compromised server can affect the whole server pool. - For Virtual Service Offerings (VSOs), backup any user data, organizational data, documents , databases, state information on virtual servers and any Active Directory data using standard backup strategy and policies. - Separate server pools from VSOs from a security perspective. Users that interact with VSOs should not have access to the physical servers which are under the control of the admins. The above best practices and recommendations can be effective when used in addition to the standard traditional security already deployed and are not a substitute or replacement for effective existing security. However, virtualization is different enough in that if these suggestions are not employed, you will still not have a totally secure hybrid (physical and virtual) environment. 8. ADDITIONAL ISSUES, RECOMMENDATIONS AND BEST PRACTICES FOR THE VIRTUALIZED CLOUD Many of the previously mentioned recommendations and best practices are effective for data center, enterprise and cloud environments alike, but the cloud is different enough from the other two environments to require other protections due to scale, multi-tenancy and the fact that VMs don’t always stay within the cozy physical perimeter that you can design security around. The following are some of the important items to take note of: - Hypervisor security is even more important in the cloud due to the magnitude of a potential breach. - VMs need to be tracked to their owners throughout the VM lifecycle. They should only be collocated on servers that meet the collocation requirements of other VMs and should use VM tagging for tracking purposes. - VLANs should be used to isolate traffic from one customer VM to another customer VM. This requires VLANs to be extended beyond the core switching infrastructure. There could be an issue with scaling VLAN capabilities to support very large clouds. - Automation is required for security in the cloud due to its sheer scale. Security must be better planned and managed in the cloud. - Recycling of IP addresses and IDs could be a problem if it’s possible for a user to gain access to another customer’s data. There must be a strong process in place to implement allocation and re-allocation of VMs. - Central storage is an attractive target in the cloud. Data protection and encryption must be properly implemented everywhere when data is at rest, in transit or being processed. - Standards will need to be in place if applications are going to be moved across different Cloud Service Providers (CSPs). This applies to data, firewalls, VMs and virtual network configurations. - Customers in the cloud need assurance that their data is kept separated from other customers within shared storage. - Automated lifecycle management tools should be used to track new deployments. CSPs also need to instruct customers to limit the number of users that can provision VMs. - Standard VM images need to be used to maintain the integrity of the environment. - A dedicated scanning VM cannot be used in the cloud to protect other VMs as they don’t control the hypervisor. An agent-based approach must be used in a multi-tenant environment. - Encryption keys for data stores must be protected. When the keys are protected properly, rogue VMs that may reach data stores become unmountable and unreadable. - Security policies tied to physical attributes like the physical server, IP address, or the physical host separation used for isolation or MAC address, don’t make much sense in the cloud. Security policies need to be tied to logical attributes as opposed to physical ones. Identity, group or role of the application users and sensitivity of the workload become important. Policies need to be context-aware and adaptive. - Standards are needed to tie all of the security together in the cloud. Customers and CSPs also need to delineate the security responsibilities between them. - In Infrastructure such as a Service environment, the client is responsible for maintaining patch levels for any provisioned VMs as well as having responsibility for properly configuring a VPN after initial installation. - The old access control model is machine based and IP focused. The model in the cloud needs to be person and user based. Network Access Control (NAC) determines who you are and what you get access to. Access control also needs to be dynamic as users come from anywhere, at anytime, on any device, and can access from multiple devices at one time8. - Data Loss Prevention (DLP) monitoring becomes more important and fingerprinting needs to be used so that DLP monitoring tools can recognize data. When a policy violation occurs, quarantine and response measures need to kick in. - Protection and scanning of dormant VMs remains with the CSP. - Full system scans in the cloud should not be used as they degrade performance. - If offered by the CSP, customers should use dedicated resources as they’re more secure. The cloud expands the security tasks necessary to provide protection of resources and customer data. The attack surface is much greater due to scale and a breach can have an effect on various customers and the related data that they’ve entrusted to the cloud service provider. 9. CONCLUSION Virtualization provides new security challenges for firms. The virtual components and environment cannot be protected by existing security mechanisms and processes alone. Virtualization creates a different network that is a hybrid between the established physically centered network and the new virtual or logical environment. Additional considerations and protections must be put into place to ensure a strong security posture, and much planning and preparation as well as training needs to be implemented in advance. Virtualization security must not become an afterthought after the new virtual infrastructure and components are put into place. Security in this area will improve as virtualization technology advances, and standards will need to be put into place so that firms have guidelines to follow to secure their new environments. ENDNOTES 1Amy Larsen DeCarlo, Myth vs. Reality: Controlling VM Sprawl in the Cloud, http://searchcloudprovider.techtarget.com/tip/myth-vs-reality-controlling-vm-sprawl-in-the-cloud. 2Amy Larsen DeCarlo, Myth vs. Reality: Controlling VM Sprawl in the Cloud, http://searchcloudprovider.techtarget.com/tip/myth-vs-reality-controlling-vm-sprawl-in-the-cloud. 3?Managing Access in a Virtualized Environment,” CA White Paper, October 2006. Page 4. 4?2010 State of Virtualization Security Survey,” Prism Microsystems, April 2010. Page 5. 5 “Is Virtualization a Black Hole in Your Security? 5 Ways to Ensure it Isn’t,” A Sophos White Paper, November 2008. Pages 3-4. 6 Forbes Guthrie, Scott Lowe, Maish Saidel-Keesing, VMware vSphere Design. (Wiley Publishing, Inc., 2011), Page 283. 7 Forbes Guthrie, Scott Lowe, Maish Saidel-Keesing, VMware vSphere Design. (Wiley Publishing, Inc., 2011), Page 295. 8 “Is Your Network Ready For Cloud Computing?,” Cisco, David Newman, 2012. SOURCES Ruest, Danielle and Nelson Ruest. (2009). Virtualization: A Beginner’s Guide. McGraw Hill Books. Campbell, Sean and Michael Jeronimo. (2006). Applied Virtualization Technology: Usage Models for IT Professionals and Software Developers. Intel Press. Haletky, Edward L. (2009) VMware vSphere and Virtual Infrastructure Security: Securing the Virtual Environment. Pearson Education. EC-Council Press. (2011). Virtualization Security. Winkler, Vic (J.R.). (2011). Securing the Cloud: Cloud Computer Security Techniques and Tactics. Elsevier. Golden, Bernard. (2008). Virtualization for Dummies. Wiley Publishing, Inc. Guthrie, Forbes, Scott Lowe, and Maish Saidel-Keesing. (2011). VMware vSphere Design. Wiley Publishing, Inc. Mishchenko, Dave. (2011). VMware ESXi: Planning, Implementation and Security. Cengage Learning. Security and High Availability in Cloud Computing Environments. (June 2011). IBM Global Technology Services Technical White Paper. Newman, David. (2012). Is Your Network Ready For Cloud Computing? Cisco. Managing Access in a Virtualized Environment. (October 2006). CA White Paper. MacDonald, Neil and Thomas J. Bittman. (October 13, 2010). From Secure Virtualization to Secure Private Clouds. Gartner Research. Virtualization and Cloud Computing: Security Best Practices. Trend Micro. Executive Brief: The Building Blocks for a Secure Virtualized Environment. IDG Global Solutions. Alternatives for Securing Virtual Networks. (2008). Altor Networks White Paper. Is Virtualization a Black Hole in Your Security? 5 Ways to Ensure it Isn’t. (November 2008). A Sophos White Paper. Antonopoulos, Andreas. (2007). Securing Virtualized Infrastructure: From Static Security to Virtual Shields. Nemertes Research. Garfinkel, Tal and Mendel Rosenblum. When Virtual is Harder than Real: Security Challenges in Virtual Machine Based Computing Environments. Stanford University Department of Computer Science. Ritter, Ted. (Summer 2009). Virtualization Security: Achieving Compliance for the Virtual Infrastructure. Nemertes Research. 5 Best Practices to Protect Your Virtual Environment. Altor Networks White Paper. The CIO Guide to Virtual Server Data Protection. A CommVault White Paper. 2010 State of Virtualization Security Survey. (April, 2010). Prism Microsystems. Server Security, Patching and Virtualization. BlueLane White Paper. Securing the Virtual World. (October, 2011). WatchGuard Technologies White Paper. Garber, Lee. (January 2012). The Challenges of Securing the Virtualized Environment. IEEE Computer Society Publishing. A Comprehensive Framework for Securing Virtualized Data Centers. (July 2010). HP Business White Paper. Vax, Nimrod. (May 2010). Securing Virtualized Environments and Accelerating Cloud Computing. CA White Paper. Securing Virtualization in Real-World Environments. (June 2009). IBM Internet Security Systems Virtualization White Paper. Making Virtual Machines Cloud-Ready. (May 2010). A Trend Micro White Paper. Securing the Virtual Information Infrastructure: Technology Concepts and Business Considerations. (February 2010). EMC Global Solutions. Essential Guide to Cloud and Virtualization Security. Information Security Magazine. Scarfone, Karen, Murugiah Souppaya, Paul Hoffman. Guide to Security for Full Virtualization Technologies. National Institute of Standards and Technology. U.S. Department of Commerce. Special Publication 800-125. Information Supplement: PCI DSS Virtualization Guidelines. PCI Data Security Standard. Version 2.0. (June 2011). Butler, J. Michael and Rob Vandenbrink. (September 2009). IT Audit for the Virtual Environment. A SANS White Paper. Database Security in Virtualization and Cloud Computing Environments. (2011). A McAfee White Paper. Sunderland, Bill and Ajay Chandramouly. (November 2011). Overcoming Security Challenges to Virtualize Internet-facing Applications. An Intel White Paper. IBM Point of View: Security and Cloud Computing. A Cloud Computing White Paper. (November 2009). Girola, Michele, Alessio M. Tarenzio, Mark Lewis, Marian Friedman. (February 2011). IBM Data Center Networking: Planning for Virtualization and Cloud Computing. IBM Redbooks. Hartman, Bret, Dr. Stephen Herrod, Dave Shackleford, Charu Chaubal, Nirav Mehta. (2009). Security Compliance in a Virtual World: Best Practices to Build a Solid Foundation. An RSA Security Brief. An Integrated Security Solution for the Virtual Data Center and Cloud: Protecting Physical and Virtual Workloads. Juniper Networks White Paper. (2011). Alternatives for Securing Virtual Networks: A different Network Requires a Different Approach – Extending Security to the Virtual World. Juniper Networks. (2011). NIST Guidance Cites Cloud Security Gaps, Need for Standards. http://searchcloudsecurity.techtarget.com/tip/NIST-guidance-cites-cloud-security-gaps-need-for-standards. Lowe, Scott. (March 1, 2012). How iSCSI Packets Are Encapsulatedand How to Protect iSCSI Data Traffic. http://www.techrepublic.com/blog/networking/how-iscsi-packets-are-encapsulated-and-how-to-protect-iscsi-data-traffic/5398 Application Brief: Multi-Tenant Cloud Security. www.vyatta.com/sites/vyatta.com/files/pdfs/vyatta_app_multitenantcloud.pdf. DeCarlo, Amy Larsen. (January 20, 2012). Myth vs. Reality: Controlling VM Sprawl in the Cloud. http://searchcloudprovider.techtarget.com/tip/myth-vs-reality-controlling-vm-sprawl-in-the-cloud. Shackleford, Dave. (March 9, 2010). An Introduction to Virtualization Security. SANS.http://net-security.org/article.php?id=1397. Chickowski, Ericka. (9/3/2009). Five Fundamentals to Secure Virtualization. http://www.channelinsider.com/c/a/virtualization/five-fundamentals-to-secure- Virtualization-565563/. Haletky, Edward L., Contributor. Securing Virtual Environments: Three Considerations. http://secureservervirtualization.techtarget.com/tip/securing-virtual-environments-three-considerations. Peterson, John. Virtual Environments Will be More Secure than Their Physical Counter Parts by 2010. Montego Networks. http://vmwaresecurity.typepad.com/security_in_the_virtual_w/2008/03/virtual-environ.html. featurevisualization security [h=5]About the Author[/h] Terry Komperda is a Chicago-based security enthusiast and researcher who likes to write about technology subjects from both a business and technical perspective. His current interests are data centers, the Cloud, virtualization and all aspects of security. He currently works in product management and new product development and develops DCIM software for data centers. Sursa: http://resources.infosecinstitute.com/virtualization-security-2/

[h=1]Kaspersky Security Bulletin 2012. Cyber Weapons[/h] Author Alexander Gostev Kaspersky Security Bulletin 2012. Malware Evolution Kaspersky Security Bulletin 2012. The overall statistics for 2012 Kaspersky Security Bulletin 2012. Cyber Weapons World view Duqu Wiper Flame Gauss miniFlame So what does it all mean? Before 2012, there were only two instances of cyber weapons being used – Stuxnet and Duqu. However, analysis of these two forced the IT community to dramatically expand the whole concept of what cyber warfare entails. Apart from an increase in the number of security incidents involving cyber weapons, the events of 2012 have also brought to light the fact that many sovereign states are heavily involved in the development of cyber weapons – something that was picked up on and widely discussed by the mass media. Moreover, cyber warfare was on the agenda of public discussions between governments and state representatives over the course of 2012. It is safe to say, therefore, that 2012 has brought key revelations in this sphere – both in terms of the increase in security incidents and a greater understanding of how cyber weapons are being developed. [h=2]World view[/h] 2012 saw the use of cyber weapons spread to a wider area. Previously they had only targeted Iran, but throughout the year they were deployed in a broader region of Western Asia adjacent to Iran. This change reflected the political developments in a region that has long been regarded as volatile. Iran’s nuclear program continued, while the situation in the region was further complicated by political crises in Syria and Egypt. Tensions in Lebanon, the on-going Israeli-Palestinian conflict and unrest in several countries around the Persian Gulf merely added to the instability across the region. In these circumstances, it is hardly surprising that other nations have sought to defend their interests and have used all available tools to both defend themselves and gather information. All these factors combined have sparked several serious incidents in the region which, after closer analysis, can be classified as the application of cyber weapons. [h=2]Duqu[/h] This malicious spyware program, which was detected in September 2011 and brought to public attention in October 2011, prompted Kaspersky Lab’s experts to action. As part of their research, the company’s experts managed to gain access to a number of Duqu’s C&C servers and collect a substantial amount of information about the programs’ architecture and its evolution. It was convincingly demonstrated that Duqu was a development of the Tilded platform, on the basis of which another high-profile malicious program – Stuxnet – had also been developed. Besides, it was established that at least three more malware programs existed that used the same Duqu/Stuxnet framework; this malware has yet to be detected. The research activity prompted Duqu’s operators to destroy all traces of their activity from the C&C servers and victim computers. By late 2011, Duqu ceased to exist “in the wild”. However, in late February 2012 Symantec’s experts discovered a new version of a driver in Iran, similar to the one used in Duqu but created on 23 February, 2012. The core module was never detected; no further modifications of Duqu have been discovered since then. [h=2]Wiper[/h] This “mystical” Trojan greatly disturbed Iran in late April 2012: it emerged basically from nowhere and destroyed a large number of databases in dozens of organizations. The country’s largest oil depot was especially hard hit – its operation was halted for several days after data on oil contracts was destroyed. However, not a single sample of the malicious program used in these attacks was detected, which prompted many to question the accuracy of media reports. The International Telecommunication Union (ITU) asked Kaspersky Lab to research these incidents and determine the potential damage wrought by this malicious program. Wiper’s creators did their best to destroy all the data that could be used to analyze the incidents. For this reason, practically no traces of the malicious program’s activity were left after Wiper was activated. In the course of investigating the mysterious malicious attack in April, we managed to obtain and analyze samples of several hard drives attacked by Wiper. We can confirm that these incidents did indeed take place and that the malicious program used in these attacks existed in April 2012. Moreover, we know of several very similar incidents that have taken place, dating back to December 2011. The bulk of the attacks took place in the final 10 days of a month (from the 21st to the 30th); however, we cannot be certain that there was a dedicated function that was only activated on specific dates. Several weeks into the investigation, we were still unable to detect any malicious files whose properties matched the known characteristics of Wiper. However, we did discover a cyber-espionage campaign being conducted on a state level, which is now known as Flame; later on, we discovered yet another cyber-espionage system that was subsequently dubbed Gauss. [h=2]Flame[/h] Flame is a very sophisticated toolkit for conducting attacks, far more complex than Duqu. It is a backdoor Trojan which also possesses some of the characteristic of worms; the latter enable it to propagate via local networks or removable storage drives following instructions from its master. After infecting the host system, Flame starts to execute a complex set of operations, which can include analyzing the network traffic, taking screenshots, recording voice communications, keystroke logging etc. All this data is available to its operators via Flame C&C servers. The operators can also download extra modules to victim computers to extend Flame’s payload. All in all, 20 extension modules were detected. Flame incorporated a unique functionality to propagate itself across a LAN; to that end, it intercepted Windows update requests and substituted them with its own module signed with a Microsoft certificate. Analysis of this certificate revealed a unique cryptographic attack which enabled cybercriminals to generate their own bogus certificate that was indistinguishable from a legal one. The information we have collected testifies that the development of Flame started back in 2008 or so, and continued actively right up to its exposure in May 2012. Moreover, we were able to establish that one of the modules created on the Flame platform was used in 2009 as a propagation module for the Stuxnet worm. This fact demonstrates that there has been close cooperation between the programming teams of the Flame and Tilded platforms, right up to the exchange of source code. [h=2]Gauss[/h] After we discovered Flame we implemented several heuristic methods based on an analysis of similarities in the code. This approach soon brought us another breakthrough. In mid-July, a malicious program was detected that had been created on the Flame platform; however, it had a different payload and habitat. Gauss is a sophisticated toolkit for conducting cyber espionage, implemented by the same group that created the malicious Flame platform. The toolkit has a modular structure and supports remote deployment of a new payload that is implemented in the form of extra modules. The modules found so far perform the following functions: Intercept cookie-files and passwords in the web browser; Collect system configuration data and send it to cybercriminals; Infect USB storage drives with a module designed to steal data; Create lists of the contents on a system’s storage drives and folders; Steal data required to access user accounts of various banking systems in the Middle East; Intercept account data in social networks, mailing and instant messaging services. It seems the modules were named in honor of renowned mathematicians and philosophers – Kurt Gödel, Carl Friedrich Gauss and Joseph Louis Lagrange. Based on the results of our analysis and the timestamps in the malicious modules available to us, we concluded that Gauss started operating in August or September 2011. Since late May 2012, Kaspersky Lab’s cloud-based security service has registered over 2500 Gauss infections; we estimate that the actual total number of Gauss victims may be in the tens of thousands. The vast majority of Gauss victims are Lebanese residents; victims were also registered in Israel and the Palestinian territories. Smaller numbers of victims were recorded in the USA, United Arab Emirates, Qatar, Jordan, Germany and Egypt. [h=2]miniFlame[/h] In early June 2012, we discovered a small yet interesting module created on the Flame platform. This malicious program, dubbed miniFlame, is a miniature fully-fledged spyware module designed to steal information and gain access to an infected system. Unlike Flame and Gauss, which were both used to carry out large-scale espionage operations with thousands of users being infected, miniFlame/SPE is a tool for carrying out targeted attacks with pinpoint accuracy. Although miniFlame is based on the Flame platform, it is implemented as a stand-alone module that can operate both autonomously, without Flame’s main modules being present in the system, and as a component controlled by Flame. Remarkably, miniFlame can also be used in conjunction with Gauss, another spyware program. It appears that the development of miniFlame began several years ago and continued until 2012. Judging by its C&C code, the protocols for servicing SP and SPE were created earlier than, or at the same time as, the operation protocol for FL (Flame), which means no later than 2007. miniFlame’s primary purpose is to function as a backdoor on infected systems, enabling attackers to directly manage them. The number of miniFlame victims is comparable to that of Duqu. [TABLE=class: pd48, width: 70%] [TR] [TD] Name [/TD] [TD] Number of incidents (Kaspersky Lab statistics) [/TD] [TD] Approximate number of incidents [/TD] [/TR] [TR] [TD] Stuxnet [/TD] [TD] Over 100 000 [/TD] [TD] Over 300 000 [/TD] [/TR] [TR] [TD] Gauss [/TD] [TD] ~ 2500 [/TD] [TD] ~10 000 [/TD] [/TR] [TR] [TD] Flame (FL) [/TD] [TD] ~ 700 [/TD] [TD] ~5000-6000 [/TD] [/TR] [TR] [TD] Duqu [/TD] [TD] ~20 [/TD] [TD] ~50-60 [/TD] [/TR] [TR] [TD] miniFlame (SPE) [/TD] [TD] ~10-20 [/TD] [TD] ~50-60 [/TD] [/TR] [/TABLE] A summary of all the data about malicious programs classed as “cyber weapons” discovered in 2012, demonstrates a clear geographic connection with the Middle East. [h=2]So what does it all mean?[/h] Our experience of detecting and analyzing all of the malware discussed above enables us to put forward the following view on contemporary threats and their classification. The current state of malware is best represented as a pyramid. The base of the pyramid is made up of all kinds of threats – what we call ‘traditional’ cybercrime. Its distinguishing features include a reliance of mass attacks targeting ordinary users. Cybercriminals’ are mostly interested in launching these attacks for direct financial gain. Malware in this tier includes banking Trojans, clickers, botnets, ransomware, mobile threats etc. and accounts for over 90% of all contemporary threats. The second tier is made up of threats aimed at organizations. These are targeted attacks, which include industrial espionage, as well as targeted hacker attacks designed to discredit their victims. The attackers are highly specialized and work with a specific target in mind or for a specific client. The goal is to steal information or intellectual property. Financial gain is not the attackers’ primary goal. According to our classification, this group of threats also includes a variety of malicious programs created by certain companies at the request of law enforcement agencies in several countries and sold almost openly, e.g. malware developed by the Gamma Group or Hacking Team SRL. The third tier, which is the top level of the pyramid, includes malware which can be categorized as true cyber weapons. In our classification, this includes malware created and financed by government-controlled structures. Such malware is used against citizens, organizations and agencies in other countries. Based on all the samples of such programs that we know of, we can identify three main groups of threats in this category: 'Destroyers'. These are programs designed to destroy databases and information as a whole. They can be implemented as ‘logic bombs’ that are introduced into victim systems either in advance and then triggered at a certain time, or during a targeted attack with immediate execution. The most notable example of such malware is Wiper. Espionage programs. This group includes Flame, Gauss, Duqu and miniFlame. The primary purpose of such malware is to collect as much information as possible, particularly very highly specialized data (e.g. from Autocad projects, SCADA systems etc.), which can then be used to create other types of threats. Cyber sabotage tools. These are the ultimate form of cyber weaponry – threats resulting in physical damage to targets. Naturally, this category includes the Stuxnet worm. Threats of this kind are unique and we believe they are always going to be a rare phenomenon. However, some countries are devoting more and more effort to developing this type of threat, as well as defending themselves against it. Sursa: http://www.securelist.com/en/analysis/204792257/Kaspersky_Security_Bulletin_2012_Cyber_Weapons

Backtrack 5 R3 :- Wpscan http://www.youtube.com/watch?feature=player_embedded&v=0vrRMf_DKM0 Description: WPScan is a vulnerability scanner which checks the security of WordPress installations using a black box approach 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: http://www.youtube.com/watch?v=0vrRMf_DKM0 Sursa: http://www.securitytube.net/video/6408

Adobe Flash Player 11.5.502.135 Memory Corruption Download: http://packetstormsecurity.org/files/download/118865/adobefp-corrupt.tgz

[h=1]Unlocked Physical Memory[/h]Author: [h=3]falkman[/h] "I just came up with this little user-mode program and driver to make it possible from user-mode without restriction (even without auth) to read/write to physical memory. There's a bit too much code to post here, so I'll have to link externally (sorry):" http://www.brandonfa.lk/ulpm/index.html Sursa: http://www.rohitab.com/discuss/topic/38727-unlocked-physical-memory/

[h=1]New Java update allows users to block Java from running while browsing[/h]Posted by: FastFlux on December 18, 2012 Oracle has published a new edition of the Jave Development Kit which includes several security advances. The major alteration in JDK 7u10 is the ability to forbid any Java application from running in the browser, which targeted a low by malware. The new release of Java also includes some additional security enhancements, most notably a feature that enables developers to set a specific level of security for any unsigned Java applets due to the large number of attacks targeting Java. Oracle’s conclusion to allow users to disable Java applications from running in web browsers could be a crucial step in preventing some of the widespread Java attacks. “The ability to select the desired level of security for unsigned applets, Java Web Start applications, and embedded JavaFX applications that run in a browser. Four levels of security are supported. This feature can be set in the Java Control Panel or (on Microsoft Windows platform only) using a command-line install argument,” Oracle said. One additional security feature in the new Java release is a dialogue that will warn you when the Java Runtime Environment is out of date or below the security baseline, which will help when new crucial security patches are released for Java zero-days. Sursa: http://zerosecurity.org/technews/new-java-update-allows-users-to-block-java-from-running-while-browsing/

[h=1]Steam for Linux open beta begins this week[/h] Dec. 17, 2012 (7:29 am) By: James Plafke Steam’s limited Linux beta has been running for a little over a month now, recently opening up to 5,000 new testers. Today, in a message to the Steam for Linux closed mailing list, Valve has announced that it will be opening up the beta to the public next week. Opening up the beta would increase the current population of 80,000 testers to, Valve hopes, a much larger number. Along with the open beta, Valve will release a new web page detailing how to install Ubuntu and Steam for Linux. A Steam for Linux repository will also be set up, stats for the Linux games library will be released, and of course, games that support Linux will become available for purchase. Remember, just because Steam is making its way to Linux doesn’t mean it’ll bring a boatload of games — Steam is just a client, not some kind of automatic porting engine. However, if the client proves to be a success, game developers could take interest in making a Linux version of their game in order to make some extra money. That said, the client is expected to have around 40 games available at launch, including World of Goo, Amnesia, and Sword & Sworcery. Valve will be opening up the beta around Christmas time — a thoughtful present to all those bored Linux gamers, but also the perfect time to generate a large amount of sales. via OMG! Ubuntu! Sursa: http://www.geek.com/articles/games/steam-for-linux-open-beta-begins-this-week-20121217/

[h=1]HTML5 is done - HTML 5.1 next on standards agenda[/h]17 December 2012, 21:13 The World Wide Web Consortium (W3C) has officially announced that the HTML5 and Canvas2D specifications are now complete and are now candidate recommendations. This does not mean that they are now a standard, but the W3C has moved on to the phase where members, businesses and developers can use the specifications for "implementation and planning". The W3C HTML Working Group is moving on to begin testing that the specification can be implemented portably on all the various venues (browsers, authoring tools, email clients, servers, CMS) that it will be used in, by examining the current implementations and finding which areas need test development. This next phase will last into mid-2014, after which there should be a publication of a final, royalty-free HTML5 Recommendation. In the meantime, new HTML5 work will take place in the development of HTML5.1 and Canvas 2D Context, Level 2. The work will encompass extensions to HTML5's accessibility, responsive images, and adaptive streaming. It will be around 2016, according to current schedules, before HTML5.1 becomes a recommendation, though this is a more rapid development schedule than HTML5; work began on that in 2004 at the WHATWG (Web Hypertext Application Technology Working Group). (djwm) Sursa: http://www.h-online.com/open/news/item/HTML5-is-done-HTML-5-1-next-on-standards-agenda-1770844.html