Posted April 22nd, 2010 by rybolov
Do you really need an explanation? OK, I’ll give you one hint on the meme.
Posted in IKANHAZFIZMA | 1 Comment »
Tags: government • infosec • itsatrap • lolcats • management
Posted April 20th, 2010 by rybolov
Go have a look at what Mike Murray and Lee Kushner have to say on what I endearingly refer to as “Stupid Contractor Tricks”.
Now I know Mike and Lee are supposed to be tactful, and they do a really good job at that. This post is not about tact. =)
You need to step back a bit and understand the business model for contractors. Because their margins are low and fixed, it means a couple of things:
- You have large-volume contracts where you still have the same margin but more total net profit.
- You can’t keep a bench of people off-project because it rapidly eats into your margin. For some companies, this means that anybody off-project for 2 weeks or more gets laid off.
- The name of the game is to win the proposal, get the work, then figure out how to staff it from rolling people onto the new project and bringing in new hires. This is vastly inefficient.
- New hires can also be to backfill on contracts where you’ve moved key people off to work something new.
So on to my advice in this particular scenario that Mike and Lee discuss: Run away as fast as you can from this offer.
There are a couple of other things that I’m thinking about here:
- A recruiter or HR person from Company A left for Company B and took their Rolodex of candidates. Hence the surprise offer. Either that, or Company A is now a sub for Company B or Company A is just the “staffing firm” getting paid $500/signed offer letter and doing business in bulk.
- The Government usually requires “Commitment Letters” from the people that have resumes submitted on a proposal. The reason for this is that the Government realizes what kind of jackassery goes on involving staffing, and requiring a signed letter gives the candidate an opportunity to decide up front.
- If you sign an offer like this, you’re letting down the rest of the InfoSec community that are contractors by letting the recruiters commoditize what we do. It’s bad for us and it’s bad for the Government.
Other stupid contractor tricks:
- Signing an exclusivity letter that they are the only people who can submit your resume on a contract.
- Making you sign an offer letter then letting the offer linger for 6+ months while you’re unemployed and could really use the ability to move on to a different job.
- Shopping resumes for people you have never met and/or do not intend to make an offer letter to.
- Changing the job completely after you have accepted the offer.
- …and you probably have more that you can put into the comments section below. =)
Posted in Odds-n-Sods, Rants, What Doesn't Work | 2 Comments »
Tags: cashcows • infosec • itsatrap • management • moneymoneymoney • risk
Posted April 12th, 2010 by rybolov
This is something I’ve been working on in my spare brain cycles: building a process for barcode hacking.
Limitations with barcode hacking:
- Feedback: is hard to get and depends on the scanner and the scanner app. In other words, you really need access to a working setup to test any kind of techniques. This isn’t web-based SQLi where you can compare the output against other results, you have to look “inside the guts” to see if a change happened.
- Reflections and Noise: Laser-based scanners have problems with reflection on phone screens. This *almost* limits you to printed barcodes and reduces some of the interactivity.
- UPC: This symbology sucks for barcode hacking because you’re limited to 12 digits, no letters are supported.
Kernels of nummieness:
- Most modern barcodes are attached via USB and are recognized as a keyboard.
- Read the previous sentence again. =) You know what to do here.
- The USPS uses DataMatrix barcodes for postage. These include command characters that “freak out” anything I read them on. This has much potential, now if I can figure out how to harness this for the powers of mischief.
- I have a Symbol 2D barcode reader, you can buy them on eBay for ~$120.
The process should run something like this:
- Configuration injection: given the make and model of the scanner, turn on all available symbologies to increase the reader attack surfaces. These command sets are available from the manufacturer and there is a wealth of untapped firmware vulns in them.
- Discovery test: to determine which symbologies are supported by the barcode scanner. The goal is to get something that supports the full ASCII set. Code 128 (1D), PDF-417, QR, Aztec, and DataMatrix are your friends here. For discovery, you can use “all 1’s” or something along those lines.
- Command injection: attempt to pass OS commands to the reader application and download and install a payload onto the OS via browser, ftp, etc or to gain a shell on the box.
- Application escape: Attempt to escape out of the application and into the OS. Then it’s just a simple matter of regular exploits *or* if you’re lucky, you’re already admin. At least try a ctrl-alt-del and see what happens.
- SQL injection: this you know, string concatenation that’s passed to the database. The problem is that depending on the system, you might not get feedback so blind SQLi is harder. “‘ or 1=1;–” probably won’t work because there isn’t really a login or when you’re scanning barcodes you’re already past that point. I think the goal here should be command execution: add users, exec OS commands, and turn on additional services.
- Malformed barcode: as a last resort, try fuzzing with non-standards-compliant barcodes to get either the scanner or the application to barf.
BTW, all the kids with their barcodes that say “‘ or 1=1;–” crack me up because they’re being barcode skiddies and don’t understand how barcodes are really used. =)
SQL Injection Bogus Example by ME! Only you can stop the stupidity.
Posted in Hack the Planet, Technical | 1 Comment »
Tags: barcode • itsatrap • pwnage • tools
Posted April 7th, 2010 by rybolov
Just a quick post to shill for Privacy Camp DC 2010 which will be taking place on the 17th of April in downtown DC. I went last year and it was much fun. The conversation ranged from recommendations for a rewrite of
The basic rundown of Privacy Camp is that it’s run like a Barcamp where the attendees are also the organizers and presenters. If you’re tired of going to death-by-powerpoint, this is the place for you. And it’s not just for government-types, there is a wide representation from non-profits and regular old commercial companies.
Anyway, what are you waiting for? Go sign up now.
Posted in Odds-n-Sods, Public Policy, The Guerilla CISO | 1 Comment »
Tags: government • infosec • infosharing • law • legislation • management • privacy • publicpolicy • security
Posted April 1st, 2010 by rybolov
In honor of the FISMA reform hearings last week, our IKANHAZFIZMA lolcats are reenacting government CISOs’ performance on Capital Hill. The haiku is just extra sauce.
Posted in FISMA, IKANHAZFIZMA | 4 Comments »
Tags: fisma • government • infosec • lolcats
Posted April 1st, 2010 by rybolov
Well, several funny things happened, they happen every week. But specifically I’m talking about the hearing in the House Committee on Homeland Security on FISMA reform–Federal Information Security: Current Challenges and Future Policy Considerations. If you’re in information security and Government, you need to go read through the prepared statements and even watch the hearing.
Also referenced is HR.4900 which was introduced by Representative Watson as a modification to FISMA. I also recommend that you have a look at it.
Now for my comments and rebuttals to the testimony:
- On the cost per sheet of FISMA compliance paper: If you buy into the State Department’s cost of $1700 per sheet, you’re absolutely daft. The cost of a security program divided by the total number of sheets of paper is probably right. In fact, if you do the security bits right, your cost per sheet will go up considerably because you’re doing much more security work while the volume of paperwork is reduced.
- Allocating budget for red teams: Do we really need penetration testing to prove that we have problems? In Mike Smith’s world, we’re just not there yet, and proving that we’re not there is just an excuse to throw the InfoSec practitioners under the bus when they’re not the people who created the situation in the first place.
- Gus Guissanie: This guy is awesome and knows his stuff. No, really, the guy is sharp.
- State Department Scanning: Hey, it almost seems like NIST has this in 800-53. Oh wait, they do, only it’s given the same precedence as everything else. More on this later.
- Technical Continuous Monitoring Tools: Does anybody else think that using products of FISMA (SCAP, CVE, CVSS) as evidence that FISMA is failing is a bit like dividing by zero? We really have to be careful of this or we’ll destroy the universe.
- Number of Detected Attacks and Incidents as a Metric: Um, this always gets a “WTF?” from me. Is the number increasing because we’re monitoring better or is it because we’re counting a whole bunch of small events as an attack (ie, IDS flagged on something), or is it because the amount of attacks are really increasing? I asked this almost 2 years ago and nobody has answered it yet.
- The Limitations of GAO: GAO are just auditors. Really, they depend on the agencies to not misrepresent facts and to give them an understanding of how their environment works. Auditing and independent assessment is not the answer here because it’s not a fraud problem, it’s a resources and workforce development problem.
- OMB Metrics: I hardly ever talk bad about OMB, but their metrics suck. Can you guys give me a call and I’ll give you some pointers? Or rather, check out what I’ve already said about federated patch and vulnerability management then give me a call.
So now for Rybolov’s plan to fix FISMA:
- You have to start with workforce management. This has been addressed numerous times and has a couple of different manifestations: DoDI 8570.10, contract clauses for levels of experience, role-based training, etc. Until you have an adequate supply of clueful people to match the demand, you will continue to get subpar performance.
- More testing will not help, it’s about execution. In the current culture, we believe that the more testing we do, the more likely the people being tested will be able to execute. This is highly wrong and I’ve commented on it before. I think that if it was really a fact of people being lazy or fraudulent then we would have fixed it by now. My theory is that the problem is that we have too many wonks who know the law but not the tech and not enough techs that know the law. In order to do the job, you need both. This is also where I deviate from the SANS/20 Critical Security Controls approach and the IGs that love it.
- Fix Plans of Actions and Milestones. These are supposed to be long-term/strategic problems, not the short-term/tactical application of patches–the tactical stuff should be automated. The reasoning is that you use these plans for budget requests for the following years.
- Fix the budget train. Right now the people with the budget (programs) are not the people running the IT and the security of it (CIO/CISO). I don’t know if the answer here is a larger dedicated budget for CISO’s staff or a larger “CISO Tax” on all program budgets. I could really policy-geek out on you here, just take my word for it that the people with the money are not the people protecting information and until you account for that, you will always have a problem.
Sights Around Capital Hill: Twice Sold Tales photo by brewbooks. Somehow seems fitting, I’ll let you figure out if there’s a connection. =)
Posted in FISMA, Public Policy, Rants, Risk Management | 7 Comments »
Tags: accreditation • auditor • C&A • catalogofcontrols • certification • comments • compliance • fisma • gao • government • infosec • law • legislation • management • metrics • NIST • omb • publicpolicy • scalability • scap • security