1

Edited: Never mind the MinGW or .bash_history, I can see that is unlikely. Somebody attacking me and those bytes ending up in the frequently used file .bash_history by accident is not that unlikely however. Is there anything legit that would look like this? The only thing I could think of apart from a NOP sled with canaries would be parts of a picture, but the fragment does not look like anything in an image editor. It also seems unlikely that somebody would paint a picture with mostly a #909090 gray

I do programming but nothing security related, and don't run any servers on my computer. I'm thinking the .bash_history might have been corrupted by the system when I had to do a CHKDSK /F a few days ago. But simply having had those exploit-looking bytes anywhere on my computer makes me nervous.

I use MinGW for compiling unixy stuff under Windows and to have unixy shell commands available. I often grep .bash_history to remember what parameters for various commands I have previously used. (Don't ask why I don't use the built in bash functions for this, just a habit)

I recently found in my ~/.bash_history a long run of binary bytes which consists mostly of 0x90 - NOP. In this are shorter runs of other binary bytes which assembles into mostly valid instructions.

A recurring run is 82 20 f8 7d 2c 61 0a de 90 90 90 [then 90... repeated]

Online Disassembler says

82      (bad)
20f8    and al,bh
7d2c    jge $+2c
61      (bad)
0ade    or bl,dh
90      nop
90      nop
90      nop
90      nop
90      nop
90...   nop... repeated

Could this be part of a buffer overrun attack, with the NOP sled? Don't know much about this kind of stuff, and can't see how these particular instructions could do anything or how they would be executed. But I also can't see how they ended up in my .bash_history or what else would produce data like this. I have reason to believe that only part of the data was "captured" by .bash_history so more obvious malicious code might have been left out and only the potential NOP sled remained.

They are repeated over and over with ~850 NOPs in between.

What do you guys think? If this is not the right forum, do you have any suggestions on where I should be posting?

André Borie
  • 12,706
  • 3
  • 39
  • 76
Jonathan J. Bloggs
  • 31
  • 2

1 Answers1

1

NOPs are just padding. Your best bet is to perform a file analysis, or behavioral analysis (what does it call, what files does it load, etc) of the binary if you are that concerned. You could search the md5/sha1 checksums on sites like Virustotal, ThreatConnect, ThreatCrowd, etc. Since you mentioned you are compiling into Windows, my guess is, the NOPs are just used as padding in order to function under Windows. Again, to be on the safe side, upload it to Anubis, Virustotal before you waste time, if something extreme has been seen (open source translates to potentially thousands of downloads) someone has uploaded the file for strangeness

munkeyoto
  • 8,682
  • 16
  • 31
  • Yes, but NOP padding is very common in overflow attacks, aren't they? I did google before posting, but came up empty handed. The binary was not a binary file but binary data in the middle of my .bash_history. My thinking was that perhaps this was a novel attack, exploiting some shell command or daemon that reads this file. – Jonathan J. Bloggs May 14 '16 at 16:55
  • So what (NOPs are common in attacks.) Let's "weaponize" this: "I as an attacker do something that disaffects your bash_history file (for whatever reason). Are you going to... execute bash history? No. So what do I gain from this? If you're *that* concerned add timestamps to your bash history (export HISTTIMEFORMAT="%h/%d - %H:%M:%S ") then correlate them to logins, access, logs. The likelihood an attacker did something is very low here. Without knowing what applications were run before or after this appeared is too broad for anyone to answer effectively – munkeyoto May 14 '16 at 18:52
  • Say there is a common daemon that reads .bash_history to, I don't know, remove duplicates, whatever. And that daemon has a buffer overrun vulnerability. Or, since this is MinGW, how about the Windows search indexing service. Now, a black hat has commit rights to some innocent looking part of a large code base. Somehow he can put stuff into .bash_history. That would be an attack vector. Perhaps it is unlikely, but can you explain how that code and those NOP runs ended up in my .bash_history? – Jonathan J. Bloggs May 14 '16 at 19:41
  • @JonathanJ.Bloggs i know nothing about your system, what it does, who uses it, so I will not even attempt to answer "how NOPs" ended up in bash_history. There are so many other attack vectors against Windows I can't even see a threat actor saying: "I think I'm gonna make an exploit for CyGWIN bash!!! Because N amount of people use it!!!" Attackers tend to focus on "exploits to scale" meaning, if I am investing time in "breaking something" I want it to have the maximum impact. How many Windows systems you audit have cygwin installed? – munkeyoto May 14 '16 at 21:29
  • bash and the windows indexer are both pretty common and there has been attacks against at least generic bash (shellshock) that affected Cygwin equally. I'm not suggesting there is an actual vulnerability affecting MinGW .bash_history, I was just asking what you guys thought of the NOP sled. Don't take it so literally, use your imagination. In any case, if I was being targetted personally, the attacker would not care about scalability but only about what works to attack my machine. I am not a security professional so a script kiddie with metasploit would likely have a field day. – Jonathan J. Bloggs May 15 '16 at 18:43