Nytro

[h=1]White House Cybersecurity Executive Order[/h]Posted by Richard Li in Information Security on Feb 13, 2013 12:16:40 PM Last night, in the State of the Union, President Obama highlighted the risk that America faces from cyber-attack. He also signed an executive order on cybersecurity, expanding the availability of unclassified threat information to critical infrastructure companies and appointing NIST to lead the development of a cybersecurity framework. These are positive steps to improving the cybersecurity of America’s infrastructure, but there is far more that needs to be done to secure our infrastructure. Our digital infrastructure is pervasive, and an integral part of our daily lives. From basic services such as power and communications to healthcare, commerce, finance, and manufacturing – every major industry and service is dependent in some way on the technology grid. This grid is extremely vulnerable to attack. These attacks may take the form of a deliberate, targeted cyberterror-type attack. Of equal likelihood – and potentially with the same impact – is an untargeted attack, where attackers unleash malware into the wild, without a specific target in mind. The impact to our economy and security of a successful attack, whether targeted or not, can be catastrophic. We need to do much, much more, but fixing this problem is not easy. The cybersecurity legislation that sits in both the House and Senate are a good next step. Providing incentives for critical infrastructure providers to improve their cybersecurity based on risk assessments will be another key step. Investing in training skilled security analysts and engineers who can defend against cyber attacks will be critical. The US is expanding the Cyber Command to have 4,900 troops and civilians, up from 900. There are 58,000 troops in the US Special Operations Command alone. As the battlefield evolves from traditional sea, air, and land battles to urban and cyber warfare, we need to evolve our defenses and capability. What can we do? We need to continue to innovate and research these threats, and how they are evolving. We need to invest in growing our cyber workforce. And, most importantly, we need to recognize that every single system in the US can potentially be exploited, and needs to be protected. Sursa: https://community.rapid7.com/community/infosec/blog/2013/02/13/white-house-cybersecurity-executive-order

Beej's Guide to Network Programming Using Internet Sockets Brian "Beej Jorgensen" Hall beej@beej.us Version 3.0.15 July 3, 2012 Copyright © 2012 Brian "Beej Jorgensen" Hall Contents 1. Intro 1.1. Audience 1.2. Platform and Compiler 1.3. Official Homepage and Books For Sale 1.4. Note for Solaris/SunOS Programmers 1.5. Note for Windows Programmers 1.6. Email Policy 1.7. Mirroring 1.8. Note for Translators 1.9. Copyright and Distribution 2. What is a socket? 2.1. Two Types of Internet Sockets 2.2. Low level Nonsense and Network Theory 3. IP Addresses, structs, and Data Munging 3.1. IP Addresses, versions 4 and 6 3.2. Byte Order 3.3. structs 3.4. IP Addresses, Part Deux 4. Jumping from IPv4 to IPv6 5. System Calls or Bust 5.1. getaddrinfo()—Prepare to launch! 5.2. socket()—Get the File Descriptor! 5.3. bind()—What port am I on? 5.4. connect()—Hey, you! 5.5. listen()—Will somebody please call me? 5.6. accept()—"Thank you for calling port 3490." 5.7. send() and recv()—Talk to me, baby! 5.8. sendto() and recvfrom()—Talk to me, DGRAM-style 5.9. close() and shutdown()—Get outta my face! 5.10. getpeername()—Who are you? 5.11. gethostname()—Who am I? 6. Client-Server Background 6.1. A Simple Stream Server 6.2. A Simple Stream Client 6.3. Datagram Sockets 7. Slightly Advanced Techniques 7.1. Blocking 7.2. select()—Synchronous I/O Multiplexing 7.3. Handling Partial send()s 7.4. Serialization—How to Pack Data 7.5. Son of Data Encapsulation 7.6. Broadcast Packets—Hello, World! 8. Common Questions 9. Man Pages 9.1. accept() 9.2. bind() 9.3. connect() 9.4. close() 9.5. getaddrinfo(), freeaddrinfo(), gai_strerror() 9.6. gethostname() 9.7. gethostbyname(), gethostbyaddr() 9.8. getnameinfo() 9.9. getpeername() 9.10. errno 9.11. fcntl() 9.12. htons(), htonl(), ntohs(), ntohl() 9.13. inet_ntoa(), inet_aton(), inet_addr 9.14. inet_ntop(), inet_pton() 9.15. listen() 9.16. perror(), strerror() 9.17. poll() 9.18. recv(), recvfrom() 9.19. select() 9.20. setsockopt(), getsockopt() 9.21. send(), sendto() 9.22. shutdown() 9.23. socket() 9.24. struct sockaddr and pals 10. More References 10.1. Books 10.2. Web References 10.3. RFCs Index Trebuie sa il stiti... http://beej.us/guide/bgnet/output/html/singlepage/bgnet.html

[h=1]Defrag Tools: #27 - WinDbg - Configure Kernel Debugging[/h] [h=3]Download[/h] [h=3]How do I download the videos?[/h] To download, right click the file type you would like and pick “Save target as…” or “Save link as…” [h=3]Why should I download videos from Channel9?[/h] It's an easy way to save the videos you like locally. You can save the videos in order to watch them offline. If all you want is to hear the audio, you can download the MP3! [h=3]Which version should I choose?[/h] If you want to view the video on your PC, Xbox or Media Center, download the High Quality WMV file (this is the highest quality version we have available). If you'd like a lower bitrate version, to reduce the download time or cost, then choose the Medium Quality WMV file. If you have a Zune, WP7, iPhone, iPad, or iPod device, choose the low or medium MP4 file. If you just want to hear the audio of the video, choose the MP3 file. Right click “Save as…” MP3 (Audio only) [h=3]File size[/h] 34.1 MB MP4 (iPod, Zune HD) [h=3]File size[/h] 205.0 MB Mid Quality WMV (Lo-band, Mobile) [h=3]File size[/h] 126.6 MB High Quality MP4 (iPad, PC) [h=3]File size[/h] 448.8 MB Mid Quality MP4 (WP7, HTML5) [h=3]File size[/h] 313.6 MB High Quality WMV (PC, Xbox, MCE) In this episode of Defrag Tools, Andrew Richards, Chad Beeder and Larry Larsen continue looking at the Debugging Tools for Windows (in particular WinDbg). WinDbg is a debugger that supports user mode debugging of a process, or kernel mode debugging of a computer. This installment goes over the cables and configuration steps required to set up kernel mode debugging. We use these BCDEdit commands: bcdedit bcdedit /dbgsettings bcdedit /dbgsettings 1394 channel:42 bcdedit /dbgsettings net hostip:192.168.0.10 port:50000 key:a.b.c.d bcdedit /debug on bcdedit /debug off In the debug session, we use these commands: .crash .dump /f lm !lmi .reload /f !drvobj !drvobj <module> 2 bl bc * be <N> bd <N> bp <function> bm <wildcard> x <wildcard> g Make sure you watch Defrag Tools Episode #1 and Defrag Tools Episode #23 for instructions on how to get the Debugging Tools for Windows and how to set the required environment variables for symbol and source code resolution. Resources: NT Debugging Blog - How to Setup a Debug Crash Cart to Prevent Your Server from Flat Lining USBView USB3 Debugging Cable - Note, you must use a USB3 A-A cable designed for debugging, otherwise it will fry your box! Timeline: [00:45] - Kernel Debugging Cables [02:14] - USB 2.0 [04:13] - USB 3.0 - New in Windows 8/Windows RT [05:30] - 1394 (Firewire) [10:39] - Break [11:38] - Driver Objects [16:00] - Network - New in Windows 8/Windows RT [17:30] - Breakpoint commands [26:00] - Network - BCDEdit [33:37] - SecureBoot and BitLocker Sursa: Defrag Tools: #27 - WinDbg - Configure Kernel Debugging | Defrag Tools | Channel 9

[h=3]Surprise for Network Resources from kernel32 (MS12-081, Detailed Analysis of Vulnerability in Microsoft File Handling Component)[/h] Microsoft issued a bulletin related to a vulnerability in Microsoft File Handling Component on December 11, 2012. The vulnerability was rated critical and assigned the category Remote Code Execution. Remote code execution is carried out, when a user opens a shared network resource with specially crafted contents. This report provides exploitation details. The results are based on Windows XP SP3 x86. The vulnerability itself is contained in the functions FindFirstFileExW and FindNextFileExW of the library kernel32.dll, which copy data received from the native function NtQueryDirectoryFile with the help of memmove. The problem is that a number received from NtQueryDirectoryFile is used as the size of a source buffer for the copy function, however, it may happen that the size of a destination buffer can be smaller than the result of NtQueryDirectoryFile. This vulnerability affects all applications, which use the functions of the families FindFirstFile/FindNextFile. The first application that comes to my mind is explorer.exe. An attacker only needs to make a user open a link to the malware resource. And, if everything is going well, they will be able to execute code with the same user rights as the current user. The remote execution script according to Microsoft FAQ is possible only via UNC share or WebDAV. A UNC (Universal Naming Convention) path can indicate a file share network resource running on the basis of the SMB protocol. Linux with the Samba service, which allows creating shared fields basing on the protocol, was chosen for the test. We wanted to carry out an attack in accordance with the following scheme. Linux has a similar restriction (not a path length, but a file name length), which is 255 characters. It is only needed to modify the resources of the Samba server to send a vulnerable Windows machine a directory listing with file names, which length exceeds 255 characters. The function smbd_marshall_dir_entry from trans2.c (Samba 3.6.6), which partially forms the server task, is one of the holes for malware injection. For the first test, the name of the output files was extended over 0x100 bytes and filled with the constant 0xfeeddead. Trying to use a modified server from a vulnerable machine, you can see the following. The screenshot shows that explorer.exe tried to read DWORD by the address from the EDX register. The read value participates in creating an address for the call. It's easy to see ascending the call stack that the first two parameters of the function RecentDocs_Enum are under control, besides they are rendered further. These values can be rewritten because they are located in a stack (see the scheme below). The function CFSFolder_CreateEnum allocates memory of size 0x498 for an instance of the class CFileSysEnum; this chunk contains the structure WIN32_FIND_DATA with offset 0x224. A pointer to this structure is transferred to the vulnerable function FindFirstFileEx, which rewrites the values that allow control hijacking. It is necessary to conduct a heap-spray attack to exploit this vulnerability. File names received by CShellBrowser2 are the objects for heap spraying in this case. Therefore, it is needed to create a lot of files on a shared network resource to conduct a heap-spray attack. The figure below provides the attack scheme. Note: the DEP (Data Execution Prevention) system is not considered in this scheme; it is evident that shellcode is in the heap, which should not be executable. One of the attack problems is server response fragmentation into several SMB packets. The driver mrxsmb.sys responsible for the SMB protocol includes the function MrxSmbUnalignedDirEntryCopyTail. This function checks the length of received names transferred to the user mode. If the limit of 0x200 bytes is exceeded, the function will display the error STATUS_INVALID_NETWORK_RESPONSE (0xC00000C3), and then NtQueryDirectoryFile will stop sending names for FindNextFile. This check can be bypassed as follows. First of all, it is necessary to create a set of files, which will conduct the heap-spray attack, and then to remove all the files from the directory and create a file, the name of which is the vulnerability trigger. The Samba server, in case of changes in the file system with a connected server, will send a packet with the function NT_NOTIFY, which will make the client repeat the request FIN_FIRST2 to the server having received only one malware name. Besides, the file names received earlier will remain in memory. Moreover, it is possible to control the order of the names, because they are sorted by name. It is worth noting that the names received from the Samba server should be unique; it is provided by allocating 5 bytes from the main file name field to the unique identifier. It is also worth noting that the file name transport supports interaction via the SMB protocol in double-byte Unicode. It restricts addresses rewritten on the vulnerable client, but due to the fact that the Samba server output is modified after conversion of single-byte to double-byte characters, these restrictions are insignificant, though they complicate the modified server's running process. Sending a big data packet, the server divides it into parts, and the client having received another such data part sends the sever a name, starting with which it should proceed the transaction (see the figure below). Due to the fact that when conducting the heap-spray attack unreal data is output, then the name to continue the output will be unreal as well. That is why it is needed to render the received continue_name in a real name on the server, with which it is necessary to continue. This construction allows code execution on a vulnerable machine with probability 1/7. Finally, we should say that the vulnerability can be easily exploited "in a wild life", though for creation of a combat exploit, one will have to solve the problem with DEP and find optimizing algorithms for heap spraying (to increase the probability of success). Author: Kirill Nesterov, Positive Research. Sursa: Positive Research Center: Surprise for Network Resources from kernel32 (MS12-081, Detailed Analysis of Vulnerability in Microsoft File Handling Component)

Cred ca e ok, adica probabil se face media voturilor, iar cum in cazul acela e un singur vot, de 5, inseamna ca si media e tot 5.

[h=3]Atmel SAM7XC Crypto Co-Processor key recovery (with bonus Mifare DESFire hack)[/h]The problem with crypto is that it is processor intensive (i.e. slow), so it's common, these days, to offload these functions to a dedicated hardware co-processor which will leave the main processor free to do whatever it is that it's supposed to be doing and not faffing about with crypto. This is good in theory, as it means that cryptographic protection can be added to more or less any system without having to worry that it's going to add an unacceptable level of load to the processor. It is also theoretically more secure as the crypto keys are safely tucked away in a dedicated secure store. Much is made of this additional level of security in marketing literature. But theory is all well and good - the bitch is getting it right in practice... The following is the result of an audit performed for a client and is published with their full knowledge and consent. There are a couple of ways you can attack a crypto system: go after the algorithm itself, or go after a specific implementation. To crack the algorithm, you generally need to be a very good mathematician (and more likely a cryptographer). Crypto algorithms are thought about long and hard, and specifically designed to be impervious to this kind of attack, so, although they don't always get it right, it is certainly not going to be an easy task to find the fundamental flaw (if any exists). The other way, to go after a specific implementation, is much more likely to bear fruit and will usually be a whole lot easier, and can therefore be attempted by the likes of you and me. This is because in crypto the devil is in the detail, and as a system gets more complicated there is a lot more detail to take care of and therefore a lot more avenues of attack. One of the specific issues crypto brings with it is the problem of managing the keys. The keys are literally the keys to your kingdom, and if you lose them you lose everything, so my first question is always: what keys are we after, and where can I find them? Our target today is an access control system that uses a Mifare DESFire EV1 card as it's token. The microprocessor in the control unit is the Atmel AT91SAM7XC256, which is part of Atmel's ARM based SAM7XC series. It has a crypto co-processor, which includes a write-only memory for the keys, and the whole of the chip's memory can also be locked so that the code cannot be read out. DESFire is a proprietary standard, but if you dig deep enough you'll find everything you're looking for, so it's relatively easy to write code to interrogate these tags and figure out what's on them (libfreefare would be a good place to start). I used my own RFIDIOt library to do so (note that I will always publish code if I can, but unfortunately as the DESFire standard is not open, and some of this tool is under NDA, I cannot in this case. If / when the restriction is lifted I'll be more than happy to do so, but in the meantime please don't ask. Sorry.) Articol: [/FONT]http://oamajormal.blogspot.co.uk/2013/02/atmel-sam7xc-crypto-co-processor-key.html[FONT=Arial]

Adobe Flash Player 0-day and HackingTeam's Remote Control System Sergey Golovanov Kaspersky Lab Expert Posted February 12, 15:01 GMT Last week, Adobe released a patch for a vulnerability in Flash Player that was being exploited in targeted attacks. Before reading any further, we recommend you to take a moment make sure you apply this patch. Adobe offers this nifty tool to check that you have the latest version of Flash Player. If you are running Google Chrome, make sure you have version ‘24.0.1312.57 m’ or later. Now back to CVE-2013-0633, the critical vulnerability that was discovered and reported to Adobe by Kaspersky Lab researchers Sergey Golovanov and Alexander Polyakov. The exploits for CVE-2013-0633 have been observed while monitoring the so-called ‘legal’ surveillance malware created by the Italian company HackingTeam. In this blog, we will describe some of the attacks and the usage of this 0-day to deploy malware from ‘HackingTeam’ marketed as Remote Control System. HackingTeam and RCS We previously wrote about RCS (Remote Control System) and HackingTeam and over the past few months, we’ve closely monitored the usage of the RCS (aka as ‘DaVinci’) against human rights activists and political dissidents from Africa, South America and the Middle East. We also presented the findings of this investigation last week at Kaspersky Lab’s SAS 2013 in a presentation named “Cyber Cosa Nostra”, which details the connections between HackingTeam with the shady organization known as ‘OPM’. An article documenting the findings will be published later this month on Securelist. During our investigation, we discovered several ways through which the RCS malware was installed onto the victims’ computers: 1. Self-signed JAR 2. CVE-2012-4167: (0-day from ‘Vupen’, see NYS OCS Advisory #2012-073 (09/26/2012) - Vulnerability in Adobe Flash Player Could Allow For Remote Code Execution (APSB12-19) -. ~3 months ITW before publishing ). Used with C2: hxxps://www.maile-s.com/yarab/stagedocJord 3. CVE-2010-3333: C2 at hxxps://ar-24.com/0000000031/veryimportant.doc2 + hxxp://rcs-demo.hackingteam.it/0000000001/exploit.doc2 4. CVE-2012-5054: (0-day Vupen, see Adobe Flash Player Matrix3D Integer Overflow Code Execution ? Packet Storm. ItW for ~3 months before patching) - used with C2 at: hxxp://176.58.100.37/0000040037/scandale.doc 5. CVE-2012-1682: (0-day. Security Explorations ~2 months ITW before publishing )- hxxp://ar-66.com/installer.jar 6. CVE-2013-0633: 0-day, previously unknown Some of these infection vectors were previously described in great detail by Citizen Lab Security Researcher Morgan Marquis-Boire, in relation to RCS and also another malware known as 'SPY_NET'. Interestingly, from the list above, two of the 0-days appear to have been created by the French offensive security company Vupen. The link was also previously pointed out by Citizen Lab’s report, which says it’s unclear if the exploits used with HacktingTeam’s malware have been purchased from Vupen, or just engineered in parallel. CVE-2013-0633 We came by CVE-2013-0633 while analysing a number of targeted attacks which appeared to be deploying the malware Backdoor.Win64.Korablin.a, which is the Kaspersky detection name for HacktingTeam’s ‘DaVinci’ package for Windows (Mac versions is called “Backdoor.OSX.Morcut”). The attacks employed Word documents which used multiple stages to deliver the malware to the target system. Although we do not have the original documents used in the attacks, we’ve identified several locations from which the 2nd and 3rd stage were delivered. Here’s a list of command servers which were used as C2 to deliver the exploits, as hardcoded in the shellcode used in the second stage of the attack: hxxp://li565-84.members.linode.com/0000000097/worddocument.doc3 hxxp://li565-84.members.linode.com/0000000093/worddocument.doc3 hxxp://li565-84.members.linode.com/0000000093/word_document.doc3 hxxp://li565-84.members.linode.com/0000000098/worddocuments.doc3 (a Linode server in Japan) Previously, we’ve seen attacks using other C2s as well: 76.162.33.13/stagedocsis www.wiki-islam.info/new/stagedocbn ww.faddeha.com/palestine27/stagedocpal wiki-arab.com/index/stagedocwinword ->>>> close[CENSORED].com/7-2012/stage2 (LIVE MALWARE, censored) 192.168.100.100/0000000788/info.doc2 173.255.215.193/napoli/napoli/stage2 The malware installed by these exploits is signed with a valid certificate from various entities around the world: (Digital certificate belonging to “Kamel Abed” used to sign the ‘RCS’ malware dropper) How widespread are these attacks? Here’s a map of detections for Backdoor.Win32/64.Korablin.a: During the monitoring period, we observed about 50 incidents from countries such as Italy, Mexico, Kazakhstan, Saudi Arabia, Turkey, Argentina, Algeria, Mali, Iran, India and Ethiopia. As it usually happens with such dubious software, it’s impossible to say who uses them and for what purpose. The problem with so-called ‘legal’ spy tools is that any government can purchase them, including governments from countries with a poor human rights records. Additionally, one government can purchase these tools and use them against another country. The link between HackingTeam and Vupen During our investigation, we observed at least two 0-days which are credited to Vupen that have been used in attacks with DaVinci/RCS. We do not know if the exploits have been discovered and created in parallel by both teams or if HackingTeam is just one of Vupen’s customers. Nevertheless, it appears there is a link between the two companies in the sense that malware written by HackingTeam is commonly deployed using Vupen 0-days. The future Following the publication of Citizen Lab’s blog From Bahrain with Love: FinFisher’s Spykit Exposed, the U.K. government reaffirmed that existing controls restricting the export of cryptographic systems apply to the Gamma Group’s exports of FinSpy. Although such restrictions exist in the U.K., there is currently little or no information on the regulations in France or Italy regarding the activity of companies that create 0-days and so-called ‘legal’ malware. Even when such regulations exist, the spyware can be easily sold to anyone through umbrella companies in other countries, such as Panama. Based on existing evidence, the victims of such attacks are human rights activists in countries with poor human rights records. It is possible that tools such as FinSpy or RCS lead to the arrest and conviction of people in such countries. We believe that the 'legal spy' industry is the equivalent of a ticking time bomb which can explode at any moment. The lack of regulation, the widespread trading of such dangerous technologies to pretty much anyone who has the money and the fact that they've already been in many dubious cases raises a big question about who will be held liable when the bubble finally bursts. Kaspersky Lab products detect the RCS/DaVinci backdoors as: Backdoor.Win32.Korablin, Backdoor.Win64.Korablin, Backdoor.Multi.Korablin, Rootkit.Win32.Korablin, Rootkit.Win64.Korablin, Rootkit.OSX.Morcut and Trojan.OSX.Morcut. Sursa: Adobe Flash Player 0-day and HackingTeam's Remote Control System - Securelist

[h=1]Hashkill 0.3.1![/h]by Mayuresh on February 12, 2013 “Hashkill is an open-source password recovery tool. Its features are: Multi-threaded so that it can benefit from multi-core/multi-CPU systems SSE2-accelerated algorithms to achieve high speeds on modern x86 CPUs 4 attack modes: dictionary/bruteforce/hybrid/markov 35 plugins for different types of passwords (ranging from simple hashes like MD5 and SHA1 to passworded ZIP files and private SSL key passphrases) Supports session save/restore. Sessions are auto-saved each 3 seconds. Password cracking can resume after the last checkpoint in case the program is stopped/killed/system crashes/power down/etc. Multi-hash support (you may load hashlists of length up to 1 million) Very fast GPU support on Nvidia (compute capability 2.1 cards also supported) and ATI (4xxx, 5xxx and 6xxx). Multi-GPU support. Session save/restore, markov/hybrid/bruteforce on GPUs“ [h=2]List of changes made to Hashkill:[/h] 9 new plugins: bfunix, drupal7, django256, sha256unix, mssql-2012, o5logon, msoffice-old, msoffice, luks. Of them msoffice-old is currently supported on CPU only, the rest are GPU-accelerated Improved build scripts Added a “fastdict” rule clause which enables very fast GPU-offloaded combinator attacks. The limitation is that wordlist candidates of len<=16 can be used. Improved bitmaps handling in non-salted kernels. Now huge hashlists would be cracked at faster speeds Rules that start with “must add str ..” are no more a badass bottleneck for the GPU-offloaded rule attacks Hash type auto-detection. Yes it works (although not 100% correct – in case there are several plugins that can crack that plugin, you will be presented a list of possible options) Added average speed indicator together with the current speed one. New hotkeys while cracking: ‘t’ would display GPU temps, ‘s’ would display short stats Thermal monitoring can now be disabled using -T 0 command-line argument Bugfixes: A new test framework was introduced. This in turn helped me to fix a LOT of bugs in the plugins. This is probably the first (well sort of) _STABLE_ hashkill version. Stack overflow issues were fixed in several plugins’ CPU code Issues with progress indicator inaccuracy were fixed. Critical issue with thermal monitoring which lead to program crashes was solved Large file support for x86 Thread-safety issues in rule engine were fixed that could lead to spontaneous errors Race condition that could lead to a deadlock was fixed Several CPU plugins had bugs that allowed false negatives. Fixed. [h=3]Download Hashkill:[/h] Hashkill 0.3.1 – hashkill-0.3.1-x86_64.tar.gz/hashkill-0.3.1-x86.tar.gz/0.3.1.zip Sursa: Hashkill version 0.3.1! — PenTestIT

[h=1]Netzob 0.4.1![/h]by Mayuresh on February 13, 2013 Our first post regarding Netzob can be found here. Sometime ago, an update - Netzob 0.4.1 – was made available to us. This release has been code named - ”WaddlingPeccary“. While the previous release introduced a large amount of changes, this one focuses on stability, UI, and model export towards Wireshark and Peach Fuzzer. Thanks to the new plugin mechanism, that was introduced in the previous release, some great features such as Wireshark and Peach exporters are now available as plugins, allowing you to dissect and fuzz proprietary protocols with well-known tools. It also added some new dialogs for configuring the workspace and projects, and to manage imported traces. Netzob is an opensource tool which supports the expert in its operations of reverse engineering, evaluation and simulation of communication protocols. Its main goals are to help security evaluators to : Assess the robustness of proprietary or unknown protocols implementation. Simulate realistic communications to test third-party products (IDS, firewalls, etc.). Create an open source implementation of a proprietary or unknown protocol. Netzob supports the expert in a semi-automatic inferring process of any communication protocol. Hence, it includes the necessaries to passively learn the vocabulary of a protocol and to actively infer its grammar. The learnt protocol can afterward be simulated. [h=2]Official change log for Netzob 0.4.1:[/h] In this release, 191 files were changed (10,968 lines added, 4,097 removed). Export plugins Automatic generation of Wireshark dissectors Automatic generation of Peach fuzzers [*]Workspaces and projects Workspace manager Project manager Trace manager [*]Pretty print of XML files [*]Simplify the default Variable [*]Provide extra compile arguments to the build process [h=3]Download Netzob:[/h] NETZOB 0.4.1 – Netzob-0.4.1.tar.gz/Netzob-0.4.1.win32-py2.7.exe Sursa: Netzob 0.4.1 – WaddlingPeccary! — PenTestIT

[h=1]Zed Attack Proxy 2.0.0![/h]by Mayuresh on February 13, 2013 Wow! It’s been some time since we last posted about ZAProxy! Our first post regarding the Zed Attack Proxy or the OWASP Zed Attack Proxy can be found here. Now, an updated Zed Attack Proxy version 2.0.0 was released! This version includes an integrated add-ons marketplace, a new Ajax spider, Session scope, and various other features and improvements have been added. “The Zed Attack Proxy (ZAP) is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing as well as being a useful addition to an experienced pen testers toolbox. ZAProxy provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.” [h=2]Zed Attack Proxy 2.0.0 official change log:[/h] An integrated add-ons marketplace: ZAP can be extended by add-ons that have full access to all of the ZAP internals. Anyone can write add-ons and upload them to the ZAP Add-on Marketplace (OK, so its a Google code project called zap-extensions, but you get the idea).More importantly you can now browse, download and install those add-ons from within ZAP. Most add-ons can be dynamically installed (and uninstalled) so you wont even need a restart.You can choose to be notified of updates, and even be automatically updated. And as the scan rules are now implemented as add-ons you can get the latest rules as soon as they are published. A replacement for the ‘standard’ Spider: The ‘old’ Spider was showing its age, so its been completely rewritten, and is much faster and more comprehensive than the old one. This is still a ‘traditional’ spider that analyses the HTML code for any links it can find. A new ‘Ajax’ spider: In addition to the ‘traditional’ spider we’ve added an Ajax spider which is more effective with applications that make heavy use of JavaScript. This uses the Crawljax project which drives a browser (using Selenium) and so can discover any links an application generates, even ones generated client side. Web Socket support: ZAP now supports WebSockets, so ZAP can now see all WebSocket messages sent to and from your browser. As with HTTP based messages, ZAP can also intercept WebSocket messages and allows you to change them on the fly. You can also fuzz WebSockets messages as well using all of the fuzzing payloads included in ZAP from projects like JBroFuzz and fuzzdb. And of course you can easily add your own fuzzing files. Quick Start tab: The first main tab you will now see is a ‘Quick Start’ tab which allows you to just type in a URL and scan it with one click. This is an ideal starting point for people new to application security, but experts can easily remove it if they find it distracting. Session awareness: ZAP is now session aware, so it can recognise and keep track of multiple sessions. It allows you to create new sessions, switch between them, and applies to all of the other components, like the Spider and Active Scanner. User defined Contexts: You can now define any number of ‘contexts’ – related sets of URLs which make up an application. You can then target all URLs in a context, for example using the Spider or Active Scanner. You can also add the contexts to the scope, and associate other information, such as authentication details. Session scope: The session scope allows you to specify which contexts you are interested at any one time. You can restrict what you see in various tabs to just the URLs in scope, and prevent accidentally attacking URLs not in scope by using the Protected mode. Different modes: ZAP now supports 3 modes: Safe, in which no potentially dangerous operations permitted Protected, in which you can perform any actions on URLs in scope Standard, in which you can do anything to any URLs [*]A scripting console: This allows you to access any internal ZAP data structures dynamically using any scripting language that supports JSR 223, [*]Authentication handling: You can now associate authentication details with any context, which allows ZAP to do things like detect if and when you are logged out and automatically log you back in again. This is especially useful when used via the API in security regression tests. [*]More API support: The REST API has been significantly extended, giving you much more access to the functionality ZAP provides. [*]Fine grained scanning controls [*]The active scan rules can now be tuned to adjust their strength (the number of attacks they perform) and the threshold at which they report potential issues. [*]New and improved active and passive scanning rules [*]We have uploaded the results from running ZAP 2.0.0 against wavsep (the most comprehensive open source evaluation project we are aware of) to the ZAP wiki: TestingWavsep - zaproxy - OWASP ZAP: An easy to use integrated penetration testing tool for finding vulnerabilities in web applications. - Google Project Hosting [*]Many stability and usability fixes [h=3]Download Zed Attack Proxy:[/h] Zed Attack Proxy 2.0.0 – ZAP_2.0.0_Windows.exe/ZAP_2.0.0_Linux.tar.gz/OWASP_ZAP_2.0.0_OSX-b.zip Sursa: Zed Attack Proxy version 2.0.0! — PenTestIT

[h=3]Introducing ModSecurity IIS 2.7.2 Stable Release[/h]swiat 11 Feb 2013 12:44 PM We are pleased to announce the release of a stable version of the open source web application firewall module ModSecurity IIS 2.7.2. Since the announcement of availability of the beta version in July 2012, we have been working very hard to bring the quality of the module to meet the enterprise class product requirements. In addition to numerous reliability improvements, we have introduced following changes since the first beta version was released: optimized performance of request and response body handling added “Include” directive, relative path and wildcard options to the configuration files re-written installer code to avoid .NET Framework dependency and added installation error messages to system event log integrated OWASP Core Rule Set in the MSI installer with IIS-specific configuration fixed about 10 functional bugs reported by ModSecurity IIS users. Microsoft also released recently a TechNet article entitled "Security Best Practices to Protect Internet Facing Web Servers", which explains in details benefits of deploying a WAF module on a web server. [h=3]Integrated OWASP Core Rule Set[/h] In version 2.7.2 of ModSecurity IIS we have included OWASP Core Rules Set pre-configured to serve most common scenarios encountered on IIS server. The rule set gets installed into c:\inetpub\wwwroot\owasp_crs directory, from which it can be included in any web.config file by adding: <ModSecurity enabled="true" configFile="owasp_crs\modsecurity_iis.conf" /> The default setting enables request body access, disables response body access, does not use audit log, and sets temporary files and data folder to c:\inetpub\temp. User can enable or modify these and other features by uncommenting appropriate ModSecurity directives in modsecurity.conf or modsecurity_crs_10_setup.conf files. [h=3]2012 Toolsmith Tool of the Year Award: ModSecurity for IIS[/h] Russ McRee over at HolisticInfosec held open voting in January for the 2012 Toolsmith Tool of the Year Award and ModSecurity for IIS won! We are glad that the Toolsmith readers found value in the IIS version of ModSecurity and we hope that it will help them to quickly mitigate emerging threats to their Microsoft IIS/ASP/.Net environments. [h=3]Acknowledgements[/h] I would like to thank Nazim Lala and Ashish Kurmi from Microsoft for their help in module testing, Breno Silva and Ryan Barnett from Trustwave for continuous support of the IIS version, and Simon Kosinski for his valuable insights and suggestions. Greg Wroblewski, MSRC Sursa: Introducing ModSecurity IIS 2.7.2 Stable Release - Security Research & Defense - Site Home - TechNet Blogs

[h=1]Object Oriented Programming in C#.net[/h]Ajay Yadav February 12, 2013 OOP’s overview Object-oriented programming is the core ingredient of the .NET framework. OOP is so important that before embarking on the road to .NET, you must understand its basic principles and terminology to write even a simple program. The fundamental idea behind OOP is to combine into a single unit both data and the methods that operate on that data,with such units being called an object. All OOP languages provide mechanisms that help you implement the object-oriented model. They are encapsulation, inheritance, polymorphism and reusability. Let’s take a brief look at these concepts: Encapsulation This mechanism binds together code and the data it manipulates, and keeps both safe from outside interference and misuse. Encapsulation is a protective container that prevents code and data from being accessed by other code defined outside the container. Inheritance Inheritance is the process by which one object acquires the properties of another object. A type derives from a base type, taking all the base type members’ fields and functions. Inheritance is most useful when you need to add functionality to an existing type. For example all .NET classes are inherited from System.Object classes, so a class scans its new functionality as well as the existing Object class functions and properties. Polymorphism Polymorphism is a feature that allows one interface to be used for a general class of action. This concept is often expressed as “one interface, multiple actions.” The specific action is determined by the exact nature of circumstances. Reusability Once a class has been written, created and debugged, it can be distributed to other programmers for use in their own program. This is called reusability or, in .NET terminology, this concept is called a component or DLL. However, in OOP, inheritance provides an important extension to the idea of reusability. A programmer can take an existing class and without modifying it, add more features to it. Articol: http://resources.infosecinstitute.com/object-oriented-programming-in-c-net/

Cateva detalii despre unu: MS13-018: Hard to let go - Security Research & Defense - Site Home - TechNet Blogs

[h=1]Microsoft Security Bulletin Summary for February 2013[/h] Published: Tuesday, February 12, 2013 | Updated: Tuesday, February 12, 2013 Version: 1.1 This bulletin summary lists security bulletins released for February 2013. With the release of the security bulletins for February 2013, this bulletin summary replaces the bulletin advance notification originally issued February 7, 2013. For more information about the bulletin advance notification service, see Microsoft Security Bulletin Advance Notification. For information about how to receive automatic notifications whenever Microsoft security bulletins are issued, visit Microsoft Technical Security Notifications. Microsoft is hosting a webcast to address customer questions on these bulletins on February 13, 2013, at 11:00 AM Pacific Time (US & Canada). Register now for the February Security Bulletin Webcast. After this date, this webcast is available on-demand. Microsoft also provides information to help customers prioritize monthly security updates with any non-security updates that are being released on the same day as the monthly security updates. Please see the section, Other Information. Informatii: http://technet.microsoft.com/en-us/security/bulletin/ms13-feb Interesante: Microsoft Security Advisory (2755801): Update for Vulnerabilities in Adobe Flash Player in Internet Explorer 10 Microsoft Security Bulletin MS13-011 - Critical : Vulnerability in Media Decompression Could Allow Remote Code Execution (2780091) Microsoft Security Bulletin MS13-006 - Important : Vulnerability in Microsoft Windows Could Allow Security Feature Bypass (2785220) Microsoft Security Bulletin MS13-015 - Important : Vulnerability in .NET Framework Could Allow Elevation of Privilege (2800277) Microsoft Security Bulletin MS13-017 - Important : Vulnerabilities in Windows Kernel Could Allow Elevation of Privilege (2799494) Microsoft Security Advisory (2755801): Update for Vulnerabilities in Adobe Flash Player in Internet Explorer 10 Microsoft Security Bulletin MS13-018 - Important : Vulnerability in TCP/IP Could Allow Denial of Service (2790655) Microsoft Security Bulletin MS13-019 - Important : Vulnerability in Windows Client/Server Run-time Subsystem (CSRSS) Could Allow Elevation of Privilege (2790113) Microsoft Security Bulletin MS13-004 - Important : Vulnerabilities in .NET Framework Could Allow Elevation of Privilege (2769324) Microsoft Security Bulletin MS13-005 - Important : Vulnerability in Windows Kernel-Mode Driver Could Allow Elevation of Privilege (2778930) Microsoft Security Bulletin MS12-060 - Critical : Vulnerability in Windows Common Controls Could Allow Remote Code Execution (2720573) Microsoft Security Bulletin MS12-057 - Important : Vulnerability in Microsoft Office Could Allow Remote Code Execution (2731879) Updatati-va Windowsu.

Pe noi nu ne viziteaza [TABLE=class: tborder, width: 90%, align: center] [TR] [TD=class: tcat, colspan: 2, align: center]IP Address Search for IP Address: "153.31" [/TD] [/TR] [TR] [TD=class: alt1, colspan: 2]153.31 : Could Not Resolve Hostname[/TD] [/TR] [TR] [TD=class: thead, colspan: 2]Post IP Addresses[/TD] [/TR] [TR] [TD=class: alt2, colspan: 2]No Matches Found[/TD] [/TR] [TR] [TD=class: thead, colspan: 2]Registration IP Addresses[/TD] [/TR] [TR] [TD=class: alt1, colspan: 2]No Matches Found[/TD] [/TR] [/TABLE] A, pula, am uitat ca am sters IP-urile...

Bravo, nu te-ai dat batut

$user = "cyber"; $pass = "gladiator";

[h=3]Attack of the week: TLS timing oracles[/h]Ever since I started writing this blog (and specifically, the posts on SSL/TLS) I've had a new experience: people come up to me and share clever attacks that they haven't made public yet. This is pretty neat -- like being invited to join an exclusive club. Unfortunately, being in this club mostly sucks. That's because the first rule of 'TLS vulnerability club' is: You don't talk about TLS vulnerability club. Which takes all the fun out of it. (Note that this is all for boring reasons -- stuff like responsible disclosure, publication and fact checking. Nobody is planning a revolution.) Anyway, it's a huge relief that I'm finally free to tell you about a neat new TLS attack I learned about recently. The new result comes from Nadhem AlFardan and Kenny Paterson of Royal Holloway. Dubbed 'Lucky 13', it takes advantage of a very subtle bug in the way records are encrypted in the TLS protocol. If you aren't into long crypto posts, here's the TL;DR: There is a subtle timing bug in the way that TLS data decryption works when using the (standard) CBC mode ciphersuite. Given the right set of circumstances, an attacker can use this to completely decrypt sensitive information, such as passwords and cookies. The attack is borderline practical if you're using the Datagram version of TLS (DTLS). It's more on the theoretical side if you're using standard TLS. However, with some clever engineering, that could change in the future. You should probably patch! For the details, read on. As always, we'll do this in the 'fun' question/answer format I save for these kinds of posts. What is TLS, what is CBC mode, and why should I care if it's broken? Some background: Transport Layer Security (née SSL) is the most important security protocol on the Internet. If you find yourself making a secure connection to another computer, there's a very good chance you'll be doing it with TLS. (Unless you're using UDP-based protocol, in which case you might use TLS's younger cousin Datagram TLS [DTLS]). The problem with TLS is that it kind of stinks. Mostly this is due to bad decisions made back in the the mid-1990s when SSL was first designed. Have you seen the way people dressed back then? Protocol design was worse. While TLS has gotten better since then, it still retains many of the worst ideas from the era. One example is the CBC-mode ciphersuite, which I've written about several times before on this blog. CBC-mode uses a block cipher (typically AES) to encrypt data. It's the most common ciphersuite in use today, probably because it's the only mandatory ciphersuitegiven in the spec. What's wrong with CBC mode? The real problem with TLS is not the encryption itself, but rather the Message Authentication Code (MAC) that's used to protect the integrity (authenticity) of each data record. Our modern understanding is that you should always encrypt a message first, then apply the MAC to the resulting ciphertext. But TLS gets this backwards. Upon encrypting a record, the sender first applies a MAC to the plaintext, then adds up to 255 bytes of padding to get the message up to a multiple of the cipher (e.g., AES's) block size. Only then does it CBC-encrypt the record. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Structure of a TLS record. The whole thing is encrypted with CBC mode.[/TD] [/TR] [/TABLE] The critical point is that the padding is not protected by the MAC. This means an attacker can tamper with it (by flipping specific bits in the ciphertext), leading to a very nasty kind of problem known as a padding oracle attack. In these attacks (example here), an attacker first captures an encrypted record sent by an honest party, modifies it, then re-transmits it to the server for decryption. If the attacker can learn whether her changes affected the padding -- e.g., by receiving a padding error as opposed to a bad MAC error -- she can use this information to adaptively decrypt the whole record. The structure of TLS's encryption padding makes it friendly to these attacks. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Closeup of a padded TLS record. Each byte contains the padding length, followed by another (pointless, redundant) length byte.[/TD] [/TR] [/TABLE] But padding oracle attacks are well known, and (D)TLS has countermeasures! The TLS designers learned about padding oracles way back in 2002, and immediately took steps to rectify them. Unfortunately, instead of fixing the problem, they decided to apply band-aids. This is a time-honored tradition in TLS design. The first band-aid was simple: eliminate any error messages that could indicate to the attacker whether the padding check (vs. the MAC check) is what caused a decryption failure. This seemed to fix things for a while, until some researchers figured out that you could simply time the server to see how long decryption takes, and thereby learn if the padding check failed. This is because implementations of the time would first check the padding, then return immediately (without checking the MAC) if the padding was bad. That resulted in a noticeable timing differential the attacker could detect. Thus a second band-aid was needed. The TLS designers decreed that decryption should always take the same amount of time, regardless of how the padding check comes out. Let's roll the TLS 1.2 spec: [T]he best way to do this is to compute the MAC even if the padding is incorrect, and only then reject the packet. For instance, if the pad appears to be incorrect, the implementation might assume a zero-length pad and then compute the MAC. Yuck. Does this even work? Unfortunately, not quite. When the padding check fails, the decryptor doesn't know how much padding to strip off. That means they don't know how long the actual message is, and therefore how much data to MAC. The recommended countermeasure (above) is to assume no padding, then MAC the whole blob. As a result, the MAC computation can take a tiny bit longer when the padding is damaged. The TLS designers realized this, but by this point they were exhausted and wanted to go think about something else. So they left us with the following note: This leaves a small timing channel, since MAC performance depends to some extent on the size of the data fragment, but it is not believed to be large enough to be exploitable, due to the large block size of existing MACs and the small size of the timing signal. And for the last several years -- at least, as far as we know -- they were basically correct. How does this new paper change things? The new AlFardan and Paterson result shows that it is indeed possible to distinguish the tiny timing differential caused by invalid padding, at least from a relatively close distance -- e.g., over a LAN. This is partly due to advances in computing hardware: most new computers now ship with an easily accessible CPU cycle counter. But it's also thanks to some clever statistical techniques that use many samples to smooth out and overcome the jitter and noise of a network connection. The upshot is that new technique can measure timing differentials of less than 1 microsecond over a LAN connection -- for example, if the attacker is in the same data center as your servers. It does this by making several thousand decryption queries and processing the results. Under the right circumstances, this turns out to be enough to bring (D)TLS padding oracle attacks back to life. How does the attack work? For the details, you should obviously read the full paper or at least the nice FAQ that Royal Holloway has put out. Here I'll try to give some intuition. Before I can explain the attack, you need to know a little bit about how hash-based MACs work. TLS typically uses HMAC with either MD5, SHA1 or SHA256 as the hash function. While these are very different hash functions, the critical point is that each one processes messages in 64-byte blocks. Consequently, hashing time is a function of the number of blocks in the message, not the number of bytes. Going from a 64-byte input to a 65-byte input means an entire extra block, and hence a (relatively) large jump in the amount of computation time (an extra iteration of the hash function's compression function). There are a few subtleties in here. The hash functions incorporate an 8-byte length field plus some special hash function padding, which actually means a one-block message can only contain about 55 bytes of real data (which also includes the 13-byte record header). The HMAC construction adds a (constant) amount of additional work, but we don't need to think about that here. So in summary: you can get 55 bytes of data into one block of the hash. Go a single byte beyond that, and the hash function will have to run a whole extra round, causing a tiny (500-1000 hardware cycle) delay. The attack here is to take a message that -- including the TLS padding -- would fall above that 55 byte boundary. However, the same message with padding properly removed would fall below it. When an attacker tampers with the message (damaging the padding), the decryption process will MAC the longer version of the message -- resulting in a measurably higher computation time than when the padding checks out. By repeating this process many, many thousand (or millions!) of times to eliminate noise and network jitter, it's possible to get a clear measurement of whether the decryption succeeded or not. Once you get that, it's just a matter of executing a standard padding oracle attack. But there's no way this will work on TLS! It'll kill the session! Please recall that I described this as a practical attack on Datagram TLS (DTLS) -- and as a more theoretical one on TLS itself.* There's a reason for this. The reason is that TLS (and not DTLS) includes one more countermeasure I haven't mentioned yet: anytime a record fails to decrypt (due to a bad MAC or padding error), the TLS server kills the session. DTLS does not do this, which makes this attack borderline practical. (Though it still takes millions of packet queries to execute.) The standard TLS 'session kill' feature would appear to stop padding oracle attacks, since they require the attacker to make many, many decryption attempts. Killing the session limits the attacker to one decryption -- and intuitively that would seem to be the end of it. But actually, this turns out not to be true. You see, one of the neat things about padding oracle attacks is that they can work across different sessions (keys), provided that that (a) your victim is willing to re-initiate the session after it drops, and ( the secret plaintext appears in the same position in each stream. Fortunately the design of browsers and HTTPS lets us satisfy both of these requirements. To make a target browser initiate many connections, you can feed it some custom Javascript that causes it to repeatedly connect to an SSL server (as in the CRIME attack). Note that the Javascript doesn't need to come from the target webserver -- it can even served on an unrelated non-HTTPS page, possibly running in a different tab. So in short: this is pretty feasible. Morover, thanks to the design of the HTTP(S) protocol, each of these connections will include cookies at a known location in HTTP stream. While you may not be able to decrypt the rest of the stream, these cookie values are generally all you need to break into somebody's account. Thus the only practical limitation on such a cookie attack is the time it takes for the server to re-initiate all of these connections. TLS handshakes aren't fast, and this attack can take tens of thousands (or millions!) of connections per byte. So in practice the TLS attack would probably take days. In other words: don't panic. On the other hand, don't get complacent either. The authors propose some clever optimizations that could take the TLS attack into the realm of the feasible (for TLS) in the near future. How is it being fixed? With more band-aids of course! But at least this time, they're excellent band-aids. Adam Langley has written a 500-line OpenSSL patch (!) that modifies the CBC-mode decryption procedure to wipe out the timing differentials used by this attack. I would recommend that you think about updating at least your servers in the future (though we all know you won't). Microsoft products should also see updates soon are allegedly not vulnerable to this attack, so won't need updates.** Still, this is sort of like fixing your fruitfly problem by spraying your kitchen with DDT. Why not just throw away the rotted fruit? In practice, that means moving towards modern AEAD ciphersuites like AES-GCM, which should generally end this madness. We hope. Why not switch to RC4? RC4 is not an option in DTLS. However, it will mitigate this issue for TLS, since the RC4 ciphersuite doesn't use padding at all. In fact, this ancient ciphersuite has been (hilariously) enjoying a resurgence in recent years as the 'solution' to TLS attacks like BEAST. Some will see this attack as further justification for the move. But please don't do this. RC4 is old and creaky, and we really should be moving away from it too. So what's next for TLS? I'd love to say more, but you see, the firstrule of TLS vulnerability club is... Notes: * The attack on Datagram TLS is more subtle, and a lot more interesting. I haven't covered it much in this post because TLS is much more widely used than DTLS. But briefly, it's an extension of some previous techniques -- by the same authors -- that I covered in this blog last year. The gist is that an attacker can amplify the impact of the timing differential by 'clogging' the server with lots of unrelated traffic. That makes these tiny differentials much easier to detect. ** And if you believe that, I have a lovely old house in Baltimore to sell you... Posted by Matthew Green at 4:00 AM Sursa: A Few Thoughts on Cryptographic Engineering: Attack of the week: TLS timing oracles

Nu e gratuit. Ai "platit" pentru Windows si Office

Patch de securitate urias de la Microsoft de Redactia Hit | 8 februarie 2013 Microsoft va publica, saptamana viitoare, un update de securitate pentru Windows ce contine nu mai putin de 57 de patch-uri pentru eliminarea bug-urilor. Pachetul va contine 12 update-uri de securitate dintre care cinci sunt considerate critice. Vizate pentru eliminarea vulnerabilitatilor sunt Windows-ul, Internet Explorer-ul si suita Office. Din numarul total de update-uri, cinci sunt dedicate Windows 7, patru Windows 8 si trei Windows XP SP3, afirma reprezentantii companiei nCircle. Nu este prima data cand Microsoft publica astfel de pachete "monstru" cu update-uri de securitate, scrie Computerworld. In aprilie 2011, compania punea la dispozitia utilizatorilor un patch cu nu mai putin de 64 update-uri pentru eliminarea unor vulnerabilitati in programele sale. Sursa: Computerworld.com Via: Patch de securitate urias de la Microsoft | Hit.ro

APISPY32 Be sure to read Readme.txt! It now works with executables that have their IAT merged into read-only data sections. I've run it successfully on Windows 2000 and Windows XP. Oldie... http://www.wheaty.net/APISPY32.zip

Cum func?ioneaz? un centru pentru testarea antiviru?ilor Un articol din seria “cum func?ioneaz?”, dar nu v? ar?t nici o fabric? de ma?ini ?i nici depozitul eMAG, ci un centru de testare a antiviru?ilor. În lume sunt dou? mari organiza?ii independente de testare: AV-Comparatives din Austria, mai exact Innsbruck, ?i AV-Test din Germania. Acum sunt la AV-Comparatives. Ce vede?i mai jos este camera de control a testului. Testele comparative sunt foarte complexe pentru c?: se folosesc computere reale, nu ma?ini virtuale (unii viru?i reac?ioneaz? altfel pe VM). se testeaz? pe configura?ii normale, asem?n?toare de media din comer? dpdv hardware ?i software instalat. programele de securitate sunt testate pe aproximativ 200.000 – 300.000 de viru?i descoperi?i în ultimele luni ?i multe URL-uri de phishing ?i malware. în toate testele se fac screenshot-uri, log-uri de fi?iere modificate, ce ?i cum a detectat antivirusului, când ?i cum a reac?ionat, plus clipuri video. situa?iile se salveaz? pentru replicare ulterioar?. De aici rezult? configura?ia uimitoare a centrului de testare. rackurile din stânga sunt pline de sta?ii de lucru, câteva zeci de buc??i. 25 de monitoare sunt disponibile pentru a fi conectate la sta?ii. rack-ul din dreapta con?ine servere de control ?i 400 TB de spa?iu de stocare. în total au 600 GB de memorie RAM instalat? în echipamente. serverul de control ruleaz? un soft dezvoltat de AV-Comparatives care porne?te ?i opre?te sta?iile de testare, le instaleaz? sistem de operare, le atac?, le pune s? intre pe net pe site-uri dubioase, s? se uite la pornografie, s? dea click pe linkuri din emailuri ciudate, s? instaleze toate toolbar-urile pe care le vor. Tot acest server face ?i screenshot-uri, video-uri, loguri ?i tot restul. au 3 conexiuni independente la net, 256 de IP-uri ?i acces la IP-uri din întreaga lume (unele malware-uri infecteaz? doar anumite ??ri, a?a c? trebuie simulat c? ar fi de acolo). De ce se pune mare pre? pe rezultatele testelor AV-Comparatives? Pentru c? au o procedur? de testare foarte bine pus? la punct, exhaustiv?, care minimizeaz? ?ansa de a gre?i un test ?i pentru c? sunt o organiza?ie independent?. E genul de industrie în care conteaz? nu numai rezultatul, ci ?i cine a f?cut testul, iar AV-Comparatives este un nume respectat în toat? lumea. De ce i-ai crede c? sunt independen?i? Eu i-am crezut. Am v?zut aici numai oameni pasiona?i de acest domeniu, oameni care au pornit de la zero din dorin?a de a testa pe bune ?i au creat o organiza?ie mare ?i frumoas?. În plus, procedura de testare, fiecare detaliu, este discutat cu fiecare furnizor de antivirus ?i cei care au obiec?ii pot cere modificarea ei. Dup? testare produc?torii au acces la toate log-urile ?i rezultatele detaliate, astfel încât dac? vor considera c? au fost depuncta?i inutil sau c? testele au fost gre?ite pot face contesta?ii ?i se poate resimula totul. O parte din independen?? vine ?i din metodele de finan?are. AV-Comparatives cere o sum? fix? de la fiecare produc?tor care dore?te s? introduc? un produs în test, un fel de tax? de participare. În plus sunt finan?a?i de dou? universit??i prin programe de cercetare (Innsbruck ?i Hong Kong), de un institut de dezvoltare a tehnologiei ?i de statul austriac, care vrea s? ?tie ce antivirus s? cumpere. AV-Comparatives nu are profit. Au cheltuieli anuale de aproximativ 500.000 de euro ?i le sus?in din aceste finan??ri f?r? a face ?i profit. Programatorii care au f?cut softul de control ?i testare automatizat? (i-am cunoscut ieri, tinerei) au f?cut o frumuse?e de program. Am v?zut screenshot-uri ?i pe cât de complex este pe atât de u?or de în?eles dintr-o privire mi s-a p?rut. Nu doar partea de raportare ?i logging, dar pân? ?i pe screenshot-urile ce se fac periodic se ruleaz? programe OCR care identific? eventualele mesaje de la antivirus, automatizând întregul proces. Am apreciat ?i grija pentru detalii. URL-urile cu malware se testeaz? simultan, pentru c? în timp dispar sau sunt raportate ca fiind nocive. Bine, nu chiar simultan, ci la o întârziere de 5 secunde, pentru a nu porni fix în acela?i timp toate ma?inile ?i a nu face un fel de spam acolo. ?i testeaz? simulând IP-uri dintr-o anumit? ?ar?, dar mereu schimbate, pentru c? unele malware nu infecteaz? acela?i IP de dou? ori, ba chiar ?i cu diverse set?ri localizate de Windows. V-am spus, oameni pasiona?i ?i aten?i la toate detaliile. Nimic din ce am auzit c? fac nu mi s-a p?rut “la nimereal?”. Conteaz? un astfel de premiu de la AV-Comparatives? Da, foarte mult. Când o revist? precum PC Magazine, cu milioane de cititori, spune “cump?ra?i Bitdefender pentru c? exper?ii de la AV-Comparatives spun c?-i cel mai bun ?i noi avem încredere în ei”, e ceva. Apoi în lumea corporate sunt foarte multe echipe tehnice care nu pot testa chiar ele toate programele de pe pia?? atunci când aleg un soft pentru o firm? cu mii de calculatoare, dar care au încredere în AV-Comparatives ?i rezultatele lor. E ca atunci când e?ti bolnav ?i ai încredere în ce-?i recomand? medicul, nu te apuci tu s? înve?i medicina de la zero. Bine, nu m? îndoiesc c? la noi în ?ar? vor fi mul?i care vor spune c? ?tiu ei mai bine c? X e mai bun ?i Y e mai lent ?i Z nu detecteaz? nimic, bazat nu pe teste de 300.000 de viru?i, ci pe 1-2 p??anii personale. Cu alt? ocazie v? spun mai multe despre Bitdefender pentru c? am avut ocazia s? discut una alta cu CEO-ul companiei, dl. Florin Talpe?. Pân? atunci, mai jos este un top al antiviru?ilor pentru rezultatele unui test Real World Protection Test de anul trecut: Bitdefender G Data Trend Micro F-Secure BullGuard Qihoo 360 (popular în China) Kaspersky Cele cu bold folosesc tehnologie Bitdefender, cump?rat? de la români de c?tre respectivele firme sub forma unor parteneriate. V-am mai spus c? avem toate motivele s? fim mândri c? un soft atât de performant ?i avansat dpdv al tehnologiei de detec?ie este produs integral în România. Sursa: Cum func?ioneaz? un centru pentru testarea antiviru?ilor | nwradu blog

fixed realm buffer size Deloc profesional...

Trebuie vazut: DevOps Reactions

Daca ar pune la noi, sa presupunem: 1. Un user descarca de pe filelist cu 10 MB/s 2. Traficul mediu este de 100 KB/s Bucuresti, 2 milioane de locuitori, 510.000 de persoane cu acces la internet, 10.000 descarca de ep filelist. 10.000 * 10 MB + 500.000 * 0.1 MB/s = 100.000 MB/s + 50.000 MB/s = 100 TB/s + 50 TB/s = 150 TB/s Dintre care RDS sa presupunem ca are 100 TB/s. Sa filtrezi toate acele pachete, nu pare imposibil, dar pare aproape imposibil. Bine, realist vorbind, cu legea Big Brother prin care ISPii erau obligati sa pastreze loguri, probabil salveaza capetele conexiunii, sursa si destinatia IP ceea ce inseamna ca sa face o "despachetare" a pachetelor deja. Asta mai inseamna si faptul ca, sarind peste headerele TCP/IP se poate obtine usor linia "GET /page.php?id=-1 union..." siliniea de "Host: www.rds.ro" care sa fie pastrate in loguri. Voi ce parere aveti? In orice caz, TOR rullz!