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...

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...

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... 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: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.

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.

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...