7 ms·

What do you think about zsh? I really like zsh history.

jcsalterego 10y ago
zsh history, from what I've seen a long time ago, can include timestamps, which is why I added a timestamp field in the schema, though it's currently unpopulated: https://github.com/jcsalterego/historian/blob/3bf7158b163d3febca4399a90dd8eb10dcce6611/hist#L38 https://github.com/jcsalterego/historian/blob/3bf7158b163d3f... #soon
- ishigoemon 10y ago
  Bash can as well, though I'm not certain if the OS X version is new enough. http://wiki.bash-hackers.org/syntax/shellvars#histtimeformat http://wiki.bash-hackers.org/syntax/shellvars#histtimeformat
- TheGRS 10y ago
  If you're an oh-my-zsh user there is a handy part of the .zshrc config for enabling and customizing the timestamp format. Dead simple.
sillysaurus3 10y ago
I like your zsh history too. Will you post all of it here unedited? Also, on pentests the ~/.bash_history file is literally the first thing we look at. It's lovely: in an instant, you know exactly which files on the system are important, why they're being used, and what the high-priority targets might be for pivoting to a different box. In some cases it cuts hours off the job. So to keep hackers happy, please don't delete your bash history on production servers.
- viraptor 10y ago
  It's just a delay. Are you really suggesting that making work harder on a daily basis is worth it to slow down by a few hours (not preventing!) lateral movement in an already exploited system? Because that's why users hate security restrictions.
  - sillysaurus3 10y ago
    By all means, steam ahead. It's certainly your right as a developer not to be slowed down by pesky restrictions. The easiest marks were always the companies that had a culture of hating security restrictions.
    - arjie 10y ago
      Wait a minute. If you've owned my user, what's to stop you from setting the histfile even if I turned it off? Not to speak of how you can just listen to my pty. I mean, it's really clever talking like a mafia enforcer making vague threats but everyone here is treating you respectfully and you're not responding in kind. It's not cool, man. If you don't feel like engaging, don't.
    - brazzledazzle 10y ago
      I'm legitimately curious about their question so I'll phrase it differently: have you ever found something in the shell history that you wouldn't have discovered on your own? Is it more of a delay tactic or real deterrent?
      - bitexploder 10y ago
        I have done my share of internals. Some of the time you find valuable clues in administrative audit logs and bash_history. Clues that mean you make a good and impactful finding within the timeframe of your timebox. Reality is an attacker with this level of access is going to have more time than I will, but it still means a measurable impact to security because it decreased the time it took to find something. So in that sense the OP is correct, it comes down to a risk reward trade off and is it worth clearing the history to potentially buy yourself more time in the event you are owned. It isn't as black and white as "well, the server is owned, of course you have my bash_history, that is the least of my worries now..." it is, but it could also be the one thing that gives you 3 extra hours to detect and shut down an attack.
    - piva00 10y ago
      You have already pwned the machine, what disabling history is gonna do to save someone's ass after that? The hassle of not having a history file every day is a much bigger cost than having it on an already pwned machine, isn't it? Stop being an ass, that's why most people don't listen to security experts, instead of educating people in a kind way and making the world more secure most of you like to live on your high ivory towers with snark comments, passive-aggressiveness doesn't help anyone or any discourse. Please, learn some social skills.
- orf 10y ago
  If your on a production server with the ability to read and act on the data in a users .bash_history you have far far bigger problems.
  - Sean1708 10y ago
    Well you don't, the user does.
- freehunter 10y ago
  As a blue team guy, either I'd catch you before you got that far or I wouldn't catch you even after pivoting. Either way, it's not worth slowing down business for that chance. Sure, I might fail a pentest, but what I'm concerned with is protecting against actual real-world attacks without disrupting business operations. Protecting against a pentest just looks good on the pentester's checklist, what really matters is "did we get hacked?".
  - bitexploder 10y ago
    I am biased here, but that isn't really fair if the person performing the penetration test is any good. Speaking strictly of external/internal penetration tests here, an average penetration tester, the kind you are referencing, will smash around for a bit, find one path to domain admin / service accounts on your Unix-likes and call it a day. Write a report and say, "yeah, you got pwned". A good penetration tester will look around a bit with their elevated privileges and maybe find some other things and write those up too. A great penetration tester will own everything, document how they did it initially, use their elevated access to gain an advanced understanding of your environment, document this understanding, and find as many nooks and crannies as they can in their assessment time frame. They will document these issues realistically and label things like auditing and clearing bash_history as defense in depth. But the parent also has a point. These little things are accelerators on a pen test. No they aren't going to be the thing that gets you owned. To be fair I have seen plenty of pen testers that wield findings like this as a hammer making it seem very important while missing the forest (for the tree in front of them) so to speak. Also, the best question probably isn't "did we get hacked?" but "how badly are we hacked right now?", because you are certainly "hacked", just maybe not at a nuclear melt down level.
    - freehunter 10y ago
      Yeah, you stated my intent better than I did. Most pentesters I've worked with would show a bash history and say "look, you failed, fix these" and my client would get mad at me for not securing this even though this isn't what would get you hacked. It's like a home security company recommending you keep your cell phone in a locked safe at night instead of on your nightstand. Sure it's safer, but it's really inconvenient and a good home security system would notice the robber kick down your door before your phone even gets stolen. The idea of any security system should be to compliment normal business operations, not to hinder them.
- hedora 10y ago
  This sort of thinking is why ssh known_hosts is hashed by default, breaking tab complete for ssh. I really wish it weren't, and a decent penetration tester will know what to do with the known hosts machine on a machine with IP 192.168.0.83 anyway (which is the common case for me), or can just feed it to one of those botnets that ssh's to every public IPv4 address on earth every 60 seconds or so. But, like password restrictions, the important thing is is inconveniences everyone, so it looks like the security team is doing something.

zsh history, from what I've seen a long time ago, can include timestamps, which is why I added a timestamp field in the schema, though it's currently unpopulated: https://github.com/jcsalterego/historian/blob/3bf7158b163d3febca4399a90dd8eb10dcce6611/hist#L38 https://github.com/jcsalterego/historian/blob/3bf7158b163d3f... #soon

ishigoemon 10y ago
Bash can as well, though I'm not certain if the OS X version is new enough. http://wiki.bash-hackers.org/syntax/shellvars#histtimeformat http://wiki.bash-hackers.org/syntax/shellvars#histtimeformat
TheGRS 10y ago
If you're an oh-my-zsh user there is a handy part of the .zshrc config for enabling and customizing the timestamp format. Dead simple.

sillysaurus3 10y ago

I like your zsh history too. Will you post all of it here unedited? Also, on pentests the ~/.bash_history file is literally the first thing we look at. It's lovely: in an instant, you know exactly which files on the system are important, why they're being used, and what the high-priority targets might be for pivoting to a different box. In some cases it cuts hours off the job. So to keep hackers happy, please don't delete your bash history on production servers.

viraptor 10y ago
It's just a delay. Are you really suggesting that making work harder on a daily basis is worth it to slow down by a few hours (not preventing!) lateral movement in an already exploited system? Because that's why users hate security restrictions.
- sillysaurus3 10y ago
  By all means, steam ahead. It's certainly your right as a developer not to be slowed down by pesky restrictions. The easiest marks were always the companies that had a culture of hating security restrictions.
  - arjie 10y ago
    Wait a minute. If you've owned my user, what's to stop you from setting the histfile even if I turned it off? Not to speak of how you can just listen to my pty. I mean, it's really clever talking like a mafia enforcer making vague threats but everyone here is treating you respectfully and you're not responding in kind. It's not cool, man. If you don't feel like engaging, don't.
  - brazzledazzle 10y ago
    I'm legitimately curious about their question so I'll phrase it differently: have you ever found something in the shell history that you wouldn't have discovered on your own? Is it more of a delay tactic or real deterrent?
    - bitexploder 10y ago
      I have done my share of internals. Some of the time you find valuable clues in administrative audit logs and bash_history. Clues that mean you make a good and impactful finding within the timeframe of your timebox. Reality is an attacker with this level of access is going to have more time than I will, but it still means a measurable impact to security because it decreased the time it took to find something. So in that sense the OP is correct, it comes down to a risk reward trade off and is it worth clearing the history to potentially buy yourself more time in the event you are owned. It isn't as black and white as "well, the server is owned, of course you have my bash_history, that is the least of my worries now..." it is, but it could also be the one thing that gives you 3 extra hours to detect and shut down an attack.
  - piva00 10y ago
    You have already pwned the machine, what disabling history is gonna do to save someone's ass after that? The hassle of not having a history file every day is a much bigger cost than having it on an already pwned machine, isn't it? Stop being an ass, that's why most people don't listen to security experts, instead of educating people in a kind way and making the world more secure most of you like to live on your high ivory towers with snark comments, passive-aggressiveness doesn't help anyone or any discourse. Please, learn some social skills.
orf 10y ago
If your on a production server with the ability to read and act on the data in a users .bash_history you have far far bigger problems.
- Sean1708 10y ago
  Well you don't, the user does.
freehunter 10y ago
As a blue team guy, either I'd catch you before you got that far or I wouldn't catch you even after pivoting. Either way, it's not worth slowing down business for that chance. Sure, I might fail a pentest, but what I'm concerned with is protecting against actual real-world attacks without disrupting business operations. Protecting against a pentest just looks good on the pentester's checklist, what really matters is "did we get hacked?".
- bitexploder 10y ago
  I am biased here, but that isn't really fair if the person performing the penetration test is any good. Speaking strictly of external/internal penetration tests here, an average penetration tester, the kind you are referencing, will smash around for a bit, find one path to domain admin / service accounts on your Unix-likes and call it a day. Write a report and say, "yeah, you got pwned". A good penetration tester will look around a bit with their elevated privileges and maybe find some other things and write those up too. A great penetration tester will own everything, document how they did it initially, use their elevated access to gain an advanced understanding of your environment, document this understanding, and find as many nooks and crannies as they can in their assessment time frame. They will document these issues realistically and label things like auditing and clearing bash_history as defense in depth. But the parent also has a point. These little things are accelerators on a pen test. No they aren't going to be the thing that gets you owned. To be fair I have seen plenty of pen testers that wield findings like this as a hammer making it seem very important while missing the forest (for the tree in front of them) so to speak. Also, the best question probably isn't "did we get hacked?" but "how badly are we hacked right now?", because you are certainly "hacked", just maybe not at a nuclear melt down level.
  - freehunter 10y ago
    Yeah, you stated my intent better than I did. Most pentesters I've worked with would show a bash history and say "look, you failed, fix these" and my client would get mad at me for not securing this even though this isn't what would get you hacked. It's like a home security company recommending you keep your cell phone in a locked safe at night instead of on your nightstand. Sure it's safer, but it's really inconvenient and a good home security system would notice the robber kick down your door before your phone even gets stolen. The idea of any security system should be to compliment normal business operations, not to hinder them.
hedora 10y ago
This sort of thinking is why ssh known_hosts is hashed by default, breaking tab complete for ssh. I really wish it weren't, and a decent penetration tester will know what to do with the known hosts machine on a machine with IP 192.168.0.83 anyway (which is the common case for me), or can just feed it to one of those botnets that ssh's to every public IPv4 address on earth every 60 seconds or so. But, like password restrictions, the important thing is is inconveniences everyone, so it looks like the security team is doing something.