Slashdot Mirror
Googling Your Way Into Hacking
knifee writes "New scientist is running an article explaining how hackers can use Google's cache to quickly hunt down sensitive pages, for example, by searching the terms "bash history", "temporary" and "password".
Might be worth looking at this tutorial about robots.txt if you think you might be at risk." That's pretty amusing.
It is always a good iea to kep the robots out of anywhere there is sensitive information. i several methods for added security. robot.txt is a good way, but i also the deflecction technique in apache's mod_rewrite to keep the crawlers out.
Consensus is good, but informed dictatorship is better
- mpg
- mov
- mp3
- secret - doesn't have to be file extensions...
- "My Documents" - yeah, that's secure...
- etc
Anyway, as you can see, it's pretty effective. Sometimes admins wise up, and all you have is the Google cache. But sometimes they don't, and you get to look. Thanks Google!A programmer is a machine for converting coffee into code.
> The first thing I do when I log onto a box is link > bash_history to /dev/null
unset HISTFILE
BZZT, wrong.
/., you'll get neither.
* is a character not allowed in the encrypted 13-character A-Za-z0-9./ password, and as such the account can not be logged in to.
x is used for shadow passwords.
Anyhow, I think the original poster aimed for a +1 Funny, and not +1 Insightful. If there's any justice on
Regards,
--
*Art
Even better yet, "rm ~/.bash_history && ln -s /dev/dsp ~/.bash_history". Now everything you type will literally "sound like crap".
/etc/csh.cshrc and etc/csh.login. It then executes commands from files in the user's home directory: first ~/.tcshrc (+) or, if ~/.tcshrc is not found, ~/.cshrc, then ~/.history (or the value of the histfile shell variable), then ~/.login, and finally ~/.cshdirs (or the value of the dirsfile shell variable) +). The shell may read /etc/csh.login before instead of after /etc/csh.cshrc, and ~/.login before instead of after ~/.tcshrc or ~/.cshrc and ~/.history, if so compiled; see the version shell variable. (+)
/etc/csh.cshrc or /etc/csh.login you *might* wanna just throw in something like the following shellcode:
...
;)
/dev/null
But uhh...from the tcsh manpage (emphasis mine)
A login shell begins by executing commands from the system files
Looks like tcsh has a history file as well, "if so compiled"? Just thought I'd point that out something you might wanna check into?
also in your
# just to make sure the user didn't delete the
# symlink
if ( -e ~/.history ) then
rm -f ~/.history
endif
ln -s ~/.bash_history
My journal has hot
Anyone familiar with Big Brother knows that it has web access pages that allow you to monitor servers on your network. Of course your suppose to keep these pages private, but lots of people dont. This makes it easy for us to determine what servers are running on a network, and what services are running on each server.
;)
Try searching google for: red Big Brother Status
Enjoy
Where I come from, a cracker is a crispy salty biscuit. Or a honkey.
Hey, you must be right! Go tell your friends and relatives. I'll be investing in the tin foil market.
In the mean time, please note that ALL search engines ALWAYS obey the robots.txt file for a very good reason: it specifies which pages might be dynamic. Maybe your evil "working for The Man" search engine likes to return lists of 4500 ebay auctions which no longer exist, online quizzes filled out with all blanks' results, and other such amazingly useful information but real sites like google are not interested.
If you like this kind of tricks you can find dozen tricks like those ones and betteron Fravia's web site SearchLores.
-- search the web
If you're lazy and wanted to transfer ICQ information between sites, you might just toss it up on some webspace you have, download it from where you wanted it, and then forget about it forever.
if only slashdots search was as good as googles i could point out this is the third time in a year this "story" has been run.
MARIJUANA, SHROOMS, X: ONLINE?! - E
Not the same kind of "hacks", but more than one might have missed that O'Reilly published recently Google Hacks. Mostly targeted to webmasters or "power users".
This paid my last vacation, it mi
Here is a nice tutorial about the topic.
We do not have a history of profitable operations. Our future SCOsource licensing revenue is uncertain.
ln -s ~/.bash_history /dev/random
/dev/random ~/.bash_history
Whoops!
You meant: ln -s
http://www.smart-dev.com/texts/google.txt
Set up a virtual machine (user-mode linux might be a good choice) and make sure the root password is in a whole bunch of files that skript kiddies are likely to google for, and in which the root account might reasonably be found (if the admin is stupid, that is).
Set the login shell to an application which creates a fake shell, and which uses the opportunity to ID the intruder's computer and download a bunch of stress-testing tools. cpuburn might be a good one for this.
The choice of downloads is important. You've got to be able to show a legit purpose for all of this, and one good purpose is to have a tool you can use to stress-test hardware on a remote machine. If you do freelance tech work, then being able to check the hardware on a machine is self-evidently a legit purpose.
Once you can show a legit purpose (whether you use it or not), and you can show that you've made a reasonable effort to prevent non-legit users from stumbling into the account (ie: by setting a password), then I can't see any way a person can claim they were suckered in and entrapped.
It takes a deliberate, concious act of will to perform a search on Google. It takes another deliberate, concious act of will to use that information to connect onto a remote computer. Since the account is not theirs, and they have no reason to believe otherwise, they are guilty of attempting to defraud the computer through identity theft, at the very least. There's no way it could be passed off as "accidently" stumbling onto a service, which could be a valid defence against traditional honeypots.
Because there's a legit use for the services, and because the attacker has actively carried out an attack on your machine with malicious intent, it would be extremely hard for them to successfully sue you for any damage caused.
It's not like placing a firecracker in a box marked "open this". It would be closer to placing a revolver in a locked cabinet, and a would-be thief accidently shooting themselves in the foot, after breaking into the cabinet.
The first case, there's no obvious risk, so the person can claim they've not assumed responsibility for any such risk. Stupidity is not a crime.
The second case is different. The person is actively performing actions they know to be illegal, and for purposes which can only be malicious. They've passed the point where they can claim they're just an innocent bystander.
Likewise, a traditional honeypot - especially one that causes damage - might well be considered in the first category. A person may well accidently stumble on it, and then any damage is the responsibility of the person setting the trap. (Don't even think of telling me you've never mis-typed an IP address.)
However, a dual-purpose service, behind a password-protected account, where the username of that account makes it self-evident that this is not a public area, cannot even remotely be placed in that category. The intruder cannot claim innocence or lack of awareness. As such, any damage they suffer is their problem. They've assumed the risks involved, knowingly of their own free will. At that point, if your utils turn their machine into scrap metal, it's not your problem.
Note: Law-enforcement types are authorized to break into machines and plant all sorts of sniffers, etc, on them, without approval and without the machine or owner having to have anything to do with any investigation. It is not clear if frying their computers, even if it could be shown that it was self-inflicted and that the software was dual-use, would be considered acceptable.
Because of this, the information above is hereby defined as being for academic interest only. If you choose to use the information, and Joe FBI gets burned, that is beween you and them.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Google Search: inurl:bash_history
If you can't wait until the next time Google crawls your site to have your information removed, you can always use Google's Automatic URL Removal System. Details are available here.
A few months back I updated all of my web pages to include the NOARCHIVE META tag. I then submitted my site to Google's Removal System and within three days Google had crawled everything and updated their database. The result was that my pages were still searchable, they just weren't cached.
As you noted, though, there are plenty of robots that do not obey robots.txt. Google may be conscientious, but others are not.
I've also been searching Google this way for years, it's a good way of getting what you need without having your browser cache clogged with cookies...
I've noticed that everyone who is for abortion has already been born - Ronald Reagan
Nope...doesn't pass the LUHN check. See LUHN Check.
"Rub her feet." -- L.L.
Do this at a shell;
Notice anything odd? It's entirely likely that .bash_history may end up outside a user's (or root's) home directory depending on where you are when you login to a new account.
If you want to avoid that, try...
where USERNAME is the account name (or optionally nothing if root).
The - will make sure that the environment settings will be the current default settings for that account. Login as root, change to another directory, change the environment settings, execute "su -", then check your environment and location. Change directories, and use "su" (no "-"), and see what happens. Exit from the shell a couple times. Nope, that little factoid isn't explicitly in the su man page.
By default, your history files are only readable by you and is not group/world readable. Your shell actually sets this up--regardless of your umask--when it first creates the file so only a bozo who manually changes the modes deserves what they get as a consequence.
Also, entrapment is only illegal if the law officers used fraud or undue persuasion to cause someone to commit a crime -- so much so, that an ordinarily law-abiding person would be compelled to commit the crime.
n ts/nationalbudgetsdefecitsorspending/lawdeceit.htm l
Cops can tempt criminals to commit crimes, and even initiate or plan out the criminal act (ie, buying or selling drugs, offering or buying prostitution, planning a bank robbery heist). None of this is entrapment, unless their actions would have cause a normally law-abiding person to commit the crime.
If a cop tricks someone into unintenionally breaking the law, or harasses them so much that they eventually cave in and break the law, or threaten them, etc, it may be entrapment. It's actually pretty subjective and up to the jury, usually.
But a lot of misconceptions of entrapment abount -- ie the ever-popular, "if you ask them if they're a cop, and they say no, then it's entrapment." And also the misconception that entrapment is a crime and can apply to non-law-enforcement. It's not a crime, it's a defense against being charged with a crime. (Well, unless you perform a crime while trying to get someone to perform a crime -- that's still a crime)
For a somewhat inflammatory discussion, see this: http://www.libertyhaven.com/politicsandcurrenteve
I had a more objective look at it, written by a lawyer, but I can't find it.
sorry if this is off-topic.
The following sentence is true. The preceding sentence was false.
http://www.vamos-wentworth.org/robots.txt
http://www.vamos-wentworth.org/no_way
cpeterso
Hehe, no he didnt disapeared at all. And i can tell you he's alive and kicking. Yet you may find his old data here on the AntiCrack website.
One question: does WoW stands for Warriors of Wasteland?
-- search the web
Actually, I do not link bash_history to /dev/null.
/tmp/../foo , grep his IP out of the message logs, etc. etc. The only thing that he forgot to do was remove the bash_history file, and I knew _exactly_ what damage he had done to my system.
I've been compromised once, and the attacker went through great length to install a rootkit in
<grub> Reading
The simpler alternative is to just not produce a history file at all. In the .cshrc, add this line:
unset history
.-.--
http://www.theregister.co.uk/content/55/32103.html
In short, the anti-spammers found a WSFTP.LOG and used it to find zips with email addresses.
Funny to see this on the register so soon after this slashdot article