dekeeu

Ai incercat sa te conectezi la baza de date ?

Ciuc . Te astept cu ceva si pe aici: https://rstforums.com/forum/bug-bounty.rst / https://rstforums.com/forum/club-showoff.rst pentru ca am observat ca ai potential little gift pe PM .

The Android operating system has hardened its security with application Sandboxing features to ensure that no application can access sensitive information held by another without proper privileges. Android applications communicate with each other through Intents and these intents can be abused by hackers to provide a channel for a malicious application to inject malicious data into a target, potentially vulnerable application. Security Researchers at IBM have discovered multiple vulnerabilities in Firefox for Android platform that allow a malicious application to leak the sensitive information related to the user's profile. Android's Firefox app stores the personal data at following location: /data/data/org.mozilla.firefox/files/mozilla/<RANDOM-STRING>.default. Where the random name for user's profile is used to prevent unwanted access to this directory in case of Firefox exploitation. Researchers developed an exploit to brute-force the <RANDOM-STRING> Firefox profile directory name in a practical amount of time CVE-2014-1516) and successfully bypassed Android’s sandbox to obtain the sensitive data reside in that directory, including users' cookies, browsing history and cache information. For successful exploitation, an attacker can create a specially crafted HTML file, that will force Firefox to load the files including inside the user profile directory using an Intent. The JavaScript code in the HTML file will download any file under the user profile directory by creating an iframe, using the vulnerability dubbed as CVE-2014-1515 (explained below). Downloaded files with the exploit code will be saved automatically to the SD card at location /mnt/sdcard/Download, that can be read by the attacker using any malicious Android app. REPORTED VULNERABILITIES 1.) Profile Directory Name Weak Randomization (CVE-2014-1516) - The Attacker who knows the seed of the Pseudo-Random Number Generator (PRNG) can easily predict its output and eventually the generated Firefox Profile name. 2.) Profile Directory Name Leaks to Android System Log (CVE-2014-1484) - Android operating system writes the randomly generated Firefox user's Profile Directory Name in the Android System Log (logcat) at various locations, that can be used to steal private information. In Android version 4.0 and below, installed apps with READ_LOGS permission can easily read Android system logs to identify the name of the Firefox user profile folder. 3.) Automatic File Download to SD Card (CVE-2014-1515) - Firefox for Android will download any file automatically to the SD card, if not of any known extension. Malicious apps with READ_EXTERNAL_STORAGE permission can read files from the SD card to extract non-renderable data such as the cookies database. 4.) Crash Reporter File Manipulation (CVE-2014-1506) - In cases where the application crashes, Firefox sends the crash dumps located in /data/data/org.mozilla.firefox/files/mozilla/Crash Reports/pending on the device file system. Using the exploit, an attacker can manipulate the crash report file path to the Android Log file in order to steal it. Researchers have also explained second way to hack user data using this vulnerability. Researchers have already reported these vulnerabilities to the Mozilla and three out of four are already been patched in the latest versions. Android users with Firefox installed in the device are advised to upgrade it to Mozilla Firefox 28.0 or later from the Google Play app store. Source: THN ? Multiple Vulnerabilities in Firefox for Android Leak Sensitive Information

After posting an introduction to FuzzDB I received the suggestion to write more detailed walkthroughs of the data files and how they could be used during black-box web application penetration testing. This article highlights some of my favorite FuzzDB files and discusses ways I’ve used them in the past. If there are particular parts or usages of FuzzDB you’d like to see explored in a future blog post, let me know. Exploiting Local File Inclusion Scenario: While testing a website you identify a Local File Inclusion (LFI) vulnerability. Considering the various ways of exploiting LFI bugs, there are several pieces of required information that FuzzDB can help us to identify. (There is a nice cheatsheet here: Exploiting PHP File Inclusion – Overview | Reiners' Weblog) The first is directory traversal: How far to traverse? How do the characters have to be encoded to bypass possible defensive relative path traversal blacklists, a common but poor security mechanism employed by many applications? FuzzDB contains an 8 directory deep set of Directory Traversal attack patterns using various exotic URL encoding mechanisms:https://code.google.com/p/fuzzdb/source/browse/trunk/attack-payloads/path-traversal/traversals-8-deep-exotic-encoding.txt For example: /%c0%ae%c0%ae\{FILE} /%c0%ae%c0%ae\%c0%ae%c0%ae\{FILE} /%c0%ae%c0%ae\%c0%ae%c0%ae\%c0%ae%c0%ae/{FILE} In your fuzzer, you’d replace {FILE} with a known file location appropriate to the type of system you’re testing, such as the string “etc/password” (for a UNIX system target) then review the output of the returned request responses to find responses indicating success, ie, that the targeted file has been successfully retrieved. In terms of workflow, try sorting the responses by number of bytes returned, the successful response will most become immediately apparent. The cheatsheet discusses a method of including injected PHP code, but in order to do this, you need to be able to write to the server’s disk. Two places that the HTTPD daemon typically would have write permissions are the access and error logs. FuzzDB contains a file of common location for HTTP server log files culled from popular distribution packages. After finding a working traversal string, configure your fuzzer to try these file locations, appended to the previously located working directory path: https://code.google.com/p/fuzzdb/source/browse/trunk/attack-payloads/lfi/common-unix-httpd-log-locations.txt Fuzzing for Unknown Methods Improper Authorization occurs when an application doesn’t validate whether the current user context has permission to perform the requested command. One common presentation is in applications which utilize role-based access control, where the application uses the current user’s role in order to determine which menu options to display, but never validates that the chosen option is within the current user’s allowed permissions set. Using the application normally, a user would be unlikely to be able to select an option they weren’t allowed to use because it would never be presented. If an attacker were to learn these methods, they’d be able to exceed the expected set of permissions for their user role. Many applications use human-readable values for application methods passed in parameters. FuzzDB contains list of common web method names can be fuzzed in an attempt to find functionality that may be available to the user but is not displayed by any menu. https://code.google.com/p/fuzzdb/source/browse/trunk/attack-payloads/BizLogic/CommonMethods.fuzz.txt These methods can be injected wherever you see others being passed, such as in GET and POST request parameter values, cookies, serialized requests, REST urls, and with web services. Protip: In addition to this targeted brute-force approach it can also be useful to look inside the site’s Javascript files. If the site designers have deployed monolithic script files that are downloaded by all users regardless of permissions where the application pages displayed to a user only call the functions that are permitted for the current user role, you can sometimes find endpoints and methods that you haven’t observed while crawling the site. Leftover Debug Functionality Software sometimes gets accidentally deployed with leftover debug code. When triggered, the results can range from seeing extended error messages that reveal sensitive information about the application state or configuration that can be useful for helping to plan further attacks to bypassing authentication and/or authorization, or to displaying additional test functionality that could violate the integrity or confidentiality of data in ways that the developers didn’t intend to occur in a production scenario. FuzzDB contains a list of debug parameters that have been observed in bug reports, in my own experience, and some which are totally hypothesized by me but realistic: https://code.google.com/p/fuzzdb/source/browse/trunk/attack-payloads/BizLogic/DebugParams.fuzz.txt Sample file content: admin=1 admin=true admin=y admin=yes adm=true adm=y adm=yes dbg=1 dbg=true dbg=y dbg=yes debug=1 debug=true debug=y debug=yes “1” “true” “y” and “yes” are the most common values I’ve seen. If you observe a different but consistent scheme in use in the application you’re assessing, plug that in. In practice, I’ve had luck using them as name/value pairs for GET requests, POST requests, as cookie name/value pairs, and inside serialized requests in order to elicit a useful response (for the tester) from the server. Predictable File Locations Application installer packages place components into known, predictable locations. FuzzDB contains lists of known file locations for many popular web servers and applications https://code.google.com/p/fuzzdb/source/browse/trunk/#trunk%2Fdiscovery%2FPredictableRes Example: You identify that the server you’re testing is running Apache Tomcat. A list of common locations for interesting default Tomcat files is used to identify information leakage and additional attackable functionality.https://code.google.com/p/fuzzdb/source/browse/trunk/discovery/PredictableRes/ApacheTomcat.fuzz.txt Example: A directory called /admin is located. Sets of files are deployed which will aid in identifying resources likely to be in such a directory. https://code.google.com/p/fuzzdb/source/browse/trunk/discovery/PredictableRes/Logins.fuzz.txt Forcible Browsing for Potentially Interesting Files Certain operating systems and file editors can inadvertently leave backup copies of sensitive files. This can end up revealing source code, pages without any inbound links, credentials, compressed backup files, and who knows what. FuzzDB contains hundreds of common file extensions including one hundred eighty six compressed file format extensions, extensions commonly used for backup versions of files, and a set of primitives of “COPY OF” as can be prepended to filenames by Windows servers. https://code.google.com/p/fuzzdb/source/browse/#svn%2Ftrunk%2Fdiscovery%2FFilenameBruteforce In practice, you’d use these lists in your fuzzer in combination with filenames and paths discovered while crawling the targeted application. Upcoming posts will discuss other usage scenarios. Sursa: https://blog.mozilla.org/security/2014/03/25/using-fuzzdb-for-testing-website-security/

https://www.google.ro/search?q=site:rstforums.com+intitle:mata-i+grasa

Today, I’d like to describe a new technique we’ve come to call Reverse Clickjacking. The situation when this technique becomes useful typically arises when a user-controlled parameter is used when constructing a URL, and the parameter is not properly escaped. Consider the following code example. <script> var params = location.search.parseQuery(); var query = params["q"] || "Regina Spektor"; var script = document.createElement("SCRIPT"); script.src = "https://ajax.googleapis.com/ajax/services/search/web?v=1.0&q=" + query + "&callback=handle_search_result"; document.body.appendChild(script); window.handle_search_result = function (json) {... }; window.delete_user_data = function () {... };</script> You can play around with it at - jsFiddle demo and modify it at Edit fiddle - JSFiddle. For a real-world example, take a look at Paul's blog post at @Paul_Axe : Two stories about XSS on Google. Notice there is a weakness in the code. The attacker-controlled "q" parameter is not URL-escaped when generating the search URL. OK, so how do we exploit this? We can use weakness to inject additional parameters into the URL. More specifically, we can override the callback parameter, and call a function of our choice. You'll notice that in the code snippet, we have a function called delete_user_data defined at the global level. We can call this using the JSONP callback to obtain a working exploit. Try this live at - jsFiddle demo. More commonly, we don't have any dangerous global functions, but instead we do have buttons that do interesting things. Consider this code. <div> <center> <h1>Welcome to this website.</h1> <button id=delete_user_data_button onclick="delete_user_data()">Delete all my data!</button> </center></div> Since button in question has a ID that is a valid JavaScript identifier, we can call it directly, e.g. - jsFiddle demo. Otherwise we can navigate through the DOM using firstElementChild and nextElementSibling, i.e. - jsFiddle demo. OK, so what can we do if the page containing the vulnerability does not contain any buttons or any interesting global functions? If we can find an interesting buttons on any other pages on the same domain, we can call them extending the technique described above. Suppose the vulnerable page is at - jsFiddle demo and the page with interesting button is at - jsFiddle demo. We construct our exploit as follows: <iframe src="http://fiddle.jshell.net/D5nZ7/1/show?q=elephants%26callback=parent.frames.btn_frame.document.body.firstElementChild.click%23" name="vuln_frame"></iframe><iframe src="http://fiddle.jshell.net/g5P9H/1/show" name="btn_frame"></iframe> See the code live at http://jsbin.com/vifuholi/1/edit. If either of the pages disallow embedding using X-Frame-Options, IFrames will not work, but that is not a fatal problem. Instead, we can open a pop-up window to another page we control and navigate the opener window to the button page. In the new pop-up, we wait for the main window to load the button page, and then navigate ourselves to the vulnerable page, which will do the clicking by accessing the button through window.opener. In previous versions of Chrome, pop-up windows that were blocked by the pop-up blocker were nevertheless executed, though their window were hidden from view. An more recent versions, in other browsers, we need a real user click to launch the initial pop-up. If you guys know a bypass, let us know in the comments. Code to do all this, along with clicking multiple buttons, is left as an exercise for the reader. Sursa: https://plus.google.com/u/0/+AleksandrDobkin-Google/posts/JMwA7Y3RYzV?cfem=1

Now that the dust has settled after the Pwn2Own contest, the browser manufacturers are beginning to roll out patches for the vulnerabilities exploited by contestants. Google on Monday released fixes for a number of bugs in Chrome discovered and exploited during Pwn2Own, releasing new versions of the browser for Windows, Mac and Linux. This year’s Pwn2Own, which runs in conjunction with the CanSecWest conference in Vancouver, showcased vulnerabilities and exploits in most of the major browsers, including Internet Explorer and Firefox, along with Chrome. The team from VUPEN, the French security and exploit-sales firm, took home several hundred thousand dollars in prize money from the contest, a good portion of it for demonstrating new bugs in Google Chrome. In addition to the prize money from the contest, Google also is paying its own rewards to the researchers who used new flaws in Chrome. VUPEN earned a $100,000 reward from Google for its two Chrome vulnerabilities, and an anonymous researcher also earned $60,000 for two separate vulnerabilities. The flaws used in Pwn2Own that Google fixed in Chrome 33 are: [$100,000] [352369] Code execution outside sandbox. Credit to VUPEN. -[352374] High CVE-2014-1713: Use-after-free in Blink bindings -[352395] High CVE-2014-1714: Windows clipboard vulnerability [$60,000] [352420] Code execution outside sandbox. Credit to Anonymous. -[351787] High CVE-2014-1705: Memory corruption in V8 -[352429] High CVE-2014-1715: Directory traversal issue Patches for Internet Explorer and Firefox likely will take a little longer, as they’re on longer update cycles than Google, which typically pushes out new versions whenever significant security issues need to be fixed. Google security officials said that they plan to publish some details of the exploits used against Chrome in Pwn2Own in the coming weeks. “We’re delighted at the success of Pwn2Own and the ability to study full exploits. We anticipate landing additional changes and hardening measures for these vulnerabilities in the near future. We also believe that both submissions are works of art and deserve wider sharing and recognition. We plan to do technical reports on both Pwn2Own submissions in the future,” Anthony Laforge of Google said in a blog post. Sursa: Google Patches Four Pwn2Own Bugs in Chrome 33 | Threatpost | The first stop for security news

In cazul meu , RST-ul chiar m-a ajutat enorm in sensul ca am gasit ceva cu care sa-mi ocup timpul liber intr-un mod extrem de profitabil. Daca nu erau aici cateva persoane marcante , gen expl0iter , poq , etc nu imi gaseam niciodata pasiunea pentru aplicatiile web si securizarea acestora si in principiu nu descopeream nici programele de bug-bounty care mi-au adus "independenta" financiara .

Introduction We have already disclosed lots of findings related to DOM Based XSS and this article talks about a pretty interesting DOM Based XSS vulnerability i found long time back inside paypal. A DOM Based xss vulnerability also known as the third type of XSS vulnerability or type 0. This vulnerability occurs due to the fact that developers don't sanitize the input before it reaches a sink. A Sink is defined as anything that generates HTML, not every sink is considered as dangerous, however there are some common sinks that should be avoided and are mentioned at DOM Based XSS wiki . - See more at: A Tale Of A DOM Based XSS In Paypal | Learn How To Hack - Ethical Hacking and security tips Current Situation The situation with DOM Based xss is getting worse now a days, not only because of dynamic JS libraries such as YUI, Jquery, Jquery mobile etc, but also with programming languages such as PHP that are more natively supporting HTML 5 features. One of the aspects of a DOM Based XSS vulnerability that i discovered was with tracking scripts such as Eloqua, Sitestat, Omniture, etc as they often introduce dangerous sinks. Examples are here and here. The same is the case with sharing buttons such as google plus, addthis etc. A Vulnerable Example from W3schools The worsed part about DOM Based xss apart from it's complexity is the fact that lots of learning references and guides teach developers to code things in an insecure way i.e. in a way that would introduce vulnerabilities automatically. The following screenshot is taken from the jquery learning section of w3schools. The website needs no introduction, it is the most commonly referred websites for beginners to learn various programming language. The code uses the html() function inside of jquery to output html, however the problem is that html() is not a safe jquery function and is represented as a dangerous sink as per DOM Based XSS Wiki. In case, where a user controlled input outputted through html() sink without sanitization would lead to a DOM Based xss. The html() function inside of jquery is the equivalent to the innerHTML function inside of javascript. The fundamental problem is that the developers are not advised to use a safe function. Therefore, in my opinion w3schools shall be renamed to w3fools. The Tale Of Paypal DOM Based XSS The financing.paypal.com subdomain was a subject of DOM Based xss vulnerability. The subdomain had a feature which triggered my interest, which allowed the users to create ad units of different sizes. The size of the ad was being handled on the client side with the help of jquery. Example https://financing.paypal.com/ppfinportal/adGenerator/webCopy?460 * 80 The above input would display "460 * 80" in front of the Selected Size Option, Changing the text with our own input would result in the same text being outputted on to the screen. This means that our input that is taken from a source is being passed through a sink to be displayed upon the screen. So, what happens if we change the input with our XSS payload, for example - <svg/onload=prompt(1)>. https://financing.paypal.com/ppfinportal/adGenerator/webCopy?<svg/onload=prompt(1)> Unfortunately, the results were returned URL encoded. Now there could be two possibilities, whether the javascript is encoding our input before rendering it on the screen or it's a general browser behaviour. Turns out that Google Chrome and Firefox browsers encode everything sent after ?, but what about Internet explorer?, Internet explorer returns the characters as URL unencoded and therefore, we inside of internet explorer we are able to render our javascript. With that being said, as per DOM Based XSS wiki google chrome does not encode certain characters when passed after a hash. Therefore, we could add an additional hash after the ? mark to get our payload executed. Example https://financing.paypal.com/ppfinportal/adGenerator/webCopy?#<svg/onload=prompt(1)> Vulnerable Code With some debugging i was able to determine the exact cause of the vulnerability. The following screenshot highlights the line of code that was responsible for the cause of this vulnerability. The line 517 represents the source being document.url, a split function is called which splits everything being sent after the ? mark and saves it inside a variable called url. Example https://financing.paypal.com/ppfinportal/adGenerator/webCopy?#<svg/onload=prompt(1)> The split function would return <svg/onload=prompt(1)> from the url and then is saved inside a variable called url. Next inside the 521 line we can see that html() function is used to output url variable, which in this case contains our xss paylaod. The payload would be outputted to the screen and hence would execute the javascript for us. Source: A Tale Of A DOM Based XSS In Paypal | Learn How To Hack - Ethical Hacking and security tips

Traducere din engleza in romana nu-ti fac. Nu mai fa tutoriale tampite si induce lumea in eroare. Deja cand spui "vezi cine ti-a vizitat profilul" automat te gandesti la o vulnerabilitate web si cum tu nu prea pari genul, cel mai sigur "descoperirea" ta este ~= nimic.

Pai nu prea : https://www.facebook.com/help/community/question/?id=10201206953830505 .

" Escaping is tricky, as demonstrated by a recent Gmail bug found by Roman Shafigullin. First, what are the escaping rules in HTML? Surely you already know that < > and & have to be escaped into <, > and &. How about URLs? The browser will use percent decoding (e.g. %20 for space) to parse the URL. Now how would you escape a user string in <a href="javascript:call('user string')">? It's JavaScript so JavaScript escaping rules apply as well. Among other things we want to avoid '. Would it be enough to escape ' with \x27? Unfortunately no. To understand how to properly escape this, it's important to know which decoding the browser will apply and as importantly, in which order. The browser first HTML decodes the attribute, then URL decodes the whole string and lastly passes it to the JavaScript parser. It means that: <a href="javascript:call('%27-alert(1)-%27')">is URL percent decoded to: javascript:call(''-alert(1)-'') and then passed to the JavaScript parser which interprets the code as an empty string '' followed by a call to alert(1). This is obviously bad. Instead, we want to apply proper escaping, in order: 1) JavaScript escaping 2) URL percent encoding 3) HTML escaping This bug was present in Gmail mobile UI at https://mail.google.com/mail/mu - yes, there are multiple UIs for some products! As seen on Roman Shafigullin screenshot, the bug was triggered by sending an email with a bogus mailto: <a href="mailto:test-01-%27-alert(1)-%27-test@test.com">test</a> Gmail mobile parses the mailto and renders the link as: <a href="javascript:_e({}, 'cvml', 'test-01-%27-alert(1)-%27');" target="_blank">test</a> It looks fine, however as we discussed earlier the first thing the browser does is URL decoding so %27 is decoded into a single quote and as a result the alert breaks out of the string parameter: javascript:_e({}, 'cvml', 'test-01-'-alert(1)-''); The browser will execute alert(1) when the link is clicked. Oops! To fix this, Gmail fixed the escaping to first JavaScript escape and second URL encode. Nice catch +Roman Shafigullin!? " Sursa: https://plus.google.com/u/0/+AlexisImperialLegrandGoogle/posts/f9gm2G2BH5g

Licente: TTVYSFRWRA== NlQ2SlNZUQ== VElLVUNSTQ== AV-ul il descarcati de aici: Click *Soft-ul e in germana si licenta e doar pe 6 luni. Din cate vad, aici e vorba de niste sponsorizari, dar licentele pe 12 luni oferite de "pcwelt" s-au epuizat dat fiind faptul ca: if(window.location.hash == '#pcwelt') { window.location.replace("http://www.bitdefender.de/media/html/circleoftrust/?OD_ID=100754"); . Daca mai aveti nevoie de licente accesati link-ul urmator: Product Page sau #blast si folositi ip de Germania.

Vedeti ca si-au updatat bajetii regulile : Security | Magento

T?t esti tu ?mecher.

Am trimis mai multe rapoarte la ei , dar toate au status "New" de 2 saptamani. Ori se misca prea greu , ori nu au chef ori nu stiu.. Dar tabelul ala oricum trebuie respectat, zic eu.

http://s29.postimg.org/4agtmc8yf/f_Lpx.png In realitate, am undeva pe la 50 ..

Sunt putin cam sceptic in prinvinta xss-ului tau dat fiind faptul ca, inainte, pentru orice caracter introdus in parametrul "id" altul decat o litera sau o cifra inainte iti dadea "Not Found" . Si vectorul tau e atat de 1337 incat nu ma gandesc sa fi facut bypass la filtru. Poza necenzurata n-ai ? Eventual si cu sursa paginii ca sa vad unde anume s-a reflectat valoarea parametrului ? (ca sa nu mor prost..nu de altceva).

Mai bine va luati 3 tablete la fiecare si scapati mai ieftin

Instaleaza Ccleaner - sterge cookie/cache . Folosesti proxy ?

Si eu am primit pentru un SQLi: [FONT=arial]Hi X,[/FONT] [FONT=arial]At the time of the report we had not completed the details around the bug bounty program. The program scope covers [/FONT][URL="http://yahoo.com/"]yahoo.com[/URL][FONT=arial] and [/FONT][URL="http://flickr.com/"]flickr.com[/URL][FONT=arial] along with the respective mobile and client side apps. ([/FONT][url=http://bugbounty.yahoo.com/]Yahoo - Bug Bounty Program Rules[/url][FONT=arial])[/FONT] [FONT=arial]The bug on [/FONT][URL="http://yahoo.net/"]yahoo.net[/URL][FONT=arial] was found to be out of scope. We have listed you as a contributor on the Wall of Fame to show our appreciation.

Si SQLi-ul se incadreaza ?

Aceleasi chestii le-am gasit si eu intr-un .net si n`am mai primit nimic de 3 luni .

Prin concluzie unde e vulnerabilitatea ?