It didn’t make all that much sense to me. Why did the team write their own bug tracking application when they could have either purchased one or used an open source solution. I guess the team felt that only they were creative enough to create a good bug tracking application.
Not created here
I never really liked the application, not because it had a tendency to slow down the process but actually because of the poor usability of the application. I am not certain where all of the textual comments were stored but the developers simply stored all attachments as files on a samba file system that was also shared. Just to keep up security or secrecy all of the files had the attribute of hidden and and read only.
I knew how the attachments were saved as did my IT colleagues also knew how the files were saved. If you wanted to retrieve the attachments it was actually more convenient to access the files directly.
During the beginning of the project there was a lot of external consultants and a number of there were also aware of this little back door.
No good deed goes unpunished
Once the project was finished everybody left but a few years later a few of them came back including John who is now an auditor. I was speaking with my colleague Kenny when I found out that John had been in touch and was asking about how we used to access these files. Kenny is a nice guy and reminded John exactly where the files were located. Kenny being an inquisitive guy asked why exactly did John need this information. The answer was too cute.
I am writing a report about weaknesses of the systems here
This is a weakness that none of the average user would ever have been able to find or to utilize. I put this story out of my memory because up until very recently Windows Explorer would display which files existed even the hidden ones. A few key presses and you could even search for the hidden attachments.
This was a nice little backdoor but you can always use the application right? Nope, some big brain wrote the application front end using MS Access about a decade ago and for some reason they couldn’t get it to work using Access 2013. I am in another group so it isn’t clear what my old group is now doing but they are still creating these hidden files.
I needed a file and could not use the application nor windows explorer.
Security in obscurity
The problem is that Windows itself is plenty willing to tell you which files exist if you ask correctly.
The simple command prompt, cmd.exe, will blab either overtly or covertly what it finds.
| Name | Description |
|---|---|
| dir | This will do the directory listing of the normal files but when you give the /ah parameter will will display the files with the hidden attribute. |
| attrib | I believe that this program has its roots in the DOS operating system that windows was built on top of. This command will show all the files in the current directory and what attributes are set (archived, read only, system or hidden) |
These are actually pretty direct but I was surprised that simply pressing the tab key in my command would display each file in the directory including those that were hidden.
I supposed that you could simply use the dir command to display all files that were hidden but it is possible to make our own command to display all the files regardless of their hidden status. this is done using a few lines of powershell script.
All you need to do is to have the following line as a power shell script.
myfind.ps1 Get-ChildItem . -recurse -force
This will display all files in the current directory as well as all files in any subdirectories. This is a neat little trick considering the files must be hidden for a particular reason but it is very easy to find the files anyway.
powershell -file myfind.ps1
Showing everything was actually the entire purpose of this script but it is also possible to filter this list of files down to only the hidden files.
myfind2.ps1
Get-ChildItem . -recurse -force | where-object {$_.mode -match "h" }
This script actually will find the hidden files that are in the current working directory as well as in any subdirectories. This isn’t so helpful as it only lists those files but it is possible to take this to the next step and copy those files elsewhere.
myfind3.ps1
get-ChildItem c:\mysourcedir -filter *.* -force | where {($_.extension -eq ".txt" -or $_.extension -eq ".text")} | Where-Object {$_.mode -match "h"} | copy-item -destination c:\mydestinationdir
The only problem for this tiny script is that the files are copied but they retain their hidden attribute. I am fairly certain that you can remove this attribute with some more clever powershell code but I couldn’t find it.
In the end I reached out to DOS history to clear this hidden attribute. The good news is that powershell scripts can call other programs in addition to these cmdlets. My final script copied these files and then used the DOS command “attrib” to do the clear.
myfind4.ps1
get-ChildItem c:\mysourcedir -filter *.* -force | where {($_.extension -eq ".txt" -or $_.extension -eq ".text")} | Where-Object {$_.mode -match "h"} | copy-item -destination c:\mydestinationdir
attrib -h c:\mydestinationdir\*.*
Not so secret after all
I actually realized that part of the reason I cannot see these hidden files in the windows explorer is because I have a new computer and have forgotten to change my computer settings to display hidden files.
https://www.lifewire.com/how-to-show-hide-hidden-files-and-folders-in-windows-2626085
With these changes back in place you can even search for files hidden or not using the windows explorer tool.
All of this points to the fact that you cannot use windows hidden files as any real security measure and security in obscurity may work for a while but eventually someone with time on their hands will find all your hidden gems.
