0

How should I approach this scenario:

I am working as a software contractor in a big telecom giant and they have an app, development for which has taken a painful two years and everyone on the team has worked very hard.

I have joined this place just two months back and have been asked to look after whatever I can grab, I also enjoy a bit more share in terms of freedom. So I started fiddling around with the live code and found a very critical glitch of not protecting the production build with obfuscation. One of the main libraries is compromised and it's only a matter of discovery before it takes all of us on an ugly ride.

I don't want to demotivate anyone, how do I approach this problem? Should I inform the whole team via a mail? Should I only ask our lead developer to fix it quietly? Or should I talk with the big guns?

atk
  • 2,411
  • 1
  • 20
  • 21
Junaid
  • 119
  • 5
  • 4
    "Why is this not obfuscated?" – Stephan Bijzitter May 10 '16 at 22:01
  • 3
    @StephanBijzitter it means making the binary unnecessarily complicated so that it's harder to manually reverse engineer, and harder for some decompilers to decompile it into something that can recompile later (note that I said 'harder' not actually 'hard'). Many security experts (myself included) consider code obfuscation to be of dubious value for most use cases. – atk May 10 '16 at 22:13
  • 4
    @atk - Stephan was suggesting that the simplest approach is to walk in to the PM's office and ask that statement, thus the quotes. He didn't ask what obfuscation is. – Wesley Long May 10 '16 at 22:27
  • @WesleyLong you're right that i misread. Leaving my comment for future readers who don't know. – atk May 10 '16 at 22:30
  • 4
    Possible duplicate of Ethical to report a critical software bug; the project is due in three weeks – gnat May 10 '16 at 23:25
  • Is it normal to let a new contractor look after whatever they want and have full access to a an app like this? Seems like there's bigger security risks here than fudging the code up. – Kilisi May 11 '16 at 06:29
  • Agree with the duplicate. As an aside OP, if you think that there is a "critical bug" because the code isn't obfuscated, that most likely isn't a bug. It's certainly not one that making the code harder to read will fix. – Lilienthal May 11 '16 at 17:58
  • See when I said critical that meant all my senses agreed to use that word. I could see the unencrypted handshake and all server end nodes including encryption passwords in plain text. I am not trying to demean the developers, I myself am one and I realise the amount of work that has gone into it. But as duty I felt bound to report it but in that I was facing a dilemma – Junaid May 11 '16 at 18:20
  • @Kilisi I think they must have calculated it in their calculations. However I personally feel that it's a well planned strategy to know about the glitches in code/documentation to put an experienced newbie in and check what his call is about the same. People here are very skilled however the app field is alien to them - more experienced in the web part / server part. – Junaid May 11 '16 at 18:24
  • So I reported it today, my immediate manager got a bit perturbed however the fix was quick (just a line of code in the proguard file); and some changes in the lib code. However the best advise I got here was "not to panick" – Junaid May 11 '16 at 18:27

3 Answers3

15

First off, take a breath.

Don't assume priority/severity

Start by realizing that you're new, don't know what the company has decided in the past. Your company many have already evaluated this issue and determined that it doesn't matter to them, which would make your severity rating inaccurate. Even if the company cares in general, they may have determined that it doesn't matter for this product, again making your severity rating wrong.

Assuming the company cares, fixing the bug may be much easier than you seem to anticipate. (in the case of obfuscation, it's is typically an automated process, so it's not that big of a deal to add it though the follow-up QA effort may be large. You can go over to https://security.stackexchange.com/ if you want to know more.)

Don't Panic

I bring up the above because, when you raise this, you need to do so in a calm manner. Panicking (like calling this 'critical') never helps. In fact, it will make people trust your judgment far less. Don't panic. Stay calm.

You also should be careful to let others prioritize the work and assign the severity. Your job is to report the issue so that others who understand the product and the company and the risk tolerances better can do their jobs.

Ask your boss

You report to someone. Tell them the facts of what you found and why you think it's a problem. Speak factually, without indicating priority, or using any adjectives whatsoever if you can help it. Using scary sounding adjectives will burn you if the company considers code obfuscation to be a non-issue, or has evaluated the performance or maintenance or other cost to be unworthy of the effort.

Your boss may tell you why the company doesn't care. S/he may direct you to someone technical to tell. S/he may tell you to talk to security. If so, give them the same facts you gave your boss.

Community
  • 1
atk
  • 2,411
  • 1
  • 20
  • 21
  • Yes there is three tier security which checks the code before we publish. I am a bit panicked because the code reveals the public key and all nodes to the server, which involves payment modules. So I am amazed how this was not found by anyone before. But I take most of the points you mentioned. I shall just ask why this was not obfuscated, through proper channels of bug resolution. Thanks for the advise and yes, no panick. – Junaid May 10 '16 at 22:45
  • Agreed 100%. A conversation with the lead developer or the manager you report to would be the first step. – Carson63000 May 11 '16 at 00:45
  • 3
    @Skynet not that I know anything about the system you're talking about but isn't a public key supposed to be... public? If it was a private key I would understand the "panic" feeling. – d0nut May 11 '16 at 16:33
  • My bad, that was my mistake. However the private keys reside on the client side and that was my actual finding. – Junaid May 11 '16 at 19:07
  • @Skynet, that can be okay, too, depending upon whose private key it is and who controls the client. If the private key is unique to the client and generated on the client, they're doing good. If it's the server's private key then there are questions about what it's being used for and why it's there. If it's a shared private key between multiple clients this might be ok depending upon the application's design and threat model. – atk May 11 '16 at 19:43
12

I would hope that such a project has a bug tracking system. In which case, raise it as an issue, and inform whoever is responsible for that area of the code. There's no need to make a big song-and-dance about it.

To be honest, if you're relying on obfuscation for your security, then you've probably got bigger problems.

Simon B
  • 14,230
  • 5
  • 30
  • 53
  • To be honest, I wouldn't even go to the bug tracking system with an issue like this without having a conversation first. As @atk said in the above answer, this could well be something which has been considered, discussed and decided upon. – Carson63000 May 11 '16 at 00:44
5

So you found a bug...

Ask the developers how many open bugs they have. Yours can be added to the list. Which is probably a very long list. Nobody will be demotivated if you find a bug. Quite the contrary, every bug found makes life easier for all the developers.

Obviously don't put up your hopes that finding a bug will get you a promotion. I find a dozen every day and fix them without running around and telling everyone :-)

I'm worried though about what you mean with "fiddling around with the life code".

Someone said I should be worried about finding 12 bugs in a day... A while ago I downloaded a new version of a popular music player and after half an hour I was so pissed off that I sent ten reproducible bug reports to them within an hour.

gnasher729
  • 169,032
  • 78
  • 316
  • 508
  • I myself am a developer and I am familiar with the bug pain. Hence this question. – Junaid May 10 '16 at 22:49
  • I meant live code; a copy of the current production version from a VCS – Junaid May 10 '16 at 22:51
  • @Skynet Given that you are a developer, access to PROD should not be restricted following best practice...is it not? – Anthony May 10 '16 at 22:52
  • @gnasher729 finding a dozen(12) is not that good, actually its really bad. You probeply need to do something about that and i hope for you that most of those "bugs" are just poor features. – Raoul Mensink May 11 '16 at 11:35
  • @RaoulMensink: Tell that our testers. Do you think we should send them to the pub at critical times to keep the rate of bugs down? Maybe you are confusing that having bugs is bad, but finding bugs and fixing them is good. – gnasher729 May 11 '16 at 15:57
  • I would rather find it annoying for a "face of the business app". We are talking about scope here :) – Junaid May 11 '16 at 19:05
  • @gnasher729 No, I thought you ment finding 12 bugs with live code (that kinda scared me). Hence my comment. development is always scatter with bugs would be weird if it didnt. – Raoul Mensink May 12 '16 at 08:52