Application security weekly for April 22

More news than usual today.


There is a new WebLogic RCE. I'll be adding it to Nikto this week.


Android is adding DNS over TLS. As a user I am happy about this.  As a tester, @#$%&#$%@^.


There are 100 devs for every appsec specialist.  We have out work cut out for us.


The thermometer in a fishtank was the pivot point for hackers to pwn a casino. Noice.


Holy crap I forgot about this one.  The RSA custom Android application had the API keys stored in the source code, so someone downloaded the attendee list.


Verizon last week, Microsoft this week. Annual security report.


Finally, a teen found some documents on a web server, downloaded them, and now is going to jail.  Stay safe out there kids!


And that's the news.

Application Security Weekly for April 15

The Verizon Data Breach Investigations Report is out. It's a good read.


DARPA (the government organization that created the Internet) is funding research into Human Assisted AI.


WebAuthN went to Candidate stage, perhaps leading to the end of passwords on the Internet.  But ... universal federal IDs?  Not sure.


Motherboard has a REALLY good series on phone cracking.  If you are into mobile, it's worth a look.


And that's the news


Some neat events I'll be participating in this spring

There are some neat developer and security events this spring that I'll be speaking at or otherwise participating in, and I'd love to see all of you there!

On the morning of the 18th, I'll be talking about updated OWASP Projects at the Columbus ISSA meeting.  I know daytime meetings are weird, but come by if you can. There is a small charge for non-members.

April 26th, there is an OWASP meetup where we will be following up on Jason Kent's Docker seminar and building some cool python code. This event is at the Idea Foundry, and is a lab environment - bring your machine. I'll get everyone started, but this is mostly team coding.

In May, on the 4th, I'll be speaking about the changes to the OWASP Top 10 at Stir Trek, one of the most awesome developer events in the midwest. The content is awesome, the venue is a movie theater, and you get to watch the new Avengers movie the night before the rest of the world! NO SPOILERS.

May 14th, I have the honor of speaking at one of the most awesome security events in the midwest (I told you this was quite a spring!) It's the Central Ohio InfoSec Summit, and the content is also awesome, although there isn't a movie at the end. If you can go, do so.  It's really a great conference.

Gonna be a bust few months, but some really great events.  Make sure you catch what you can - attending these events is one of the best ways to stretch your mind and see what skills you should be working on right now.

Application Security Weekly for April 8

(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 "" than "".  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.


Twitter thread regarding Tmobile Austria storing passwords in plain text. Warning: rough language

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.

Critical — RCE Attack (CVE-2018-1270)
High — Directory Traversal Attack (CVE-2018-1271)
Low — Multipart Content Pollution (CVE-2018-1272)


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.


And that's the news

Proxy Fiddler Through Burp

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 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!

Application Security Weekly for April 1

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.


 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.


Finally some good news - plans to add a security parameter in response headers.  Should be a good move toward better browser level decision making.


And that's been your week in application security.

Application Security Weekly for March 25

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.


Here's a really good writeup by as researcher that discovered an XML External Entity vulnerability in Windows Remote Assistance.


Dropbox and Netflix join the growing group of large technology organizations promising not to sue white hat security researchers.


Here's another application vulnerability analysis procedure, well written and organized.

A new blog series: Application Security Weekly

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.


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.

I spend a lot of time talking about the Facebook Open Graph, here I am three years ago at Cleveland BSides:


Abusing Certificate Transparency logs to get subdomains from an HTTPS website:


A nice primer on breaking encryption from MalwareBytes:


Happy hunting!

Live Webinar: Come talk Application Vulnerability Analysis with me and WintellectNOW

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:

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!

Day 6 of C# Advent - Coding for an encrypted service

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 =
        cipher =, 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;
                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))
                            result = msEncrypt.ToArray();
            catch(Exception e)
            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, a C# implementation of the well known NaCl library. There's the solution I needed. 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, looks like this:

        static string Encrypt(string target)
                var nonce = SecretBox.GenerateNonce();
                var result = SecretBox.Create(target, nonce, Cipher);
            catch (Exception e)
            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!) 


Bill Sempf

Husband. Father. Pentester. Secure software composer. Brewer. Lockpicker. Ninja. Insurrectionist. Lumberjack. All words that have been used to describe me recently. I help people write more secure software.



profile for Bill Sempf on Stack Exchange, a network of free, community-driven Q&A sites