I would like to start checking that the open source projects that I am using in my apps are what the developers released. I noticed that many projects have a SHA1 and MD5 digests presumably these can be easily tampered with for example if a hacker replaces the orginial zip file on a mirror they can also replace the .md5 and .sha1.
How can I check the integrity of third party open source libraries that I depend on?
I think , there is No trusted way for this, since the hacker may change the source files and its (md5 or sh1) files. He simply may replace the whole project with another one.
so , download the source from trusted sites such as sourceforg and code.google.com and codeproject and mirrors recommended by these sites.
typically an open source project, although open to all to download and modify themselves, the ability to actually change the uploaded files is restricted to certain individuals governed by the project owner.
A good example is https://github.com/thecodemine/formwizard, where you can see a read-only link, but cannot modify directly unless authorised.
However you can fork the project to your own account and modify as you wish, for example https://github.com/AlexKey/formwizard
I'm also guessig on large open source projects like linux distributions for example, even code / files uploaded by authorised individuals will also go through stringent reviews before official release.
A hacker of course on comprosising a system could change files at will, but this isn't a weakness of an opensource model but instead could be a problem for any project.
Also things like Code signing help detect unauthorised modification.
http://en.wikipedia.org/wiki/Code_signing
Code signing is the process of digitally signing executables and
scripts to confirm the software author and guarantee that the code has
not been altered or corrupted since it was signed by use of a
cryptographic hash.
You have not Googled your question. If you do so you'll get a lot of content about it. The link below will teach you how to check the integrity of a downloaded file.
https://help.ubuntu.com/community/HowToMD5SUM
You may also check the following link, which shows that it is very difficult to modify or replace the .md5 and .sh1 files.
Here's the link.
Related
Notepad++ acknowledged this DLL hijack vulnerability:
https://wikileaks.org/ciav7p1/cms/page_26968090.html
I don't get from the description how it works. As a Notepad++ user I am concerned and as a developer myself I am curious too.
There is a general DLL hijack explanation here - What is dll hijacking?. A bit too general.
Does it mean that to effectively exploit this vulnerability the attacker has to first have control over my PC, using a different vector of attack, to plant a malicious version SciLexer.dll (?) into DLL search path?
If the attacker have already such power over my PC why he would bother with Notepad++. Why not to go after more core libraries or even system ones?
I also don't get implications of this remark in the WikiLeak text: For the life of me, I couldn't get this function [Scintilla_DirectFunction(..)] to be called. If this is the only exported function in that DLL, the only one called by Notepad core, how come that is is not called? That would mean also that malicious code would not be called either.
Was hacked SciLexer.dll ever actually detected, hacked by CIA or anyone else, or it is only a discovered possibility?
Also Notepad++ team in the latest release 7.3.3, in release notes claims that they "Fix CIA Hacking Notepad++ issue". Any ideas how they could do it?
A DLL hijacking attack is simple: Consider your download directory that contains many files.
If someone manages to make you download the manipulated SciLexer.dll dll it will be most likely be downloaded into your download directory. You don't do anything with the file after download, the file just remains where it has been downloaded.
Later you download a txt file from somewhere on the net and this file is also placed in the download directory.
If you now open the explorer and double click the downloaded txt file the current directory is the download directory. The dll hijack vulnerable Notepad++ version would then search for the SciLexer.dll file to be loaded in the current directory (which is now the download directory). Therefore Notepad++ would load the manipulated SciLexer.dll that you downloaded previously.
Regarding the fix you can look at the source code changes that fixes the bug.
It seems like the Nodepad++ team changed the way this dll is loaded and additionally they added a certificate check of the SciLexer.dll.
Sometimes I see a list of keys along with a download that I believe are meant to verify if a downloaded file is legit. For example here
http://cdimage.ubuntu.com/releases/12.04/release/
There are SHA1 sums at the end of the download page.
I assume the process is, you download file, verify it using these sums. However, if someone hacked the page and installed a modified version of download files, wouldn't they change the SHA sums as well? Then what is the purpose of sharing the sums / keys along with downloads?
"That they can also be used to verify the integrity of the dl, check if your file wan't corrupted, and to verify authenticity of remote mirrors" are good enough for me.
I'm trying to find all of the (javascript) resources located on a specific site.
What would be a efficient way of finding them?
Everything I could think of is bruteforcing every possible name and check whether there's a file with this name at the server, although this isn't exactly that efficient.
Yes you can do this. The thing which you actually want to do is web directory traversal..
It is a kind of web vulnerability which is usually taken in to consideration by the web master so you get 403-Forbidden or 404-Not Found Error. Manual exploitation on this is surely possible with trial and error basis in case u get to know directory that contains .js files. For automation You can take use of Python/Perl for ease of use. I am personally working on a same project targeting the same objective using PHP and cURL. At very present I can not help about any source code but for sure I'll be posting same.
What are the best steps to take to prevent bugs and/or data loss in moving servers?
EDIT: Solved, but I should specify I mean in the typical shared hosting environment e.g. DreamHost or GoDaddy.
Bootstrap config is the smartest method (Newism has a free bootstrap config module). I think it works best on fresh installs myself, but ymmv.
If you've been given an existing EE system and need to move it, there are a few simple tools that can help:
REElocate: all the EE 2.x path and config options, in one place. Swap one URL for another in setup, check what's being set and push the button.
Greenery: Again, one module to rule them all. I've not used this but it's got a good rating.
So install, set permissions, move files and and DB, and then use either free module. If you find that not all the images or CSS instantly comes back online, check your template base paths (in template prefs) and permissions.
I'm also presuming you have access to the old DB. If not, and you can't add something simple like PHPMyAdmin to back it up, try:
Backup Pro(ish): A free backup module for files and db. Easy enough that you should introduce it to the site users (most never consider backups). All done through the EE CP. The zipped output can easily be moved to the new server.
The EE User Guide offers a reasonably extensive guide to Moving ExpressionEngine to Another Server and if you follow all of these steps then you will have everything you need to try again if any bugs or data loss occur.
Verify Server Compatibility
Synchronize Templates
Back-up Database and Files
Prepare the New Database
Copy Files and Folders
Verify File Permissions
Update database.php
Verify index.php and admin.php
Log In and Update Paths
Clear Caches
As suggested by Bitmanic, a dynamic config.php file helps with moving environments tremendously. Check out Leevi Graham's Config Bootstrap for a quick and simple solution. This is helpful for dev/staging/prod environments too!
I'd say the answer is the same as any other system -- export your entire database, and download all of your files (both system and anything uploaded by users - images, etc). Then, mirror this process by importing/uploading to the new server.
Before I run my export, I like to use the Deeploy Helper module to change all of my file paths in EE to the new server's settings.
Preventing data loss primarily revolves around the database and upload directories.
Does your website allow users to interact with the database? If so at some point you'll need to turn off EE to prevent DB changes. If not that you don't have too much to worry about as you can track and changes on the database end between the old and new servers.
Both Philip and Derek offer good advice for migrating EE. I've also found that having a bootstrap config file helps tremendously - especially since you can configure your file upload directories directly via config values now (as of EE2.4, I think).
For related information, please check out the answers to this similar Stack Overflow question.
The majority of our C# projects configuration is kept in *.ini files. Mainly these files hold
many sections affecting all aspects of programs behaviour. But besides of regular configuration data some of sections are vulnerable like db connection string or server password. We try to keep this sections in following forms:
[Database]
user=testuser
database=testdb
password=
But when developer is testing application he must fill the config in order to start application. It is quite common that some of the passwords are commited into version control.
Because these files are indispensable for application they cannot be included in .svnignore.
Probably what I'm looking for is some kind of script (maybe in powershell). That would scan all *.ini files and erase all passwords. The most interesting solution would be adding some external password storage that can be used both to encode and decode passwords in *.ini files.
I always push to store configuration template files in subversion, but not actual configuration files. So if the configuration file is "config.ini" then I'll check in a "config.ini.template" populated with non-working sample data.
Then to prevent multiple developers from checking in their individual "config.ini" files, I'll add the actual configation file name to the svn:ignore properties list.
This forces the developer to copy the file and modify it appropriately for their environment, but eases the work of that task by not forcing them to find out which fields need to be present. If you have the time, you can even embed comments into the template file to simplify the meanings of some of the configuration options.
At the top of the file, include the directions of how to configure the system using the template, which should read something like:
# *** CONFIGURATION TEMPLATE --- DO NOT MODIFY THIS FILE ***
# 1. Make a copy of this file in the same directory with the command "copy config.ini.template config.ini"
# 2. Edit the new copy and follow the rest of the instructions
#
# Change "this.system.hostname" to the hostname of this system
Hostname = this.system.hostname
# Set the answer "23" to "42"
Answer = 23
You get the idea....
If you have problems (or think you might have problems) with people checking in their configuration options over the config.ini.template file, then I'd recommend using "svn lock" on the template file. However, with the appropriate warning, I've never found it necessary.
I'll not answer your question and instead recommend a different approach, assuming it's not too late to change the relevant design.
You should not store passwords in the same files as the rest. Have the application read a dedicated password file (or retrieve the password from a password storage service) in addition to the regular configuration file. This is not just about not storing passwords in svn, but also about not having passwords exposed to shoulder surfing, accidentally mailed or posted when someone asks for help with a non-working configuration, etc.