Nytro

Da, corect, eu vazusem ca parolele generate de acele site-uri au 7 caractere, nu am numarat bine, au 8.

Cea mai comuna metoda e sa capturezi un handshake si sa spargi parola. In particular, pentru UPC, pentru anumite modele de routere probabil, exista acea metoda de "generare" a parolei deoarece se foloseste un algoritm dobitoc. Daca nu merge, parola default cred ca e ceva de genul acela. Da, parola se poate schimba cu ce vrea utilizatorul.

Aparent, parolele au 7 caractere si sunt doar litere mari. Captureaza un WPA2 handshake si seteaza un mask pentru cracking la parola care sa acopere doar acest key space.

Probabil se gaseste e okazii sau pe olx.

Producatorul roman de ceasuri inteligente Vector Watch a fost cumparat de Fitbit de Raluca Abrihan 10 ianuarie 2017 11.39 Vector Watch, startup-ul romanesc producator de ceasuri smart cu autonomia de o luna, a fost cumparat de compania americana Fitbit, cunoscuta pentru bratarile inteligente de fitness cu acelasi nume. “Azi, suntem bucurosi sa anuntam ca echipa Vector Watch si platfomra noastra software se alatura comaniei Fitbit lider pe piata de dispozitive purtabile de fitness si sanatate”, a anuntat startup-ul local Vector Watch pe site-ul oficial. Compania a fost lansata in 2015, iar pachetul majoritar de actiuni era detinut de Gecad Ventrures, fond de investitii local controlat de omul de afaceri Radu Georgescu. Vector Watch se vinde in 25 de piete, la un an de la lansare. In afara de pietele foarte mari, SUA, Marea Britanie, ceasul a fost lansat si in piete exotice precum Thailanda, Singapore, Malaezia si Filipine. Ceasul se vinde in peste 500 de puncte de vanzare, incluzand aici atat magazinele fizice , cat si cele online. Amazon este principalul canal de vanzari la nivel mondial, dar vanzari importante sunt generate si prin Orange cu care au fost semnate parteneriate in mai multe tari. De exemplu ceasul se vinde la cel mai mare magazin Orange din Paris si foarte recent a fost semnat un parteneriat cu Microsoft UK, astfel incat ceasul poate fi cumparat de pe magazinul online al companiei americane, fiind printre putinele smartwatch-uri premium care au aplicatie pe Windows. Vector Watch are 40 de angajati. Echipa de dezvoltare este la Bucuresti, o mica echipa de vanzari se afla in SUA si mai exista o echipa de vanzari in regiunea EMEA. Din punct de vedere retail si financiar sediul este la Londra unde se gasesc si stocurile, in timp ce in Romania este "sediul tehnologic". Fitbit este cel mai mare jucator din piata dispozitivelor "wearable" si a vandut in cel de al doilea trimestru al anului trecut 5,3 milioane de dispozitive "wearable", avand 23% din piata. Sursa: http://www.startupcafe.ro/stiri-afaceri-21523479-vector-fitbit-cumparat-vanzare-ceasuri-inteligente.htm

Vă mai amintiţi de laptopul cu 3 ecrane prezentat de Razer la CES? A fost furat Adrian Popa - 9 ian 2017 Razer a făcut valuri la CES 2017 cu laptopul său cu trei ecrane. Deşi un prototip, dispozitivul arată ce se poate face cu tehnologia de azi. Computerul a atras din nou atenţia după ce a fost furat de la salon, în ultima zi. Hoţul a furat două concepte ale companiei, printre care şi laptopul cu trei ecrane. „Am fost informat că două dintre prototipurile noastre au fost furate astăzi din cabina de la CES”, a scris pe Facebook şeful companiei, Min-Liang Tan. Organizatorii CES şi poliţia au deschis o anchetă şi încearcă să găsească hoţul. Nu este prima dată când Razer atrage atenţia hoţilor. În 2011, două prototipuri de laptopuri Blade au fost furate din centrul de cercetare şi dezvoltare al companiei din San Francisco. Nu este exclusă nici varianta spionajului industrial. Este foarte posibil ca dispozitivele concept să fi fost furate de o companie rivală pentru a fi studiate în detaliu. Sursa: http://www.go4it.ro/curiozitati/va-mai-amintiti-de-laptopul-cu-3-ecrane-prezentat-de-razer-la-ces-a-fost-furat-16053902/

Yahoo s-a dus, rămășițele sale devin Altaba by unacomn on 10/01/2017 Achiziția companiei Yahoo de către conglomeratul de telecomunicații american Verizon s-a încheiat. Această afacere se află în desfășurare încă din vara anului trecut, trecând de atunci peste câteva hopuri, după ce Yahoo a dezvăluit că a fost de două ori victima a celui mai mare incident de hacking din istoria internetului, fiind periclitate inițial o jumătate de miliard de conturi, iar apoi un miliard întreg. Totuși, în ciuda revoltării generale la adresa modului în care Yahoo a tratat incidentul, achiziția nu a fost afectată, iar Verizon a plătit suma de 4.8 miliarde de dolari pentru ceea ce a fost odată cea mai valoroasă companie de internet din lume. După această achiziție, toate funcțiile principale ale Yahoo vor trece sub tutela Verizon, urmând ca investițiile companiei în Alibaba și alte companii din Asia să fie consolidate sub numele Altaba. Aceasta componentă va rămâne independentă și în efect reprezintă tot ce mai rămâne din Yahoo care să nu fie o proprietate a Verizon. Conducerea curentă a Yahoo și-a luat tălpășița, Marissa Mayer nu mai este CEO, co-fondatorul companiei David Filo nu se mai află acolo, iar o mare parte din toți ceilalți care au ghidat compania spre situația sa precară vor căuta acum alte locuri de muncă. Serviciile Yahoo vor rămâne în funcțiune, dacă încă le mai folosește cineva. [Ars Technica] Sursa: https://zonait.tv/yahoo-nu-mai-exista/

Asta merge? https://ubee.deadcode.me/ https://upc.michalspacek.cz/ http://haxx.in/upc-wifi/

KickThemOut KickThemOut - Kick Devices Off Your Network A tool to kick devices out of your network and enjoy all the bandwidth for yourself. It allows you to select specific or all devices and ARP spoofs them off your local area network. Compatible with Python 2.6 & 2.7. Authors: Nikolaos Kamarinakis & David Schütz Installation You can download KickThemOut by cloning the Git Repo and simply installing its requirements: $ git clone https://github.com/k4m4/kickthemout.git $ cd kickthemout $ pip install -r requirements.txt Demo Here's a short demo: (For more demos click here) Disclaimer KickThemOut is provided as is under the MIT Licence (as stated below). It is built for educational purposes only. If you choose to use it otherwise, the developers will not be held responsible. In brief, do not use it with evil intent. License Copyright (c) 2017 by Nikolaos Kamarinakis & David Schütz. Some rights reserved. KickThemOut is under the terms of the MIT License, following all clarifications stated in the license file. For more information head over to the official project page. You can also go ahead and email me anytime at nikolaskam{at}gmail{dot}com or David at xdavid{at}protonmail{dot}com. Link: https://github.com/k4m4/kickthemout

Hacker publishes GitHub secret key hunter TruffleHog snuffles through your dirty commit drawers,. 9 Jan 2017 at 06:56, Team Register A researcher has published a tool to help administrators delve into GitHub commits to find high-entropy secret keys. The tool, dubbed TruffleHog, is able to locate high-entropy keys with Github potentially saving admins from exposing their networks and sensitive data. TruffleHog developer Dylan Ayrey, who warned of the Pastejack attack last year, says the tool will locate any high entropy string longer than 20 characters. "[TruffleHog] searches through git repositories for high entropy strings, digging deep into commit history and branches," Ayrey says. "This is effective at finding secrets accidentally committed that contain high entropy. "If at any point a high entropy string >20 characters is detected, it will print to the screen." TruffleHog in action. He says it searches the entire commit history of branches, checking each diff in commits, and evaluating the Shannon entropy for both the base64 character set and the hexadecimal character set for every blob of text larger than 20 characters and comprised of those character sets in each diff. Reddit users praising the tool have claimed Amazon already searches GitHub for AWS keys and shutters the respective service when any are found. TruffleHog relies only on GitPython. ® Sursa: http://www.theregister.co.uk/2017/01/09/hacker_publishes_github_secret_key_hunter/

pev pev is a full-featured, open source, multiplatform command line toolkit to work with PE (Portable Executables) binaries. This is the current source for a likely unreleased version. Use at your own risk. For more information and stable releases, please refer to http://pev.sourceforge.net/ How to get the source code? git clone --recursive https://github.com/merces/pev.git How to build on Linux? cd pev make NOTE: You may need to install OpenSSL using your package manager. Examples: apt-get install libssl-dev yum install openssl-devel How to build on OS X? cd pev CFLAGS="-I/usr/local/opt/openssl/include/" LDFLAGS="-L/usr/local/opt/openssl/lib/" make NOTE: You may need to install OpenSSL via Homebrew: brew update brew install openssl brew link --force openssl How to build on Windows (via Cygwin)? cd pev make make zip NOTE: The following packages must be installed along with your Cygwin: - gcc-core - binutils - make - zip - openssl-devel - git (just to clone de repository and make things easier) Please check the online documentation for more details. Link: https://github.com/merces/pev

Jonathan Zdziarski ‏@JZdziarski 1h1 hour ago In honor of the iPhone’s 10th Anniversary, here are the original jailbreak instructions for iOS 1.0 Opening the iPhone NerveGas has the spirit. It exploits Apple's 'generosity' in leaving things inside the (only) perimeter 'wide open'.NerveGas on #iphone figured out a clever way of enabling SSH on the iPhone. First he overwrites the update binary with chmod. Then he tricks the iPhone into calling update so he can reset the mode of the Dropbear server to make it eXecutable. Then he puts everything back where it was. Mission accomplished! Working SSH Instructions by NerveGas Previous instructions on the net have required the use of restore mode to set binary permissions. Unfortunately, restore mode doesn't work with all public versions of iPhoneInterface I've tried. The instructions below work by overwriting an existing binary on the system with chmod, and then calling it with the appropriate arguments to set permissions. The result is a fully functional SSH setup. You can then proceed to uploading your own world builds, or other programs to execute via commandline. Step 1: Key creation. On your Mac or PC download Dropbear from here: http://matt.ucc.asn.au/dropbear/dropbear.html Run: ./configure && make You don't need to install the software, just run: ./dropbearkey -t rsa -f dropbear_rsa_host_key ./dropbearkey -t dss -f dropbear_dss_host_key And copy the two new key files into your iPhoneInterface directory. Step 2: Uploading Dropbear and friends. Download the iphone-ssh kit and the iphone binaries kit: http://www.abigato.com/iphone-ssh-kit-vr1.tar.bz2 http://netkas.freeflux.net/blog/ Rename sh6 from the kit to sh. Use the jailbreak application to break out of jail and then open iPhoneInterface to connect. mkdir /etc/dropbear cd /etc/dropbear putfile dropbear_rsa_host_key putfile dropbear_dss_host_key cd /bin putfile chmod putfile sh cd /usr/bin putfile dropbear Step 3: Overwriting 'update' with 'chmod'. While still connected to iPhoneInterface make a backup copy of /usr/sbin/update: cd /usr/sbin getfile update Rename this to update.original on your local filesystem Now copy the 'chmod' binary to 'update' and upload it back to the iPhone: cd /usr/sbin putfile update Step 4: Overwriting the update configuration. Now the 'update' binary is really 'chmod' and has execute permissions! We just need to tell the iPhone to chmod next time it boots. To do this, we download /System/Library/LaunchDaemons/com.apple.update.plist and add our own arguments to ProgramArguments: 0 /usr/sbin/update 1 555 2 /bin/chmod 3 /bin/sh 4 /usr/bin/dropbear Save the new plist and upload it back to the iPhone: cd /System/Library/LaunchDaemons putfile com.apple.update.plist While we're here, lets also: putfile au.asn.ucc.matt.dropbear.plist Step 5: Reboot the iPhone twice. The first reboot should set the permissions on the dropbear and related binaries. The second reboot should start dropbear, so you can ssh to it: ssh -l root [IP ADDRESS] The root password is 'dottie'. Step 6: Replace the original update and com.apple.update.plist files. Don't forget to put the old update files back. Rename update.original back to update, and delete the extra ProgramArguments you added to com.apple.update.plist. Now put them back: cd /System/Library/LaunchDaemons putfile com.apple.update.plist cd /usr/sbin putfile update Step 7: Change the root password. If you don't like 'dottie', you can generate a new encrypted password by running: perl -e 'print crypt("MYPASSWORD", "XU");' Where MYPASSWORD is the new password you want, and XU is a random two-letter salt. Copy the encrypted output and replace the existing one in /etc/master.passwd on the phone. You're done! Enjoy! -NerveGas Sursa: http://rixstep.com/2/2/20070805,00.shtml

Cracking 12 Character & Above Passwords Combo & Hybrid Password Attacks January 8, 2017 · Hash Crack,Password Cracking,Cyber Security Cracking The 12+ Character Password Barrier, Literally 12 Characters? Are you serious?! What do I mean by cracking 12 characters passwords and above? I'm simply stating that with modern hardware, like the "budget" cracking rig, we can almost exhaustively search the highest probability keyspace for candidate passwords, against fast hashes like MD5, NTLM, SHA1, etc..., in a reasonable amount of time. Normally anything above 8 characters isn’t practical and/or feasible to brute force against standard fast hashing algorithms. When factoring in language and human peculiarities, like the average English word is only 4.79 characters long and people preferring multiple common words when creating 10 characters or longer passwords, you are within cracking distance of these passwords. For a quick reference guide to the various cracking tools and their usage check out Hash Crack on Amazon. Why are 12+ character passwords vulnerable? Practically speaking, people that manually create passwords above 10 characters, for the most part, use common words or phrases. Why do they do this? Because remembering the password "horsebattery123" is way easier than "GFj27ef8%k$39". It's just simple human behavior exhibiting path of least resistance that will always exist and, until auto-generating password managers gain mass adoption, this vulnerability will always be around. I agree that XKCD's password strength cartoon of four random words is sound but only for non-fast hashing algorithms like bcrypt. In this article we will demonstrate Combo and Hybrid Attacks using Hashcat that will expand your cracking knowledge toolkit. These examples will show how an attacker can efficiently attack this larger keyspace, with modern hardware, and make these so called strong passwords succumb to his cracking methodology. Combo & Hybrid Attack Background First a quick background of these attack methods: Combo Attack: all words in two dictionaries are appended to each other. EXAMPLE dictionary1.txt dictionary2.txt pass => password, passpass, passlion word => wordpass, wordword, wordlion lion => lionpass, lionword, lionlion Hybrid Attack: a dictionary attack but with the ability to append/prepend a brute-force mask. EXAMPLE dictionary.txt ?u?l?l pass => passAbc, passBcd, passCde word => wordAbc, wordBcd, wordCde lion => lionAbc, lionBcd, lionCde *password candidate generation order not completely accurate but you get the idea **further explanation can be found at the Hashcat website Combo Attack Let's look at how the Combo attack can help us with passwords that are English words appended to each other, and the best dictionary to get the job accomplished is Google's 10,000 most common words list. This is a list of the 10,000 most common English words in order of frequency, as determined by n-gram frequency analysis of the Google's Trillion Word Corpus. Now lets use an example of two randomly selected english words combined to form a 16 character password like shippingnovember. Here's how we would combo attack this password with Hashcat if it was hashed as an Md5: Example hashcat -a 1 -m 0 hash.txt google-10000.txt google-10000.txt By having Hashcat combine every word in this list to each other the password falls in less than 1 second using modern hardware. Not too shabby and this attack will still work reasonably well against some of the medium to slower hash types as well. Before the critics say, "Well you could just capitalize the words or add a digit or special character and you would be fine to form a new password like ShippingNovember. Well let us test that theory real quick. Let's combine that google-10000 dictionary into one single dictionary using Hashcat utils "combinator.bin". This allows us to manipulate the combined words with rules. Example combinator.bin google-10000.txt google-10000.txt > google-10000-combined.txt Now that we have our newly combined dictionary we can just run a rules based attack against the new modified password ShippingNovember using Hashcat like below: Example hashcat -a 0 -m 0 hash.txt google-10000-combined.txt -r best64.rule This one falls in 28 seconds, so much for that theory. And we could create rules to account for added special characters, non-traditional placement, 133t speek, etc... you get the point. 3 Words Now using the combined dictionary we just created let's go after a three word random phrase password like "securityobjectivesbulletin"...looks pretty strong right? But since we just created the new "google-10000-combined.txt" dictionary we can use the combo attack again like the following with double-words in the first dictionary and single words in the second dictionary: Example hashcat -a 1 -m 0 hash.txt google-10000-combined.txt google-10000.txt This one could have been a little more difficult if some character variation was added but as you can see the straight random english words fall in 2 seconds. Are you seeing a trend here yet? 4 Words Let's go big and attack the XKCD password instructions of four random english words to create a new password "sourceinterfacesgatheredartists". This addition of one more word just drastically increased our keyspace to 10,000,000,000,000,000 candidates, but just like the previous attacks it will fall, mostly because of us using MD5 as the hashing function. Again we will use our newly created "combined" dictionary twice and tell Hashcat to perform a combo attack: Example hashcat -a 1 -m 0 hash.txt google-10000-combined.txt google-10000-combined.txt This cracking attempt could have taken 4 days to complete, using modern hardware, but luckily we found the candidate just 5hrs 35mins into the cracking session. Simple modifications to this password like numbers or special characters in the middle would have made this password beyond our reach but again random common words is no match. Hybrid Attack Hybrid Attacks take a little more creativity to find interesting attack plans but it's so much fun when you find that perfect pattern. It's like gold mining for passwords, when you hit that rich vein of patterns and the passwords begin to scroll by in real-time in your terminal, you could almost levitate out of your seat. Google-10000 + Mask For the first example we will use our previous work from the Combo Attack demonstration and incorporate the google-10000.txt list to form the base words of our candidate generation. Then we are going to break out PACK (Password Analysis and Cracking Kit) and focus on the hashesorg251015.txt dictionary from weakpass.com. I picked the hashesorg dictionary because of its efficiency rating of 65.9 and its relatively small size. What we will do is analyze the hashesorg dataset and create masks based on the most popular password patterns constrained to a certain character length. These masks will be appended/prepended to our base words from google-10000.txt to form an efficient Hybrid Attack. PACK Example Generate initial mask statistics studying passwords of length 5-6 characters and output to a masks file. (Be aware this may take some time to generate) python statsgen.py hashesorg251015.txt --minlength=5 --maxlength=6 --hiderare -o hashesorg_5or6.masks Now let's output the masks into Hashcat format into a .hcmasks files so we can use them seamlessly within a Hashcat Hybrid Attack; PACK Example python maskgen.py hashesorg_5or6.masks --optindex -o hashesorg_5or6.hcmask We can now begin the Hybrid Attack using attack mode 6 in Hashcat to append the newly created hashesorg masks file. This will launch a sequential attack beginning with the first mask and working its way down the list. Some attacks will go very quickly and others could take a little more time. For testing purposes we will use a random password 'environmentsqaz472" we know will hit eventually during the attack. Example hashcat -a 6 -m 0 hash.txt google-1000.txt hashesorg_5or6.hcmask This attack took nearly 20 minutes before it eventually cracked reaching the mask ?l?l?l?d?d?d and then it hit with 14 seconds of starting that attack. Rockyou + Rockyou-1-60.hcmask Now let's use Hashcat's built-in mask derived from the Rockyou password dataset. The rockyou masks in Hashcat have been broken into smaller chunks that grow in size based on the numbering, which what I assume accounts for the percentage of passwords that fall within that category of masks. We are going to use the smallest .hcmask file rockyou-1-60 because it contains the higher probability masks and it works well with a Hybrid attack. We are also going to pair this with the actual Rockyou passwords which can be retrieved <HERE> at Skullsecurity. Be carefully when pairing with a dictionary to ensure the dictionary is not too large, otherwise your attacks will take a VERY long time. I like to keep my Hybrid dictionary size below 500MB and even smaller based on the masks I plan to append/prepend. Let's draw at random from the Rockyou dictionary the password "sophia**!" and we will add an arbitrary date just like a user would to the front of "1996". This leaves us with the password 1996sophia**! to test against. Again this attack is going to run through the lists of mask sequentially contained in the rockyou-1-60 dataset and append to them to every password contained in the Rockyou dictionary. Example hashcat -a 7 -m 0 hash.txt rockyou-1-60.hcmask rockyou.txt This attack hits on a mask of ?d?d?d?d after only a few minutes. Again this is for demonstration purposes but shows the process and power of generating Hybrid Attacks. The rockyou-1-60.hcmask contains 836 different masks representing the top occurrences in the rockyou.txt dictionary, and if that variation isn't enough for you Hashcat includes ALL the masks for the rockyou dataset. Cut First 5 Chars + Mask Let's get creative and create our own dictionary and masks to pair with a Hybrid Attack and since we learned that the average English word is 4.79 characters long we will make our dictionary contain words only up to 5 characters long. We will again use the rockyou.txt dictionary for this example. Here is an how we can chop the first 5 characters from the dictionary and sort it uniquely into our new first5_dict.txt dictionary. Depending on your hardware this may take some time to complete. You will also notice this new dictionary comes out to 18MB's in size which is a little on the small side for an attack against MD5 but would be perfect for a slower hash. Example cut -c 1-5 rockyou.txt | sort -u > first5_dict.txt Let's pair this new first5_dict.txt dictionary again with the rockyou-1-60 masks built into Hashcat. Now I know some candidates generated will be below 12 characters but you can always sort out the masks that are below 7 chars and create a new .hcmask file. Now again let's create a random password from the list we will chose Alty5 from the first5_dict.txt and random digits 9402847 to combine them into Alty59402847 Example hashcat -a 6 -m 0 hash.txt first5_dict.txt rockyou-1-60.hcmask This attack is especially effective against users who love using the same base words or digits for their passwords but append or prepend "randomness" to the passwords based on the account. This password falls within a total of 30mins. Straight Mask Attack 12 Chars + I know this isn't a Hybrid attack but it's worth mentioning that 12 character mask attacks are still reasonable, especially if you formulate them using the PACK tool. A 1 day attack (86400 seconds) can be formulated using the speed of your rig against a certain hash type, which can be measured by performing a hashcat -b -m #type from the terminal. Let's quickly show how to follow these steps to create a mask attack for passwords from 12 - 15 characters in length using PACK. Let's again use the rockyou.txt dictionary as an example to generate these masks, but let's first estimate the speed of our cracking rig against md5 hashes. Example (md5) hashcat -b -m 0 Now that we know our rigs cracking speed is 76 billion (76,000,000,000 c/s) let's create the new masks using PACK from the rockyou.txt dictionary. Example python statsgen.py rockyou.txt -o rockyou.masks We can now create our Hashcat hcmask file tailored to a 1 day (86400 seconds) cracking speed attack which covers character lengths of 12-15. Example pythong maskgen.py rockyou,masks --optindex --minlength=12 --maxlength=15 --targettime=86400 --pps=76000000000 -o rockyou_12-15.hcmask Now we can run a series of masks attacks using rockyou_12-15.hcmask against md5 hashes we know will complete within 1 days time. Pretty awesome right?! Example hashcat -a 3 -m 0 hash.txt rockyou_12-15.hcmask Conclusion So as you can see 12 character passwords are not that inconceivable to crack. It just takes a little finessing and a little creativity to formulate the correct strategy. Also don't always assume that since your password is above 11 characters that the online service you trusted with this password is going to hash it properly, thanks $4.8billion company Yahoo. I hope I've demonstrated that you need unique words, digits and not just four random common words all lowercased, and if you need more convincing check out my friend Troy Hunt's write-up <HERE>. If you are really smart you will begin using a password manager like 1Password or Keepass to generate and database your passwords across devices. I'd like to plug Dumpmon's twitter feed as a good place to find hashes to practice on for research purposes. You can follow me on Twitter @netmux, and lastly for a good pocket reference guide on cracking tool usage and syntax check out Hash Crack. "The cyber general who wins the battle makes many calculations in the terminal before hacking begins." - Cyber Sun Tzu Sursa: http://www.netmux.com/blog/cracking-12-character-above-passwords

myBFF is a web application brute force framework (currently) Point the framework at a file containing usernames, a host, and give it a password. The framework will determine what type of web application is in use, then attempt to brute force accounts. After brute forcing accounts, myBFF will then do a little more, like enumerating apps available, and reading in important data. Each module is different so try them out! Current modules: HP SiteScope (will attempt to give you a Meterpreter Shell!) Citrix Gateway (also enumerates authorized applications) Juniper Portal (Will look for 2FA bypass and list what is accessible) MobileIron (Unknown. Have to find out what is accessible first!) Outlook/Office365 (will parse email, contacts, and other data from email) Wordpress (Will be adding "SomethingCool" soon) CiscoVPN (Enumerate User accounts (May not work on all configurations)) Okta (Enumerate Applications and check if 2FA is setup for account) Jenkins (Will be adding "Something Cool" soon) SMB (Check if user is an administrator) (must use --domain with this module. for host, use smb://) FTP (List root dir contents) New modules will be added. CONFIGURATION myBFF requires lxml and pysmb. Install using 'sudo apt-get install python-lxml' 'sudo pip install pysmb' Link: https://github.com/MooseDojo/myBFF

Web Application Penetration Testing Local File Inclusion (LFI) Testing Techniques Jan 04, 2017, Version 1.0 ©2017 – Aptive Consulting Ltd This document and the templates used in its production are the property of Aptive Consulting Ltd and cannot be copied (both in full or in part) without the permission of Aptive Consulting Ltd. While precautions have been taken in the preparation of this document, Aptive Consulting Ltd the publisher, and the author(s) assume no responsibility for errors, omissions, or for damages resulting from the use of the information contained herein. The information herein is provided for educational and informative purposes only, Aptive Consulting Ltd the publisher and author(s) take no responsibility or liability for the actions of others. 2 | A p t i v e phone: +44 (0)3333 440 831 | email: contact@aptive.co.uk | web: https://www.aptive.co.uk Introduction The intent of this document is to help penetration testers and students identify and test LFI vulnerabilities on future penetration testing engagements by consolidating research for local file inclusion LFI penetration testing techniques. LFI vulnerabilities are typically discovered during web app penetration testing using the techniques contained within this document. Additionally, some of the techniques mentioned in this paper are also commonly used in CTF style competitions. Download: https://www.exploit-db.com/docs/40992.pdf

Identifying WordPress Websites On Local Networks (behind Firewalls) and Bruteforcing the Login Pages Last Updated: Thu, 05 Jan 2017 - by Sven Morgenroth Statistics from w3techs suggest that 1 out of 4 websites (around 25%) on the internet are powered by WordPress. WordPress’ popularity is derived from its ease of setup and use, its contributing community, and the big repertoire of plugins and themes that are available. Why is WordPress Such a Common Target? Even though WordPress is a beginner friendly web application, like every other platform it has its own issues and limitations. One of the most voiced security issues is that it is possible and very easy to bruteforce login credentials. WordPress’ advice on this is to install a security plugin, protect the WordPress login page with a .htpasswd file (HTTP authentication), and of course use strong credentials. However many users, especially the unexperienced ones do not take these extra security measures onboard. They use very weak credentials and do not setup any additional layers of security on their websites, thus making WordPress a good target for brute force attacks. How to Bruteforce WordPress Websites and Blogs Running on an Internal Networks and Behind Firewalls WordPress blogs aren’t always used for publicly accessible websites. They are also frequently used as websites in intranets for employees. Typically Intranets are not reachable from the outside (the internet) because they are sitting behind a firewall. Though WordPress websites running in intranets are still at risk; attackers can effectively brute force a WordPress blog or website in an internal network via XSHM, without having direct access to it. What is XSHM? XSHM is an abbreviation for Cross Site History Manipulation. It is a security breach in the Same Origin Policy, which is used by web browsers to prevent different websites from retrieving information from each other when a user is accessing them both. This means that website A can not read the content of website B when both are accessed at the same time in different browser tabs. However, there are some side channel attacks that can be used to leak certain information even though the same origin policy is in place. XSHM is one of them and below is an example: An attacker creates an iframe on a website he controls (website A) and points it to a page on website B that has a conditional redirect. For example the iframe points to login.php, which when accessed redirects the user to index.php if he is logged in. The attacker retrieves the history.length value of the browser tab. The attacker updates the iframe to point to index.php. When the user accesses the iframe again, the attacker retrieves the new value of the history.length property again and compares it to the one in step 2. Since the web browser does not increase the history.length value if the URL the iframe is the same as the URL the user is currently browsing, then it is easy to determine if the user is logged into WordPress or not. Therefore if the history.length value remains the same, it means that the user was redirected to index.php, which means he is logged in. How to Identify WordPress Websites on a Local Network WordPress has a unique redirect, that makes it really easy for attackers to spot. If a user is not logged in and visits the page /wordpress/wp-admin/, he is redirected to: /wp-login.php?redirect_to=http%3A%2F%2Fexample.com%2Fwordpress%2Fwp-admin%2F&reauth=1 Using XSHM Therefore to find WordPress websites on an internal network an attacker can send the victim a link with a XSHM payload, that tries the above redirect on a range of internal IP addresses such as 192.168.1.1/24 when a user clicks the link. Using JavaScript The attacker can also use JavaScript to scan internal networks for websites running on WordPress. For example by using WebRTC, like implemented in the BeEF framework he can narrow down the list of live hosts which has to be checked for the above WordPress’ redirect. Once the scanning is done the attacker should have a list of internal IPs running WordPress. You can download a PoC of the JavaScript. How does bruteforcing WordPress logins work with XSHM? Now that the attacker identified the WordPress websites he can start the brute force attacks with XSHM, even though he does not have direct access to it. This is possible due to the fact that WordPress does not have a token to prevent logins via CSRF. There is a general misunderstanding of whether or not CSRF Tokens are necessary in login forms. Note: Tokens in login pages are necessary. It is generally advised to secure your WordPress login page with Tokens to prevent these type of attacks. There are several other attack vectors that use the login CSRF as entry points, which are not obvious but can have serious impacts, such as logging the user in an attacker’s account without his knowledge and steal private information. It might also be possible to abuse an otherwise not reachable Stored Cross-site Scripting (XSS) vulnerability. WordPress also provides a redirect_to form field in its login, which lets the attacker specify where he wants the victim to be redirected after a successful login. This suits perfectly the attacker’s XSHM attack. He can now use a website which makes a CSRF attack based on GET parameters and supply different username / password combinations. The attack works as follows: Retrieve the value of the history.length property of the victim’s browser tab. Point the src of the iframe to the page that carries out the CSRF attack. This can be done by using a self-submitting form to the wp-login page with a username / password combination. Point the iframe to the path from the redirect_to parameter Check the value of the victim’s history.length From the value of the history.length property the attacker can now tell whether or not the attack was successful, because the attacker knows that a successful login means that wordpress redirected the user to the page in the redirect_to parameter. Therefore if the value of the history.length property does not increase, he knows that the attack was successful. The attacker is also able to tell if a CSRF attack worked under certain conditions, which usually isn’t possible due to Same Origin Policy. Proof of Concept Video Below is a proof of concept video of how WordPress websites running on internal networks can be identified, even when running behind a firewall, and how then a bruteforce attack is launched against them. Limitations and Problems of the WordPress Login Page Attack via XSHM The Attack is Easily Noticed In order for this WordPress attack to succeed the attacker needs at least two interactions from the victim: First he must convince the victim to visit his malicious web page. After that the victim must click a button or link on the attacker’s page that opens a new browser window or tab. This is required since it is not possible to open a new window or tab without user interaction, because of popup blockers. Since the victim can easily notice the new opened tab and the page refreshes the chances of the victim not noticing the attack are very slim. Also, the attacker can’t just create a simple iframe as the wp-login page is secured with X-Frame-Options. This might cause problems in some web browsers since they might not increase the history.length value if this header is set, thus could be very difficult for an attacker to determine if there is a WordPress or not. Different Browsers' Behaviour Complicates Matters Another problem is that some browsers such as Chrome always change the value of the history.length property, even if the attacker redirects the iframe to its current src. This might be a counter measure for the XSHM attack, and in fact the attack will fail. So how can the attacker change the history.length without an iframe on the current page? Using Window.Opener in the XSHM Attack The answer is window.opener. If a new browser window or tab is opened from another tab, either by clicking a link or with javascript, the new page can access its parent’s window object. It is even possible to get the value of the history.length property if the page is from the same origin. At first this does not seem very useful, since the attacker needs to know the value of history.length property after redirecting to a cross origin page to carry out the XSHM attack. But since the attacker can set the location of the parent window, even via cross-domain he can do the following: Open a child window from his page, for example attacker.com/opener.html -> attacker.com/child.html In the child window the attacker uses the opener.history.length to retrieve the history length from attacker.com/opener.html Set the location of the opened window to http://192.168.1.123/wordpress/wp-admin/ using opener.location Set window.opener.location to http://192.168.1.123/wordpress/wp-login.php?redirect_to=http%3A%2F%2F192.168.1.123%2Fwordpress%2Fwp-admin%2F&reauth=1 Set opener.location back to attacker.com/opener.html to be on the same origin again. Now the attacker should be able to get the value of opener.history.length again and compare it to the one from step 2. This way the attacker can also bypass the X-Frame-Options protection against XSHM. This could also be stealthily done by using a popunder window. The Maximum Value of the history.length Property Another problem that might hinder these type of attacks is the maximum value of the history.length property. For example on Chrome its highest value can be 50. If the value needs to be increased and it is already at 50, the first (oldest) entry is removed and the last entry is added. This can be a problem when doing a Cross Site History Manipulation attack, but as a workaround the attacker can: Trick the victim into visiting a url from the same origin with window.opener.location. Then trick the victim again to navigate back to the first page he visited in the current session with window.opener.history.go(- (window.opener.history.length-1)). This first retrieves the amount of pages the user can go back and then goes back to the first page. Set the URL to a new link. The history value is 2 now. This way the attacker bypasses the problem of the 50 entries limit. Dealing with Logout CSRF Protection Another hurdle for the XSHM attack is the logout CSRF protection. If the user is logged in the attacker usually can’t reliably check whether or not there is an actual WordPress installation on the server, so he can’t brute force the login page with a user that is already logged in. Well WordPress is a little special in this case. When the victim visits wp-login.php he is greeted with a login prompt whether or not he is logged in. This would solve the problem the attacker would have with bruteforcing credentials, however it is still not possible to reliably check with wp-login / wp-admin if there is a WordPress installation on the web server. But WordPress has an additional parameter you can set to actually log you out when you visit wp-login. It is called reauth. When it is set to 1 you are automatically logged out, which means the attacker can try to point the victim to wp-admin and see if it redirects him to wp-login again. How can You mitigate against the XSHM Attack? As a WordPress user you can’t take any precautions to prevent XSHM attacks, since this is a browser feature you can’t control. You can only rely on the developers of the respective website to take all the necessary precautions that prevent XSHM attacks. These include: Avoiding conditional redirects that can leak sensitive information. Using of CSRF Tokens. It can also be a good idea to add random characters to the URL. These don’t have to be connected to any application level logic, like CSRF tokens do, but can make it difficult for an attacker to guess the exact link where the victim will be redirected to. Note: While there is a proof of concept for this WordPress attack it is unlikely to be used in a real life scenario because of the knowledge that is required about the target and because of the long time the victim has to spend on the attacker’s page, while having a refreshing window in plain sight. Sursa: https://www.netsparker.com/blog/web-security/bruteforce-wordpress-local-networks-xshm-attack/

SNIFFING GSM TRAFFIC WITH HACKRF. While my friend and colleague Simone was visiting our ZIMPERIUM – Enterprise Mobile Security TLV office, we got our hands on HackRF and hacked together the unguarded boarders of Radio Frequencies. Simone had the great patience to try and explain me the boring world of complex numbers and friends (more on that here), but my dyslexia won over again and left me to fill the gap by following Simone’s steps (and some mistakes, eh Simone?) and use my ‘trial & error’ approach until success. This tutorial is the result of our collaborate GSM hacking session, presented with the hope it will be useful for others. TOOLS USED: hackrf_kalibrate gnuradio-companion gr-gsm gqrx wireshark INSTALL REQUIREMENTS: First thing, you want to make sure you have all the required software installed, you can install most of them and their dependencies using your distribution package manager. Let’s start with the libraries and tools for the hackrf itself, on a Debian/Ubuntu distro you’ll install them like so: 1 sudo apt-get install hackrf libhackrf-dev libhackrf0 Once these libraries are installed, you can plug your hackrf into one of your USB ports and execute the hackrf_info command, at this point you should see something like the following: 1 2 3 4 5 6 7 # hackrf_info Found HackRF board. Board ID Number: 2 (HackRF One) Firmware Version: 2014.08.1 Part ID Number: 0x00574746 0x00574746 Serial Number: 0x00000000 0x00000000 0x14d463dc 0x2f4339e1 You will now install gnuradio which is the software we’ll use to decode the RF signals, gqrx a tool to visualize signal power on certain frequencies and everything else that will be needed in the next steps: 1 sudo apt-get install gnuradio gnuradio-dev gr-osmosdr gr-osmosdr gqrx-sdr wireshark Proceed with gr-gsm, the GnuRadio blocks that will decode GSM packets: 1 2 3 4 5 6 7 8 9 sudo apt-get install git cmake libboost-all-dev libcppunit-dev swig doxygen liblog4cpp5-dev python-scipy git clone https://github.com/ptrkrysik/gr-gsm.git cd gr-gsm mkdir build cd build cmake .. make sudo make install sudo ldconfig Now create the file ~/.gnuradio/config.conf and paste the following contents into it: 1 2 [grc] local_blocks_path=/usr/local/share/gnuradio/grc/blocks Finally install kalibrate-hackrf, a tool that will hop among known GSM frequencies and will tell you which your country is using: 1 2 3 4 5 6 git clone https://github.com/scateu/kalibrate-hackrf.git cd kalibrate-hackrf ./bootstrap ./configure make sudo make install FINDING GSM FREQUENCIES: Each operator in each country uses a different frequency in the GSM possible spectrum, which usually starts from 900Mhz. You can use hackrf_kalibrate to find the frequencies you want to sniff: 1 ./kal -s GSM900 -g 40 -l 40 Note the two gain values, those are important in order to get some results. Leave kalibrate running and after a while you should see an output similar to this: You will have to use the proper GSM parameter (‘-s’) to correspond to your local operator. Consult this list for verification. Sometimes you might want to see the frequencies in order to ensure correct results from hackrf_kalibrate, or to save yourself from calculating the correct frequency given by hackrf_kalibrate (notice the +/- Khz sign of each result – this means the top peak with the corresponding power,not 100% correct frequency). Open gqrx and tune it to the first frequency you got from hackrf_kalibrate, for example 940.6Mhz, and you’ll see something like the following picture: In the above screenshot you can visually see the activity is around 945Mhz. Once you know the GSM channels frequencies, you can start gr-gsm by running the python script ./airprobe_rtlsdr.py or load the airprobe_rtlsdr.grc file using gnuradio-companion and set one of the channel frequencies you just found in the frequency field. Don’t forget to add ‘gain’ value again, move back to the frequency field and start pressing the UP/DOWN arrows on your keyboard to start scrolling the frequencies in 200Khz steps until you start seeing some data in your console window. The whole process should look something like this: Now you only need to launch wireshark from another terminal tab with the following command: 1 sudo wireshark -k -Y 'gsmtap && !icmp' -i lo If gr-gsm did his job, you should be able to see decoded GSM traffic sniffed by your hackrf. WRITTEN BY Z4ZIGGYMAY 17, 2015 Sursa: https://z4ziggy.wordpress.com/2015/05/17/sniffing-gsm-traffic-with-hackrf/

Nokia 6 este primul smartphone sub acest brand echipat cu sistem de operare Android Cătălin Niţu - 9 ian 2017 HMD Global, compania finlandeză care controlează brandul Nokia în prezent, a anunţat în sfârşit mult aşteptatul smartphone Nokia 6, primul dispozitiv al companiei bazat pe sistemul de operare Android. Acesta vine cu hardware nu tocmai puternic pentru întoarcerea unui brand atât de mare pe piaţă, însă va avea un preţ accesibil. Probabil că majoritatea celor interesaţi de noile telefoane Nokia cu Android vor fi însă dezamăgiţi de faptul că va fi lansat exclusiv pentru piaţa din China. zoom in Nokia 6 este un smartphone care ar putea fi încadrat în gama mid-range premium, fiind echipat cu hardware de medie, învelit în materiale de calitate precum sticlă şi aluminiu. Vorbim despre un dispozitiv cu display de 5,5” şi rezoluţie Full HD, chipset Snapdragon 430, 4 GB memorie RAM, 64 GB spaţiu de stocare şi camere foto de 16, respectiv 8 megapixeli. Acest hardware a devenit deja standard chiar şi pe dispozitive mid-range, însă procesorul pare să fie dintr-o gamă mai ieftină, cu performanţă limitată. Sistemul de operare pre-instalat va fi noul Android Nougat, însă nu cât de diferită este interfaţa proprietară faţă de cea standard de la Google. Lansarea este programată pentru „începutul anului 2017”, la un preţ de 1699 yuan, adică aproximativ 250 de dolari americani. Problema este că în China există deja multe brand-uri locale care oferă dispozitive mult mai puternice cu o construcţie similară la preţuri similare. Via: http://www.go4it.ro/telefoane-mobile/nokia-6-este-primul-smartphone-sub-acest-brand-echipat-cu-sistem-de-operare-android-video-16053801/

Sunday, January 8, 2017 How to crack WLAN - WPA/WPA2 pre shared keys To crack WPA/WPA2 pre shared keys may not so difficult as many people think. When an client authenticates at the router, there is a 4-way handshake between router and client, to handshake a session key, which must be recorded with a simple WLAN sniffer. The messages are called EAPOL. Here I described how to setup a simple sniffer with a raspberry pi-2 http://blog.x1622.com/2016/12/how-to-setup-rasperry-pi-2-model-b-for.html So, the only task to do is to record all the traffic until one of the 4-way handshake gets recorded. In WIRESHARK there exists a display filter called "eapol". In my test case, I opened a WLAN called darkqueen with a simple numeric password 19042001 I authenticated with a mobile device and captured the handshake. In my example I did it more than one time but capturing a complete handshake (1-4) is enough. I stopped capturing and stored all data in a standard wireshark pcap format. You can store all data or mark the EAPOL lines. The standard PCAP file cannot be used direct with HASHCAT. The file has to be converted to hccap format. Here is a description about the different possibilities to do that. https://hashcat.net/wiki/doku.php?id=cracking_wpawpa2 It can be done online, or locally using AIRCRACK suite. I took the hccap file to a single machine with an old GPU (~50 Dollar) I got from sons old gaming PC. I started HASHCAT and for eight digits (WPA passwords minimum length is eight) and HASCAT calculated a maximum time of 50 minutes. After few Minutes HASHCAT cracked the password of darkqueen => 1904001 In this POC ist was simple because I used a weak WPA2 key. If it's more complex it may take much more time. In this case, there is also the possibility to pre calculate a rainbow table if the name of the accesspoint is known. Therefor COWPATTY can be used http://tools.kali.org/wireless-attacks/cowpatty Sursa: http://blog.x1622.com/2017/01/how-to-crack-wlan-wpawpa2-pre-shared.html

Exploiting JBoss with Empire and PowerShell When Empire was initially launched by @harmj0y and @sixdub at BSidesLV, I was immediately excited about the possibilities that a pure PowerShell RAT would bring to the offensive community. With what little free time I have, I’ve been working to add a few modules that have been inspired by recent engagements I’ve been on. This post will cover how to enumerate and exploit an internal web service through a deployed Empire agent without port scanning. In this demonstration, I have an empire agent running on a Windows 7 host. The plan is to quietly enumerate the network for vulnerable web services and exploit one to move laterally. First, I load the recon/find_fruit module and set the required options. The find_fruit module accepts CIDR ranges as well as single hosts. The module is also multi-threaded with a default setting of ten threads. One thing that makes this module great for red teaming or quieter penetration testing, is that unlike port-scanning, it uses legitimate web requests to check for web services that we commonly target such as Apache Tomcat, JBoss, Cold Fusion and more. The module will also accept a custom dictionary if desired. Kicking off the module I quickly find some “low hanging fruit” on a host in my target range. Next, I want to create a payload and exploit the JMX-Console. Thanks to a stager by @ch33kyf3ll0w, Empire has the ability to generate java .war files for deploying agents. If you’re doing this outside of Empire, you can also generate a .war file using another @harmj0y script at https://gist.github.com/HarmJ0y/aecabdc30f4c4ef1fad3 Here I host the .war file with the python SimpleHTTPServer module. This is necessary as the jmx-console exploit will reach out to grab this file and deploy it on the target server. Finally, I load the exploitation/exploit_jboss module and set the required options. I start by setting the JMXConsole switch to “true”. Next, The AppName needs to match the AppName I used when generating the .war file. I point the WarFile to my Python hosted file. Since I am tunnelling this exploit through an already deployed agent, I need to set the Agent option to deploy the exploit from. Empire will also let you know if this module is “opsec safe”, meaning it drops a file to disk. Once the exploit is launched, I first see the HTTP request from the target server to grab the hosted .war file. After a few seconds, I am greeted by a new Empire agent! If you’re looking for a way to enumerate and exploit internal web services without the noise of port-scanning, give this a try. The standalone Find-Fruit and Exploit-JBoss PowerShell scripts may be found on my github repository as well. Scripts: https://github.com/rvrsh3ll/Misc-Powershell-Scripts Empire http://www.powershellempire.com/ Sursa: http://www.rvrsh3ll.net/blog/offensive/exploiting-jboss-with-powershell-and-empire/

Exploiting Misconfigured CORS (Cross Origin Resource Sharing) DECEMBER 16, 2016 ADMIN Hey frnds few days before noticed a blog post for exploiting facebook chat and reading all the chats of users so that made me to interested to know about the issues, and basically it was misconfigured CORS configuration where null origin is allowed with credentials true, it was not something heard for the 1st time, @albinowax from the portswigger explained it very well in his blog post, so after reading that messenger blog post i went to test for the same issue for some targets where i allowed to test it. but before that here are some tips about CORS where it can be exploitable from attackers point of view: POORLY IMPLEMENTED, BEST CASE FOR ATTACK: Access-Control-Allow-Origin: https://attacker.com Access-Control-Allow-Credentials: true POORLY IMPLEMENTED, EXPLOITABLE: Access-Control-Allow-Origin: null Access-Control-Allow-Credentials: true BAD IMPLEMENTATION BUT NOT EXPLOITABLE: Access-Control-Allow-Origin: * Access-Control-Allow-Credentials: true or just Access-Control-Allow-Origin: * even this is not good from development point of view but due to own rules of CORS if Access-Control-Allow-Origin set to * we don’t get benefit Access-Control-Allow-Credentials: true means no cookie access of the victim. am not going to more deep about CORS, as earlier blog post covered it very well. so in above i mentioned 3 cases where first two cases is exploitable in that eg of 2nd case is that Facebook Messenger chat issue which i mentioned in earlier section of the post, and eg of 1st case is mine which i found 2 days before only where any arbitrary Origin is allowed and same Origin get reflected back to Access-Control-Allow-Origin with Credentials set to True, the best way i found to check for CORS issue is using CURL. eg : curl https://test.victim.com -H "Origin: https://geekboy.ninja"-I and check the response if Origin is reflected in the response or not. OR if your burp pro user, Burp Active Scan may find this for you, but in mine case it didnt, idk the reason, when i CURLed my target manully curl https://my.target.com -H "Origin: https://geekboy.ninja" -I , the Origin didnt got reflected but when i curled specifc endpoint where all users data getting back into response curl https://my.target.com/api/web/user -H "Origin: https://geekboy.ninja" -I it reflected back with my host with Credentials set to True and that’s enough to make this work and steal all that data. i made quick poc code for it function cors() { var xhttp = new XMLHttpRequest(); xhttp.onreadystatechange = function() { if (this.readyState == 4 && this.status == 200) { document.getElementById("demo").innerHTML = alert(this.responseText); } }; xhttp.open("GET", "https://my.target.com/api/web/user", true); xhttp.withCredentials = true; xhttp.send(); } And here how it worked Sources for better understanding of CORS: http://blog.portswigger.net/2016/10/exploiting-cors-misconfigurations-for.html https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS https://ejj.io/misconfigured-cors/ Sursa: http://www.geekboy.ninja/blog/exploiting-misconfigured-cors-cross-origin-resource-sharing/

A New XSSI Vector (or the untold merits of nosniff)... Posted on December 19, 2016 by Dennis Goodlett Introduction While playing with Cross Site Script Inclusion (XSSI) recently, I realized the attack can be used to leak information, cross-origin, from HTTP status codes. If you're thinking "XSSI Login Oracle" then you're on the right track, but the attack can be expanded to more situations. Login oracles are usually JavaScript files that load or don't load depending on current authentication status. However, this attack can be done on HTML, JSON, XML, or just about any content type. This dramatically opens up the attack surface of XSSI to enumerate information from GET parameters, one bit at a time. I haven't seen this specific attack published anywhere, so I'm going to attempt to make this post as comprehensive as possible. Edit:domnul_anonim on Reddit pointed out that Mike Cardwell published the same basic attack before it was called "XSSI". My blog post presents some new ideas about the attack, but referring to it as “new” is a bit bold and isn't quite appropriate. I've also structured this paper for easy reference. The structure is as follows: Attack Attack Requirements Defense Further study Summary TLDR Attack: Read "A More Interesting Example" in the Attack section below for a walkthrough. TLDR Defense: Use the nosniff HTTP header ("Requirement 1" explained in Defense section below). I won't explain the basics of XSSI because I lack the room. SCIP has a blog post explaining XSSI in great depth. I consider it the best reference and introduction on the subject. I'm presenting an attack on non-script content injection. Stronger attacks on non-script content are explained in the cited blog but the attacks tend to require more specialized circumstances (encoding and injection tricks) than the one I will be demonstrating. 1.) The Attack The basic idea is very similar to a XSSI login oracle. An attacker attempts to load script tags to his page that point at a different origin. By handling the onerror, onload, and window.onerror functions, an attacker can learn information about how the cross-origin server responded to the GET request. I was surprised to learn that onerror executes if you receive a non-2XX response, and onload executes otherwise. This is regardless of the content type returned, unless strict content type is being enforced (see Requirement 1). So what's the big deal? What can you learn from a 200 vs a 400 response? Well, it depends on the endpoint but potentially a lot. After all, the HTTP status code is meant to return information, and often does for API's. SOME BASIC EXAMPLES Imagine an /admin directory that returns a 200 status code and HTML if you're authenticated, and a 401 with an HTML error page if you aren't. This would act not only as a login oracle, but it would also allow the enumeration of privileges. If there was a unique profile page for each user (ie: /profile/dennis) then a similar attack could be used by a malicious site to identify specific users for further attacks and play innocent to response teams. If a page has SQL injection in a GET request but cannot be reached by the attacker, the attacker can cause authenticated users visiting an attacker controlled page to bit bang the injection for the attacker and leak the results cross origin to the attacker's JavaScript. A MORE INTERESTING EXAMPLE Let’s walk through a more interesting example in greater detail. Imagine a ticketing system that has a search field which is used to look up customer information. Sending a GET to "/search?c=d*", where the “*” character is acting as a wildcard, will return all the customers that start with the letter "d" and a 200 status code. If no customers match the “d*” pattern, then a 500 is returned. An attacker wants this information, but can’t login and just look. So instead he asks an already logged in user to make requests in the attacker’s behalf and tell the onload function “yes, I found someone” or tell the onerror function “no, that search returned nothing”. It’s similar to exploiting a blind SQL injection except it’s through a third party and you're abusing Same-Origin Policy instead of syntax. Notice, the content type returned in the body by the ticketing system does not need to be assumed here. The search can return JSON, XML, HTML or even an image, it's all the same to this attack as long as the nosniff header isn't being returned (Requirement 1 in defense). URL parameters can be included in the script src attribute so an attacker can create a script like so: d = document.createElement('script'); d.src = victim_domain + "/search?c=a*"; This will send a GET request to the “/search?c=a*” API on the ticketing system. Now the attacker just sets the onload and onerror events to log success and failure respectively: d.onload = function(){client_exists("a*")}; d.onerror = function(){client_does_not_exist("a*")}; Then append it to the DOM: document.head.appendChild(d); Any visitor to the attacker's site will then automatically send a GET request to the ticketing system, cross-origin. If there's a customer that starts with "a", then the endpoint will return a 200 and the onload will execute. The attacker's onload handler would then load another script into the DOM asking if there are any customers that start with "aa". If the onerror event occurs it's because there were not customers that started with the letter "a", so the attacker would then load another script into the DOM checking for customers who start with the letter "b". The script would continue with a tree searching algorithm until a valid customer name was returned. Once a customer name is discovered, the same type of attack can be used to search other API endpoints that require a customer name and return other information. For example, an endpoint that searches for email addresses associated to a customer. The attacker could also search for customers matching the "*" pattern. If this fails it means the visitor doesn't have access to the ticketing system customer search and no further requests need to be made. Because the information stealing requests are being performed by visitors to the attacker's site, the attack can be parallelized across all visitors. Put all this together with a social engineering email and there is potential for a lot of information leakage from even an internal ticketing systems. This attack is not far fetched and does not require a special circumstances. HTTP status codes are meant to return information. Script tags are meant to detect the onerror and onload. 2.) Attack Requirements To put it simply, the following elements are required: The 'X-Content-Type-Options: nosniff' HTTP header is not being returned, unless the content type is JavaScript. The endpoint must respond to a GET request. The status code of the endpoint varies from a 200 type response to a non-200 type response for success/failure (Note: 300 responses seem to act like whatever status code they point to). The information is not publicly available. The most concerning thing is what is not said here. There is no mention of content type, other than JavaScript in requirement 1. So, this attack works on XML, JSON, images, or any other content (so far as I have seen). (See Note 2 in "Requirement 1" below for details). More details on the requirements follow in the defense section. Pentesters: you should read that section too, because it explains some more tricks in greater depth. 3.) The Defense You just have to disturb one of the above requirements. Let's go through the requirements in greater detail from a defensive perspective. REQUIREMENT 1 If the ‘X-Content-Type-Options: nosniff’ HTTP header is returned, this attack won’t work. This is the simplest to verify and to implement. If you want to fix your site this is probably the way to do it. The nosniff header is a way the server can tell a browser "When I say I am giving you <Content-Type> I mean it is really <Content-Type>!". Why does this work? All types of files are served over HTTP, and web developers aren't always good about declaring the file type properly. So when a browser requests a JavaScript file, the content-type header may declare it's actually HTML. A browser thus puts off producing an error until it tries to parse the file as JavaScript. At that point, onload has already executed and any parsing errors will call the window.onerror function. The existence of the nosniff header means onerror will always be called immediately if the content type isn't stated correctly. Always onerror means no measurable difference and no information loss. If the content type is JavaScript, nosniff doesn't help and you have a normal XSSI attack. Note: This is only true for browsers that respect the nosniff header. IE and Chrome were the first to support this header. Firefox has followed also, I don’t know when support started but I have found Firefox 50 Firefox 51 honors nosniff while Firefox 45.5 does not. I assume Edge will act the same as IE, but I haven't personally tested either of them. Edit: 1lastBr3ath from Reddit pointed out Safari doesn't support the no-sniff header, Edge does. Also he corrected my mistake, it is Firefox 51 not 50 that included support for no-sniff. Note2: On the topic of what content type, 1lastBr3ath from reddit pointed me to this documentation, which is really where I should've pointed to. It states: The script should be served with the text/javascript MIME type, but browsers are lenient and only block them if the script is served with an image type (image/*), a video type (video/*), an audio (audio/*) type, or text/csv. If the script is blocked, an error is sent to the element, if not a successevent is sent. So all content types won't work in script tags. However, typical informational content types, like XML or JSON will. This restriction can potentially be bypassed by just using a different tag (See Further Study: other tags). REQUIREMENT 2 Script tags only work with GET requests. So if your endpoint only accepts POST requests, then this attack can’t be performed. This requirement is seemingly simple, but be careful. You may have designed your API to accept POST requests but your content management system may accept GET requests all the same. REQUIREMENT 3 If the endpoint always returns a 200, then there is no information within the status code to steal. However, status codes exist for a reason! Don’t just go abandoning a core part of the HTTP protocol just to stop this attack. Use the nosniff header instead. Constant HTTP status codes do stop the particular attack described here, but other attacks may still be possible. For example, a top level JSON array can be parsed as JavaScript while a top level JSON object can not. So even though your endpoint always returns 200 status codes, information can be gathered from whether or not there is a parsing error by creating a window.onerror function. Applying the nosniff header will stop even this attack as long as the Content-Type header is appropriately set to JSON. REQUIREMENT 4: If an attacker is in a position to just load up the secret information in his own browser, then there is no need for this attack. This attack revolves around an attacker domain asking a visitor to use their privileged position to get more information. Privileged position will most commonly mean authenticated, but could also mean network position. If your home router has this vulnerability, malicious public sites can request scripts from it and leak information. 4.) Further Study 3XX CODES: I have given little attention to open redirects and 3XX responses, which could expand the attack further. So far it does appear redirecting to a 2XX acts like a 2XX and redirecting to a non-2XX acts like a non-2XX. This means an endpoint protecting itself by checking the referer header might be bypassed if an open redirect is discovered. This is a neat idea too. OTHER TAGS: I believe img tags pointing cross-origin behave similar to script tags. Maybe loading a resource in both img and script tags could lead to more information disclosure due to parsing differences. CSS may also deserve a look. OTHER ATTRIBUTES I was hoping Subresource Integrity would yield further information leaks, but it wisely requires CORS to work. If you can get around CORS then there are bigger problems then this attack. I have spent most of my time testing onload, onerror, and window.onerror to get information. Observing more attributes may yield other attacks or more information per request. 5.) In Summary Any detectable difference in loading a cross origin resource is information. That information may be as minor as a login oracle, but could potentially be as bad as credentials (though unlikely). Defenders: A misunderstanding of content type is a common vector for all sorts of attacks. Enforcing strict content type with the nosniff HTTP header will mitigate this and many more attacks. It also puts you in a failsafe position. A response with improper content will cause an error that will be obvious to anyone and fixed easily. Attackers: Same origin policy is a little understood concept, which makes it a great source of bugs. Look for sensitive information returned in GET requests. Then see if you can detect any difference in behavior when requesting that information cross origin via script tags. This entry was posted in Penetration Testing by Dennis Goodlett Sursa: https://www.hurricanelabs.com/blog/new-xssi-vector-untold-merits-of-nosniff

Mobile Security Framework (MobSF) Version: v0.9.3 beta Mobile Security Framework (MobSF) is an intelligent, all-in-one open source mobile application (Android/iOS/Windows) automated pen-testing framework capable of performing static and dynamic analysis. It can be used for effective and fast security analysis of Android, iOS and Windows mobile Applications and supports both binaries (APK, IPA & APPX ) and zipped source code. MobSF can also perform Web API Security testing with it's API Fuzzer that can do Information Gathering, analyze Security Headers, identify Mobile API specific vulnerabilities like XXE, SSRF, Path Traversal, IDOR, and other logical issues related to Session and API Rate Limiting. Made with in India MobSF is also bundled with Android Tamer and BlackArch Documentation https://github.com/ajinabraham/Mobile-Security-Framework-MobSF/wiki/1.-Documentation Collaborators Ajin Abraham Dominik Schlecht Presentations OWASP APPSEC EU 2016 - Slides | Video NULLCON 2016 - Slides c0c0n 2015 - Slides More info: https://github.com/ajinabraham/Mobile-Security-Framework-MobSF

Google patches severe Android boot mode vulnerability The critical vulnerability left Android devices open to denial of service and privilege escalation attacks. By Charlie Osborne for Zero Day | January 9, 2017 -- Symantec Google has resolved a dangerous Android vulnerability which allowed attackers to reboot Nexus devices into custom boot modes, leading to spying and remote attacks. Patched as part of Google's January Android security bulletin, the flaw, CVE-2016-8467, grants cyberattackers the ability to use PC malware or malicious chargers to reboot a Nexus 6 or 6P device and implement a special boot configuration, or boot mode, which instructs Android to turn on various extra USB interfaces. According to IBM X-Force Application Security Research Team researchers Roee Hay and Michael Goberman, who revealed further details of the vulnerability in a blog post, the flaw gives attackers access to interfaces which offer additional control over a compromised device. In particular, the Nexus 6 the modem diagnostics interface is of concern as accessing this platform gives attackers access to the modem, which compromises "confidentiality and integrity," the team says. Once an attacker has gained access to the modem they can intercept phone calls, for example. It would also be possible to sniff mobile data packets and grab information including GPS coordinates of the device for tracking, place phone calls, steal call information and either access or change nonvolatile (NV) items or the EFS partition of a device. See also: Google patches Dirty Cow vulnerability in latest Android security update IBM says that if Android Debug Bridge (ADB) is enabled on the device, PC malware or a malicious charger can boot the target device with the special boot mode configuration. Once connected, the user is forced to accept the PC or charger permanently, a few commands are issued, and the device is rebooted. "Every future boot from this point forward will have the boot mode configuration enabled," IBM says. This means the attack is persistent and no longer requires ADB to run, although it still requires USB access." "Therefore, the attacker only needs the victim to enable ADB once," the researchers added. "Moreover, a lucky attacker might wait for the device to be in fastboot mode, which requires no authorization from the victim. This, however, is less likely." If attackers have physical access to the device, they can also reboot it into the custom boot mode manually. These issues are less severe on the Nexus 6P due to firmware protections, however, a quirk in the device type means attackers can open ADB sessions even if the mode has been disabled. In addition, due to the inclusion of additional USB interfaces in both device types, attackers can also access other interfaces to send or on SMS messages and potentially bypass two-factor authentication, escalate privileges, change radio settings and access a wide range of mobile device features. Google has now patched the flaw by forbidding a locked bootloader to boot with the dangerous boot modes. In December, researchers revealed that a new variant of Android malware called Gooligan was exploiting unpatched vulnerabilities to steal sensitive user data. Sursa: http://www.zdnet.com/article/google-patches-severe-android-boot-mode-vulnerability/