4 ms·

I really don't think .gov cares all that much. Over a year ago, I came across a vulnerable .gov site that was first reported in a news.com article from 2005!

by jjarmoc 12y ago

I really don't think .gov cares all that much. Over a year ago, I came across a vulnerable .gov site that was first reported in a news.com article from 2005! Sadly, it's still vulnerable today. The author of the original piece states they contacted the Department of Labor back in '05, who responded that they were 'working to address the issue.' Before I wrote the blogpost, I tried getting some attention too, but never got a response. It's now been 9 years, and the site is still vulnerable. http://jarmoc.com/blog/2013/10/14/open-redirect-in-gov-for-eight-years/ http://jarmoc.com/blog/2013/10/14/open-redirect-in-gov-for-e... .gov sites are littered with trivial vulns that never seem to get addressed when reported. HTTPS is great and all, but it's far from the only thing that needs to be done in .gov.

seanherron 12y ago
(18Fer here) That's one of the things we're very much focused on fixing. While we can't go in and change every federal government website out there, we can work to ensure that the security of the platforms we are working on is tight as possible. 18F is working with a number of agencies (see https://18f.gsa.gov/dashboard/ https://18f.gsa.gov/dashboard/ for the full list), and our hope is that we can be a force multiplier in security best practices throughout government. Furthermore, we take responsible disclosure very seriously, and welcome any feedback through our email (18f@gsa.gov). We should probably take this up a notch and have a dedicated security inbox that goes directly to our core security team.
- jjarmoc 12y ago
  I didn't mean to imply that 18F is responsible for everything in the .gov namespace, and I have no reason to doubt that you guys take security seriously. The problem, from my perspective, is that NO ONE is responsible for everything in the .gov namespace. Trying to sort out an appropriate security contact, especially for relatively minor vulns like this (though it's likely also reflected cross site scripting on benefits.gov) is a nightmare. Another example involves some work I did while at a previous employer: https://web.archive.org/web/20131114050720/http://www.secureworks.com/resources/blog/research/spam-government-websites-abused-ongoing-spam-campaign/ https://web.archive.org/web/20131114050720/http://www.secure... I definitely think you're right that a dedicated security inbox would be helpful. Even better would be a dedicated .gov-wide security inbox. I don't know how difficult it would be to establish something like that, but it would give security minded folks who care about improving things an outlet for sharing these sorts of details, and hopefully help get things fixed.
  - mpyne 12y ago
    > The problem, from my perspective, is that NO ONE is responsible for everything in the .gov namespace. Actually, the Department of Homeland Security is responsible for the security of .gov (at least in theory). I don't think they have unilateral directive authority to enforce that, however, which is a big problem. But maybe reporting the issue to DHS (whatever their cyber security division is) can rattle something loose.
    - cmder 12y ago
      US-CERT handles information security incidents and reports within DHS: https://www.us-cert.gov/report https://www.us-cert.gov/report
acdha 12y ago
One of the big things you have to remember is that the government is not only large and inconsistent (imagine a F500 with a ton of acquisitions and you're on the right track). I'd put pretty good odds that there's someone who cares at most of those .gov sites and they've been trying to get their management to authorize a fix for many years. In many cases, they've been prevented from hiring technical staff for a decade or longer so it's not uncommon to find projects which are entirely on life-support, subject to a contract which would require expensive (in both time and money) amendments, etc. The person responsible likely knows about the problem but have zero ability to either fix it directly or get someone else to do. The other thing you tend to find are poorly considered policies with serious unintended consequences – i.e. for alleged performance/security reasons all traffic is required to go through an agency-wide load-balancer but they didn't buy the SSL module / it's already at capacity and nobody is willing to authorize an exception. (Bonus points if the old single-point-of-failure is scheduled to be replaced by a shiny new SPOF and no changes are allowed until that overdue project ships)

by jjarmoc 12y ago

seanherron 12y ago

(18Fer here) That's one of the things we're very much focused on fixing. While we can't go in and change every federal government website out there, we can work to ensure that the security of the platforms we are working on is tight as possible. 18F is working with a number of agencies (see https://18f.gsa.gov/dashboard/ https://18f.gsa.gov/dashboard/ for the full list), and our hope is that we can be a force multiplier in security best practices throughout government. Furthermore, we take responsible disclosure very seriously, and welcome any feedback through our email (18f@gsa.gov). We should probably take this up a notch and have a dedicated security inbox that goes directly to our core security team.

jjarmoc 12y ago
I didn't mean to imply that 18F is responsible for everything in the .gov namespace, and I have no reason to doubt that you guys take security seriously. The problem, from my perspective, is that NO ONE is responsible for everything in the .gov namespace. Trying to sort out an appropriate security contact, especially for relatively minor vulns like this (though it's likely also reflected cross site scripting on benefits.gov) is a nightmare. Another example involves some work I did while at a previous employer: https://web.archive.org/web/20131114050720/http://www.secureworks.com/resources/blog/research/spam-government-websites-abused-ongoing-spam-campaign/ https://web.archive.org/web/20131114050720/http://www.secure... I definitely think you're right that a dedicated security inbox would be helpful. Even better would be a dedicated .gov-wide security inbox. I don't know how difficult it would be to establish something like that, but it would give security minded folks who care about improving things an outlet for sharing these sorts of details, and hopefully help get things fixed.
- mpyne 12y ago
  > The problem, from my perspective, is that NO ONE is responsible for everything in the .gov namespace. Actually, the Department of Homeland Security is responsible for the security of .gov (at least in theory). I don't think they have unilateral directive authority to enforce that, however, which is a big problem. But maybe reporting the issue to DHS (whatever their cyber security division is) can rattle something loose.
  - cmder 12y ago
    US-CERT handles information security incidents and reports within DHS: https://www.us-cert.gov/report https://www.us-cert.gov/report

acdha 12y ago

One of the big things you have to remember is that the government is not only large and inconsistent (imagine a F500 with a ton of acquisitions and you're on the right track). I'd put pretty good odds that there's someone who cares at most of those .gov sites and they've been trying to get their management to authorize a fix for many years. In many cases, they've been prevented from hiring technical staff for a decade or longer so it's not uncommon to find projects which are entirely on life-support, subject to a contract which would require expensive (in both time and money) amendments, etc. The person responsible likely knows about the problem but have zero ability to either fix it directly or get someone else to do. The other thing you tend to find are poorly considered policies with serious unintended consequences – i.e. for alleged performance/security reasons all traffic is required to go through an agency-wide load-balancer but they didn't buy the SSL module / it's already at capacity and nobody is willing to authorize an exception. (Bonus points if the old single-point-of-failure is scheduled to be replaced by a shiny new SPOF and no changes are allowed until that overdue project ships)