G-Archiver Harvesting Google Mail Passwords

Thwomp writes "It appears that a popular Gmail backup utility, G-Archiver, has been harvesting users' Gmail passwords. This was discovered when a developer named Dustin Brooks took a look at the code using a decompiler. He discovered a Gmail account name and password embedded in the source code. Brooks logged in and found over 1,700 emails all with user account information — with his own at the top. According to a story in Informationweek, he deleted the emails, changed the account password, and notified Google. The creator of G-Archiver has pulled the software, stating that it was debug code and was unintentionally left in the product."

Comments

A-ha!

[ccguy]

Maybe _this_ is why I'm getting more spam in my gmail account lately?
If it isn't, surely someone had a boner after reading the article and is coding as we speak...

Trust me, trust me not.

[bruce_the_loon]

Trust me, trust me not, trust me, trust me not.

Oh damn, there goes my password.

Do you believe the developer? What debug code needs to send an email containing user account information?

Re:Trust me, trust me not.

[TheRaven64]

GCC attempts to avoid this kind of problem by building itself once with the system compiler, then again with itself and then a third time with the version of itself built with itself. It then compares the binaries from the second and third attempt to see if it inserted any malicious code into itself. Of course, an attacker is likely to just write a special case for compiling GCC...

Gmail Backups?

[techpawn]

You have 6.5 gig of space on redundant remote servers. What are you backing up? Perhaps I do not understand what this application does and who needs it...

That REALLY doesn't make sense

[fph il quozientatore]

Suppose you want to harvest all users' emails by simply mailing them to your own account. Why on h^Hearth do you need the password of this account to be written in the source code?

Just wondering...

[Doodhwala]

So why did the binary program also have the password for the gmail account? One would assume that the email address would have been enough. After all, sending someone email doesn't require their password.

Re:Debug, Sure

[OptimusPaul]

I actually did something like that accidentally. I enabled debug logging on a server and later noticed that it was logging usernames and passwords for all users on the system. It wasn't my code that was logging the names and it took me a week to find where it was being done and disable it.

what was that dude's name

[rice_burners_suck]

how about that guy who modified the login program to give him a backdoor hard-coded password and username? then he modified the compiler to recognize when it was compiling login and automatically insert the code, and deleted that code from login so it wouldn't be apparent in a code review. then he modified the compiler to recognize when it was compiling itself, and insert the code to modify both itself and login, and then deleted that code from the compiler as well. now there ain't no code to do that in the source code no more, but it does it anyway. eh?

Re:what was that dude's name

[adamofgreyskull]

Ken Thomson?

The actual bug I planted in the compiler would match code in the UNIX "login" command. The replacement code would miscompile the login command so that it would accept either the intended encrypted password or a particular known password. Thus if this code were installed in binary and the binary were used to compile the login command, I could log into that system as any user.

Such blatant code would not go undetected for long. Even the most casual perusal of the source of the C compiler would raise suspicions.

(...)

The final step is represented in Figure 7. This simply adds a second Trojan horse to the one that already exists. The second pattern is aimed at the C compiler. The replacement code is a Stage I self-reproducing program that inserts both Trojan horses into the compiler. This requires a learning phase as in the Stage II example. First we compile the modified source with the normal C compiler to produce a bugged binary. We install this binary as the official C. We can now remove the bugs from the source of the compiler and the new binary will reinsert the bugs whenever it is compiled. Of course, the login command will remain bugged with no trace in source anywhere.

Re:That doesn't make sense.

[Galactic Dominator]

Not if you're debugging the authentication process. I don't know the particulars of this project, but it's a least conceivable a hash wasn't processed correctly, or some other auth error. I don't that this was some oversight however.

Plausible but unlikely.

This is why...

[Thelasko]

I stopped using shareware and only use open source software. You never know what kind of crap the programmer might have stuck in there unless you can read the source yourself.

Re:Debug, Sure... Around 1999 I found this out

[davidsyes]

by using a protocol analyzer to recover my OWN login and password for my side of the company's intranet. Turned out that the web software we used (can't remember the name, but it was not front phage, but it was indeed popular at the time) was harvesting or retaining ALL USER ACCOUNTS names and passwords. I became scared shitless because I was not sure how IT would feel. But I was former IT in the company and felt obligated to warn them that the vendor was conducting shitty coding processes and put not only OUR company at risk but other companies as well. If they had any diagnostic or call-home code in their web site building software, then potentially a corrupt employee in their company could gain some limited or full access to many companies' intranets if they gained physical access to the building. And, we all know about piggy-backing, where thieves waltzed in behind other employees, then proceeded to lift laptops, purses, keys, wallets, documents, whatever they could steal.

DAMN, I wish I could recall the name. I may ..

Here we go... I'm PRETTY damned sure it was NetObjects Fusion. Just googled "Year 1999 web building applications intranet web" and they were at the top of the list... I preferred it over front phage, but...

And, now that I Google "Year 1999 protocol analyzer sniffer packet" it seems to refresh my memory that I am PRETTY sure Sniffer Basic was the tool I used.

Of course, after that I never used any such tool on the LAN. But, being formerly in the IT department, and knowing what to look out for to help the company probably kept me out of trouble.

Re:Is this for or against Open Source?

[UbuntuDupe]

Everybody can check the source. ... But because most users/people generally are not qualified to do so,

Why do people keep saying this? It equates "I can't verify" with "no one can verify". As long as there's the possibility of someone verifying, people who can't personally verify have much better reason to trust it.

There's a parallel here (because there aren't enough flamewars in this discussion...) to creationists who say that "Because you can't personally verify the science, you're accepting evolution on faith."

Additionally, isn't there some information-theoretic argument (perhaps having to do with zero-knowledge proofs?) that an arbitrary-low probability of being caught is equivalent to a zero probability of being caught?

Yet another SCM problem

[plopez]

What happened was that a member of our development team had inserted coding used for testing G-Archiver in the debug version and forgot to delete it in the final release version.

Just a few suggestions:
1) Use source control and know how to use it. Know how to tag releases and when your code is 'frozen' and ready to ship. Communicate.

2) Know how to use your source control to ID recent changes. Review recent changes.

3) At least know how to use diff, for Christ's sake. Diff your code and look for recent changes.

4) Just a thought, you might want to move your soon to be released code to another repository. Just a thought.

5) LART any programmer touching the soon to be released code without communicating or following through (i.e. removing debug code). If the said programmer is a cowboy, move that programmer over to sales.

6) Dare I say it, QA and code reviews. Even short-cycle extreme programming has de facto code reviews in that 2 programmers check each other's work.

As projects get larger and more complex, version control get harder. But a few basic rules can help out.

Malice? Incompetence?

[bestinshow]

Had any of the emails been looked at?

If they were all unread, and if the last login on that account was like forever ago, then maybe the developer's story is the truth.

But this is a key example of where open source wins, because most eula's will have a don't decompile clause.

Re:This is why I backup my Gmail with G-Archiver

[TerminalSpin]

Not quite.

The fact that the source is available makes the publisher far less inclined to place "nastiness" in the code. For any moderately popular piece of software, some pesky kid will point out that it contains hidden routines to reprogram your VCR, drink all your beer, etc.

if the source and binaries do not match up, the same pesky kid will gleefully point it out to the world.

Now the compiler itself is a different matter - what a great place it would be to hide malware...

Re:Wha?!?

[Anonymous Coward]

(and unless the software has got a built-in ansible, that should be good enough for almost all applications.)

What are you talking about?

He probably means one of these...

Re:Wha?!?

[voxelz]

I am quite interested in learning what kind of hard firewall you have that is capable of distinguishing between a packet sent over port 80 originating in, say, Internet Explorer and any other piece of software. I am also interested in knowing what software firewall you have that can block applications from rewriting its rules to allow themselves access. I know the free version of ZoneAlarm can distinguish which program is sending data over port 80. Additionally, I would hope that all firewalls do this. ZoneAlarm even asks you for verification when the program checksum is changed / updated. I can't elaborate much on the second, but there are fairly extensive protections against rewriting the firewall rules. You cannot simply overwrite a settings.xml file without it complaining. Still, a firewall will not prevent G-Archiver application from sending your login credentials to gmail, since you must already give the program access to the port used to download and archive your emails.

Re:Wha?!?

[Anonymous Coward]

http://en.wikipedia.org/wiki/Ansible

You've never read Asimov's Foundation series?

(captcha: babbling. heh.)

Not to be droll

[IBitOBear]

Turns out, I have actually oiled snakes. And I am not talking plumbing snakes.

I worked at a pet store that did some light animal care, and snakes were some of the animals we treated and kept. The oil was Linatone(tm). It helps snakes shed, and it is lightly anti-biotic and anti-microbial and anti-parasite. (it makes reptiles happy 8-).

So yes, snake oil for oiling snakes...