(Yes, last week was indeed an April Fools' joke)
(This week isn't.)
Domain names are a blessing and a curse. It's a lot easier to remember "sempf.net" than "168.62.224.13". The domain registration system is also on the front lines of fighting spam and malware - and it is under attack by the Powers That Be. Overreaching privacy law is about to make blue teaming a lot harder.
https://krebsonsecurity.com/2018/03/who-is-afraid-of-more-spams-and-scams/
Twitter thread regarding Tmobile Austria storing passwords in plain text. Warning: rough language
https://twitter.com/c_pellegrino/status/981409466242486272
https://motherboard.vice.com/en_us/article/7xdeby/t-mobile-stores-part-of-customers-passwords-in-plaintext-says-it-has-amazingly-good-security?utm_campaign=sharebutton
So, if they store the WHOLE password salted and hashed, but keep the first 4 characters in plain text just to help customer service, it is still a vulnerability?
Three Vulnerabilities Discovered in Spring Development Framework. Patchy patchy.
https://t.co/ytHgTw59LU
Critical — RCE Attack (CVE-2018-1270)
High — Directory Traversal Attack (CVE-2018-1271)
Low — Multipart Content Pollution (CVE-2018-1272) https://t.co/3UQj3iD3qO
Normally I link to primary sources, but El Reg did such a good job writing up the trustwave report I want to link to them. Good, tongue-in-cheek breakdown of the TRustwave report, which is pretty ugly (Spoiler: criminals are getting better, and we are not catching up). Link to the report at the end of the article - there will be a quiz.
https://www.theregister.co.uk/AMP/2018/04/05/trustwave_security_sitrep/
And that's the news
I am testing an application that only works on Internet Explorer in compatibility mode. Before you laugh, it's is EXACTLY these legacy applications that get us into trouble, and they should be tested regularly, and they can be secured using compensating controls. However, I am on the client's computer, which has enterprise controls on the proxy, which means I can't easily configure IE to use Burp because it uses the system proxy.
Fiddler, however, traps WinINET so it will see the traffic from IE, even with the proxy set to the corporate settings. Fiddler is only an average-at-best security testing tool though, so I would like to use Burp too. The solution is to chain the proxies, and all of the instructions I am reading online are out of date. Because of this I thought I would add to the corpus because it is quite simple these days.
First it is important to know that Burp Suite listens on localhost, port 8080. This is what you need to set your browser to in order to have the requests and responses filtered through Burp. We can leave these settings as default.
Fiddler's proxy is localhost, 8888, but that doesn't matter on Windows. Since it listens on the network channel, we don't have to do anything - Fiddler "Just Works (tm)." You can leave these settings default as well.
The "Gateway" tab in the Options dialog has settings to proxy Fiddler outbound. It will probably be set to System settings, as it should, but we are going to change that for this exercise. Just like you would normally do in Chrome, set the proxy to manual, and set the values to localhost, 8080. (Remember 127.0.0.1 is localhost)
That's it! Now every request and response will go through Fiddler and Burp. Note that some of your enterprise applications might notice the proxy change and stop working, but at least you can get through your test. Happy hacking!
Chinese cell phone manufacturer OnePlus (incidentally my daily carry) plans on including cryptocurrency mining baked into their next release of Oxygen in the OnePlus 6, sparking security concerns.
The IETF floated a new analog protocol for internet traffic in an attempt to get some more security in the system.
https://tools.ietf.org/html/rfc1149
I don't often talk biotech here, but Razer (the gaming hardware maker) is creating a nanobot infused energy drink for gamers. I am sure that will go well.
https://www.razer.com/campaigns/project-venom-v2
Finally some good news - plans to add a security parameter in response headers. Should be a good move toward better browser level decision making.
https://tools.ietf.org/html/rfc3514
And that's been your week in application security.
HSTS tracking beats even incognito mode in browsers, and it more and more often used by advertisers. In the most recent edition of OSX, Safari has two mitigations in place for this issue. Let's hope other browsers follow suit shortly.
https://thehackernews.com/2018/03/hsts-supercookie-tracking.html
Here's a really good writeup by as researcher that discovered an XML External Entity vulnerability in Windows Remote Assistance.
https://krbtgt.pw/windows-remote-assistance-xxe-vulnerability/
Dropbox and Netflix join the growing group of large technology organizations promising not to sue white hat security researchers.
https://www.theregister.co.uk/AMP/2018/03/22/netflix_bounty_dropbox_promise/
Here's another application vulnerability analysis procedure, well written and organized.
https://jdow.io/blog/2018/03/18/web-application-penetration-testing-methodology/
No, I haven't given up on my OTHER blog series about application vulnerability assessment but an opportunity opened up to start publishing my client newsletter on my blog. It's just usually four stories about appsec that I think are particularly important this week. Not even a lot of commentary, but if you only have so much time to absorb appsec news, then this could be a great way to fit some news in.
Enough chatting, this weeks stories:
Any authenticated user on a Samba 4 Active Directory can change any other users' password via LDAP. A patch is available.
https://www.theregister.co.uk/2018/03/14/samba_password_bug/
Ass we all surmised, there was an app that leveraged Open Graph to download profiles from Facebook for the purposes of crafting the election advertising.
https://www.theguardian.com/news/2018/mar/17/cambridge-analytica-facebook-influence-us-election
I spend a lot of time talking about the Facebook Open Graph, here I am three years ago at Cleveland BSides:
https://www.youtube.com/watch?v=Ze9Pzb1KSFw&feature=youtu.be&t=12m26s
Abusing Certificate Transparency logs to get subdomains from an HTTPS website:
https://github.com/UnaPibaGeek/ctfr
A nice primer on breaking encryption from MalwareBytes:
https://blog.malwarebytes.com/threat-analysis/2018/03/encryption-101-how-to-break-encryption/
Happy hunting!
I'll be doing a live webinar on Application Vulnerability Analysis on February 8 at 2PM EST - 1 month from today - and it will be a lot of fun! You can hang out in the afternoon and hack some stuff, at least the east coast folks. West coast people can start their afternoon early. Europe - you are on your own. India - you should be sleeping.
Here is the link:
https://www.wintellect.com/webinar/check-security-digging-application-vulnerability-analysis/
We'll talk about a few principles and then work through using an attack proxy to look for insecure direct object references, forced browsing, injection vulnerabilities, and whatever else comes to mind.
Thanks to WintellectNOW for having me on.
Hop to see you there!
Welcome to the 6th day of the C# Advent! Let's encrypt some malware.
That sounds horrible, but in security testing, sometimes you have to use the tools of the bad guy to make sure you aren't likely to be susceptible to any attacks. There are many such tools, but a new one - one that takes instructions from an HTTP web server - was developed by Dave Kennedy of TrustedSec. Called TrevorC2, it is a Python Command and Control server with a variety of clients. The attacker would install the client on the target workstation, and have a server delivering commands. In this case, it is over HTTP. And one of the clients is in C#. And encrypted in AES.
Wait, what? AES? Really?
Yes, really. Companies look for certain strings that are common in command and control servers moving across their networks. So, the attackers encrypt things! How do we find it then? Well, that's not our problem at the moment - we just need to figure out how to replicate what the bad guys are doing. So, that's the task for this day of the C# Advent - implement AES in C# that will talk nice to a Python command an control server over HTTP.
Fortunately, most of it I have written. The communication bits in C# are pretty straightforward, but the encryption piece is not at all. When I started, I wanted to use System.Security.Cryptography.Aes, but guess what? It ain't that easy. The Python client encryption method looks like this:
def encrypt(self, raw):
raw = self._pad(AESCipher.str_to_bytes(raw))
iv = Random.new().read(AES.block_size)
cipher = AES.new(self.key, AES.MODE_CBC, iv)
return base64.b64encode(iv + cipher.encrypt(raw)).decode('utf-8')
My initial take was something like this for an encrypt method:
static string Encrypt(string target)
{
byte[] result = null;
try
{
if (target == null || target.Length <= 0)
throw new ArgumentNullException("plainText");
using (Aes aesAlg = Aes.Create())
{
aesAlg.Key = Cipher;
ICryptoTransform encryptor = aesAlg.CreateEncryptor(aesAlg.Key, aesAlg.IV);
using (MemoryStream msEncrypt = new MemoryStream())
{
using (CryptoStream csEncrypt = new CryptoStream(msEncrypt, encryptor, CryptoStreamMode.Write))
{
using (StreamWriter swEncrypt = new StreamWriter(csEncrypt))
{
swEncrypt.Write(target);
}
result = msEncrypt.ToArray();
}
}
}
}
catch(Exception e)
{
Console.Write(e.Message);
}
return Encoding.ASCII.GetString(result);
}
That didn't work. So, I did what any good senior developer would do. I buckled down, focused, and looked for a library written by someone smarter than me. Fortunately, Adam Caudill is out there with libsodium.net, a C# implementation of the well known NaCl library. There's the solution I needed.
Libsodium.net is a living breathing example of how complicated encryption can be. NaCl is a very well known implementation of the main encryption protocols ... in C. Yeah, C. You can use it in other languages but C is what NaCl is for.
The chem majors among us will recognize that NaCl is table salt. Thus, Sodium. Libsodium is a higher level library for C++ and ilk, and then Adam's implementation uses the .NET native libraries to perform the same tasks. It's a reasonable legacy, and you should consider it if you have to write encryption code, as, well, I do right now.
Anyway, the interface is SUPER easy to use. The SecretBox holds everything you need, including the abilityto generate the nonce required for the AES encryption, and to do the actual work.
So, my NEW method, after adding libsodium.net, looks like this:
static string Encrypt(string target)
{
try
{
var nonce = SecretBox.GenerateNonce();
var result = SecretBox.Create(target, nonce, Cipher);
}
catch (Exception e)
{
Console.Write(e.Message);
}
return Encoding.ASCII.GetString(result);
}
Tune back in next week, after I get my Trevor server up and running, and we'll get everything configured and working. (Remember, play with malware on a network that is not your employer's network!)
Reconnaissance means something different for pentesters as it does from vulnerability analysts. It is, truthfully, the first obvious break between the two forms of testing. For vulnerability analysts, reconnaissance means doing all of the research that is required to understand what one apps does, and how it works. For pentesters, reconnaissance means doing the vulnerability analysis. Remember, their job is to exploit the vulnerabilities. Finding the vulnerabilities is part of the reconnaissance! For vulnerability analysts, though, we have to go a little deeper into research the application itself, in order to find every possibly vulnerability.
I have quite a list - reconnaissance usually takes me a whole day of the week long test. I recommend not just running a scan - the idea is to get an idea of what the app does, and how well it does it. If I can, I schedule a chat with the dev lead to talk about what the app should do, and then I write the application summary of the report after I have indexed the app. But I am getting ahead of myself.
Beginning reconnaissance starts ahead of the application. Usually when I start, I just have a URL and credentials, just like an attacker would (we'll assume he stole the credentials from a user, cause that's pretty easy). The absolute first thing I want to do is look at the network and the server. Fortunately, there are two awesome free tools that will help you do this.
However, in order to do these, you will need an environment in which to do so. If you read my earlier posts you will know that I like Windows 10 for testing - putting me at odds with most of the industry. I do, however, acknowledge the weaknesses of the platform for some kinds of testing, and Perl and Python scripts are included in that. Therefore, I usually use a Kali Linux VM for scripts, because nearly everything I use is preinstalled. And there is a new tool on the horizon, PentestBox, which does everything in a modified command prompt right in Windows. It's pretty slick.
Start with the network (for one thing, this will give you the IP of the server). Really, we will probably just "network scan" one machine, depending on your scope, but that's OK. The tool you want to use is nmap. It's a fantastic open source vulnerability scanner for the network surrounding the web server in question. I got a favorite set of parameters from the awesome Jon Welborn, and I recommend it:
nmap -sS -Pn -v --script=default,vuln,safe -oA nameOfOutputFile IPofTarget
For the web server itself, there are a couple of options, and I still like Nikto. I like Nikto because I have a custom ruleset for Nikto, and no you can't have it because it has client information in it. That said, there are a LOT of other tools, and there is a very interesting and more updated tool for Windows (see my earlier posts for my thoughts on that) that might suit you better. That said, Nikto is easy to run, and it does catch a lot of stuff, especially on older installs, and even kinda not that old installs. It's still pretty slick.
nikto -host IPofTarget
Another part of recon is getting details about the encryption certificate being used to protect communicate with the browser. If the site is public facing, I use Qualys's free SSL Test. If the site is in an internal network, SSL Test can't see it, though, so you have to use another script. My usual go-to is SSLScan, which is also super easy in either Kali or PentestBox.
SSLScan IPofTarget
OK, enough of running scripts. Next I turn to my proxy. There are two I use, Burp Suite and ZAP. Burp Suite is a paid, closed source application with a company backing it, complete with researchers and devs and everything. It is well supported and has lots and lots of features. ZAP is a free, open source application with a company backing it, complete with researchers and devs and everything. It is well supported and has lots and lots of features. It's your call. However, for whatever reason, if you are working for an organization with a standard vulnerability program, the results are expected to be turned in using Burp. Otherwise, ZAP is a fantastic tool.
What we are going to do with the proxy is index the site. This works differently in Burp and ZAP, so I am just going to talk generalities here. First, with the proxy running, exercise the application completely. Some folks like to make a separate file from the proxy for each role, but I just use the labeling feature to label important interactions with their role. This is the admin login. This is the Admin adding a user. This is a user adding a user. WHOOPS. Shouldn't be able to do that. You get the idea.
Next we want to write the Application Summary. This is part of the report that tells what the application does. Why do we need to tell the developer what the application does? To make sure we are on the same page. You would not believe the number of times I have had the developer say "Didn't you test the Admin screens?" WHAT admin screens? That wasn't in the scope? Well, it was supposed to be. What you do business wise from there is up to you, but it lays a level set as to what the scope really was.
Then it is time to brute force. I use FuzzDB to get a list of known web directories and files, and then use the brute force tools to implement them. In ZAP, it's just called Forced Browse in ZAP. but for Burp you need to use Intruder and get fancy. I load up the first GET (for /) and then put the weird § signs right after, and run a directory scan, then a file scan. Then I run a file scan on any interesting looking directories. You will not BELIEVE what you will find, sometimes. There are 30,000 words in that Medium directory listing.
Finally, spidering. This is just like the old days, or like the Google spider - the proxy will look for any URLs, and attempt to follow them. Nice thing about attack proxies, they will look in comments, JavaScript, CSS, text files, anything it can for URLs. Then it adds them to the site map.
Once we have a solid look at the application, we scan. I don't suggest just right clicking on the host and selecting Active Scan. It takes forever, makes a crapload of extra stuff in the Burp file, and won't earn you much. Instead, look for interesting POSTs, or GETs with neat stuff in the URL. Stuff that gets edited. That's where the magic is.
While the scanning is happening, we do the "insight" portion of the recon. First, get the comments. In Burp, that's engagement tools, and ZAP uses an addon. Read them. Look for developer names, open source packages, interesting stuff. The hit Google. No, I'm not kidding. Look for existing, known vulnerabilities. Do they have a vulnerable version of JQuery? Look up the devs. Their LinkedIn, Facebook. Then get their StackOverflow profile. Asked any security questions recently? Any code in there? Are you smelling what I'm cooking here?
This is also the time when you look for weird stuff. Is there file upload? Notate it. Method name in a URL? Point that out. Redirects, like a URL in a querystring? Make a note. Encoded strings? Weird hidden HTML INPUT fields? Cookies you've never seen? Those are all Things That Are Weird. You need to add them to the file, and check on them in the analysis.
Last thing - need to take apart anything binary. Flash? Java applets? ActiveX (pleaseno)? Take them apart. There are decompilation tools out there, and at least run strings (it's in Kali) to see what's in there. You'd be amazed.
That's just about it for recon. I store everything in Evidence, and then step away from the app, even if just overnight. Fresh eyes and all that. The analysis part will likely take a bit, so we will break that over several posts.
Being a vulnerability analyst has a few humorous artifacts. This takes a few different forms, but in general it's like having 100 projects - with all the related notifications - but not being responsible for them anymore.
As an adhoc member of the team for just a few weeks, you tend to get full access to everything, and then sometimes never lose it. For instance, I get TestFlight notifications for iOS applications I tested two years ago. I go unsub when I see them, but I have tested so many iOS applications, and some of them update less frequently, so I get a notification and think "Oh yeah, that app!".
Also, I regularly get put on code repositories. Now, those get edited more often, so I usually can go and remove myself, but sometimes they are internal, so I am geting alerts but can't change the settings. I'll email the dev lead, get the "oh yeah I'll fix that" and then get a task assigned to me randomly two weeks later. It's a lot of fun.
The best is Jira. I'll get added to Jira as a source for bugs, and then questions will get directed back to me. As many readers know, the average for remediation of security flaws hovers around 360 days. Often, I'll get a ticket that has me as the source assigned to a junior developer, and get an email from an (often internal) Jira system saying "What the heck does any of this mean?!??!" Those are always a good time too.
My very most favorite is when developers get a vulnerability on a card sometime down the road, and look me up months or even years later for clarification. This is exactly the kind of thing I like to see. Honestly, often the environment has changed around the vulnerability, but it restarts the conversation. This kind of followup is something that is going to help save appsec, and we need more folks like that.
All of this fancy organization and lists are just tools for the goal - making a list of everything that is wrong with an application. When I start a test, I get a URL, a description of how the application works, credentials for two user accounts for each role, and a pat on the back. This effectively emulates an attacker on “the inside” - they have already found a way in as they will. Now they have to take the next step. That’s what I do: take that next step before the attacker finds the app, and list all of the problems in the app that will give the attacker a leg up.
Truth is, though, I have 40 hours and they have all the time they need. So, information organization is or the most importance to me. I take copious notes, use full test plans, and track statistics to keep the apps I test ahead of the attackers. So let’s talk about how I organize information to run a test.
The information about the test has to be protected. When possible, I use a VPN protected repo to control the information, evidence, and reports related to an application. I check out my details at the beginning of the day, check them in the end of the day. Sounds like a dev? Yup. Worse, I use Subversion. Yeah, go ahead and hate. Remember, I don’t have branching and merging, so the SVN commands are a lot simpler. Some of the folks I work with still use CVS so it could be worse.
Quick note: I have a pretty solid network in my home office. I use a business class router, a grid wireless network, and I get help from people who know networking to set things up. Do this.
All of the information for a test is stored with this structure:
/client
/year
/application
/information
/evidence
/reports
I argue with myself about the order of year and application all the time, and even year and client. Information architecture is a pain in the ass. Did you know that the study of information architecture is called “ontology” and the study of treating cancer is called “oncology”? There is a reason. Anyway, let’s talk about what goes where.
- The Information folder is stuff that the client gives me about the test. Sometimes it is empty. Sometimes it has an email, WDSL files, documentation, the APK or IPA binary, source code, or osint I have performed.
- The Evidence folder is everything that I have that supports my findings. The Burp state, screen shots, the notes and test plan (more on that in a sec), anything I stole, Nikto and SSLtest and other scans, databases, like that.
- The reports folder has twinkies. No, that’s where I put the reports. Mostly, it’s just THE report, but sometimes I save Burp or Nessus reports, summaries, code reviews - basically anything that is to be turned over to the client.
There are three files that are very important and they make up the core of the information architecture for an assessment that we start with.
- The Test Plan. This is a big Excel spreadsheet with tests to run. It is based on the OWASP Testing Guide, and The Web Application Hackers Handbook, Volume 2. I’ll probably release it later in the series. It goes in the Evidence folder.
- The Notes. This is a text file, with three sections. At the top is the URL and credentials, plus any other salient information. Then there is a Notes section, where I put anything that I find that is interesting as I am doing recon. “This URL has a filename as a parameter.” or “Here is a file upload.” Finally there is a findings section. This should match with the test plan failures, and contain the textual evidence. This usually is a request and response pair, but we will cover it later in the series.
- The Report template. I do have a report template, but unlike most, I don’t have a lot of text in there about my testing process. No one has complained yet. If you are a client, and hate the fact that I don’t double the size of the report with process text, let me know. But, I do use a template, and I like it. I’ll cover what’s in it in the reporting chapter.
To make sure I have a good, clean set of evidence, I reset everything I use to default values before I start. I use FireFox only for testing, not browsing or anything else, so clearing cookies is no big deal every test. I clear the browser history, the cookies, the webdb, everything after each test.