How do open-source projects prevent disclosing a bug while fixing it? I understand that many open-source projects request vulnerabilities not to be disclosed on their public bug tracker but rather by privately contacting the project's security team, to prevent disclosing the bug before a fix is available. That makes perfect sense.
However, since the code repository of many open-source projects is public, won't fixing the bug in the source code immediately disclose it?
What measures (if any) are taken by open-source projects (e.g. the Linux kernel) to ensure that fixes for security vulnerabilities can be deployed to the end user (e.g. a Samsung Android phone) before the vulnerability is disclosed?

They don't. By releasing code, they automatically "disclose" the issue to those who can reverse engineer the patch. But they can delay explaining or providing the details for easy consumption.
If they delay releasing the code, they force users to use known-vulnerable code.
If they release the code and do not announce it as a security fix, then users might not patch and end up running known-vulnerable code.
So, they fix the code, release it, announce a security fix so that people assign the appropriate urgency, but they can delay explaining all the details to make it a little harder for attackers to figure out how to exploit the vulnerability.
Is that effective?
To some degree, "security by obscurity" has a place in a strategy in order to buy some time. Since it costs nothing, and it can have some positive effect, it seems like an easy call to make.


Find accounts that belong to an e-mail address I would like to delete an old e-mail address of mine. However, I'm not exactly sure on which (popular or obscure) sites I signed up for an account using that address.

If I delete the address, someone else could register the same address (after a few month waiting period). Given the name, this is not unlikely. The new owner could then sign up for an account on some site and if they find the address is already in use, they would reset the password and get into my old account.

Is there any software tool that could help me verify which accounts are associated with the address? For example, by triggering the password reset on lots of popular (and probably less popular) sites automatically?

Short answer is, not really ... and if you think about it, its actually a good thing most of the time.  Can you imagine going for a job interview and being asked why you registered for an "adult" site, or a site that promotes piracy back when you where in school ... and whether or not this makes you a fundamentally decent person today?

However, most sites you sign up for should have a double opt-in ... one on the page, and a verification via email.  In this case you should have a record of it in your old email (if you didn't delete it).

Also, if you signed up for a site and you adhere to a good password strategy ... you may be able to check your browsers saved passwords for a list of accounts associated with a given email address.


arpspoof on corporate network I've just been learning some things about arp poisoning and would be tempted to use it on colleagues to inject some javascript alerts into their pages when they aren't working to freak them out - but was wondering if my virtual machine / arp spoof packets could be picked up / linked back to my host machine by site security?

Yes they can. Of course it depends on conditions like:

How are the ethernet switches configured
Is there any logging enabled

Also on non-technical conditions like what happens after they freak out:

You don't say a thing they report it to IT and an investigation starts (and they might look at everyone's browsing history, looking for "arp spoofing")
You tell them it was a prank and they report it to HR

In the end the main question you should ask yourself is: would this violate company policies, and if so is it a firing offense? followed shortly by is it worth?

How about setting up a private network on your home computer and playing in a safe environment.


Is there a benefit to Diffie-Hellman parameter rotation? When setting up a web server with TLS support I've generated my dhparams with openssl dhparam -C 2048 some.pem. I understand that the output in some.pem are the parameters by which DH key exchange will be done and that they are by nature public values. With empirical testing it seems that I can rotate the dh parameters without clients programs complaining, but a few questions arise that I can't find answers to.

If I rotate the parameters with some cadence is there any benefit to doing so?
Is there any downside to rotation? ie could an attacker more easily masquerade as my web server?

Naively it seems that rotation of parameters would marginally increase security in the event that one particular set of parameters is compromised, but this seems unlikely. Does anyone have input on this?

Naively it seems that rotation of parameters would marginally increase security in the event that one particular set of parameters is compromised, but this seems unlikely. Does anyone have input on this?

This is correct. Rotating parameters protects from  precomputation attacks against Diffie-Hellman. Any individual DH group can be subject to an extremely intensive precomputation after which each individual key agreement step can be broken very rapidly (sometimes even in real time).

The biggest danger is in using small, popular groups which various government agencies have very likely managed to attack, judging by analysis of the Snowden leaks. Generating your own group, even if you do it just once, is sufficient to protect against all but the most serious cryptanalysis efforts.

Of course, the best solution is to just use a large group (at least 3072 bits) and call it a day.


using VLAN to mitigate ARP poisoning hi I have been told VLANs can help mitigate ARP poisoning because they can be configured with different broadcast domains. and arp works using a simple broadcast domain. can someone explain how the VLAN achieves this ?

When you configure a VLAN on a local network it's as if you have differents locals networks between your hosts.
So if you sniff the traffic on a particular VLAN you will see only the hosts which are conected on this VLAN and not the others hosts of your network. On the switch which manage VLAN you will have a ARP table per VLAN.

Moreover, you can use the privates VLANs to improve your local security.


BCrypt hash as database table ID In my web application I have to store hashed values (using BCrypt) as ID for a database table.
The input for each hash value is a unique string.
I am concerned about possible collisions.
1) What is a chance to have collision (which will cause DB exception, while inserting new row with generated collided id)?
2) What are the means to prevent it?

Please do not advise, that hashed values can't be used as IDs.
However I'm not stick to BCrypt solely (alternative is ok).
The main task is to have unique secure hash values.

If you're using bcrypt, then in addition to the plaintext/password you're hashing, bcrypt requires a salt and a work factor. I'm assuming you're keeping the work factor constant, but you didn't say about the salt.

Generally, the collision probability of a good hash function depends on the size of the hash's output. The birthday paradox makes collisions much more frequent than your intuition allows for; a (very rough) approximation is to take the square root of the number of possible outputs (call the result n) and assume that you'll see a collision after hashing n inputs.

So, if you kept the salt constant, you'd get 184 bits of output space, translating to about 1 collision in 292 hashed inputs. If you used a random salt on every input, you'd have an additional 128 bits of output space, further improving collision resistance.

Note that these are probabilities, not guarantees. So you might produce your first collision much earlier than expected, even though it's unlikely. Still, you should probably plan for collisions. If you actually produced a collision, you could change the salt and try again until you went collision-free; that's simple enough to not complicate your code much.

This article gives you the math behind calculating hash collision probabilities.


Is certificate pinning enough to protect client (native mobile app) - server communication? My use case is the following: I want to create an app with React Native that I can deploy on both iOS and Android.
The app should consume an RSS feed (https call) from the server but there is no need to have authorization in place. The output does not depends on the user.
I was trying to look around for ways to have some form of security for my server to be sure that the caller is my mobile app.
For this use case, is it certificate pinning enough or do I need something else in your opinion?

The app should consume an RSS feed (https call) from the server but there is no need to have authorization in place. The output does not depends on the user.

In this case I'd consider the need for an app at all... But that's not important.

I was trying to look around for ways to have some form of security for my server to be sure that the caller is my mobile app.

No, it would not be. It would make it more difficult to discover the endpoints used by your app, but still trivially doable. Replacing the certificate and rebuilding an APK is rather trivial - and it's enough that one person does it.
You can use Safetynet attestation or Devicecheck for IOS to verify that the device is not compromised, and verify your app integrity. Note that this is not foolproof either, but it raises difficulty somewhat.
Ultimately, your problem is unsolveable. The moment the data leaves your server, you have no control over how it's used anymore. You can make it somewhat difficult, but it can be broken. Hollywood has spent the last 20 years trying to implement DRM - but name a movie released in the same time span that has not been pirated...


What is a Cinderella attack I've read online that it is a time-based attack, but not much other information was given. Can someone explain the definition of a Cinderella attack to me?

Cinderella attack: A cyber-attack that disables security software by manipulating the network internal clock time so a security software license expires prematurely rendering the target network vulnerable to cyber-attack.

Extracted from the book: Cybersecurity Lexicon


How does ProcessBuilder avoid OS command injection? while I understand that OS command injection needs to have the untrusted input to be validated, I see that people have been suggesting to use ProcessBuilder(...).start() over Runtime.getRuntime().exec(..); is this because ProcessBuilder does not take command to be executed as a single string?

I overcame this vulnerability by using ESAPI's executeSystemCommand method which internally seems to be using ProcessorBuilder after validating the input though.


Banking platform accepts password containing subset of real password How would it be possible that if my password was 123abc that my bank also accepts something like 123abc12?

Isn't that an extreme security flaw? If the password was hashed and salted, wouldn't the latter create a completely different digest?

This does not mean that your bank is storing your passwords in a plaintext format. The bank could simply be truncating the input password to a certain length before hashing it.

It is a security flaw as there is no good reason to artificially limit the length of passwords, but it might not be as bad storing passwords in plaintext. I would write to them and demand an explanation of why they are doing this.


Does SFTP cost more to implement than FTP? This is a two part question.

How does the implementation of SFTP differ over FTP? (Account Creation, Setup of connection)
Is it more expensive (in terms of time/cost) to do so?

In this scenario I am using user credentials for authentication.

SFTP is a completely different setup than FTP.
SFTP is a FTP over a SSH tunnel, usually using the sftp-server thats part of openSSH.

You set this sftp-server up like any other SSH connection:

you create a (system) user
add a clients public key to the [user]/.ssh/authorized_keys file
have the client connect to your ssh server using a SFTP application (sftp, scp, winscp, etc.)

Now if you mean FTPS instead of SFTP, than you have a FTP connection with TLS security. This is  (i.m.h.o) a pain to setup and use. you have to get a certificate, setup a FTPS server (I know of no secure one I would run myself) Setup users, setup permissions, setup storage location. Just like with plain FTP.


How To Stop A Mobile Verification Attack I am thinking of using mobile phone number verification for the sign up step in my web application but how do I prevent a hacker or a malicious user from sending mobile verification requests to an unlimited number of phones? It would cause damage in a number of ways. It would consume my SMS package, thus costing me money plus preventing sign up of legitimate users. It would also cause inconvenience to those who would receive these text messages.

I thought of IP blocking but I think that would not stop a distributed attack and it would block legitimate users from that IP. I thought of using a CAPTCHA but that is not very convenient for mobile users and even though it will slow down the attack by a ratio, it will not be enough to completely prevent it.

How do websites like Facebook, Google, Microsoft etc. deal with this?

Something that you might consider is a cool down period for an IP after it requested the SMS verification. This would not solve a distributed attack as indicated in the question but would to a large extent limit the effect of a single origin attack. The effectiveness of a  distributed attack would also be reduced to some extent.

Although this might not be the best or final solution to your problem it is something to consider as an additional layer of your security.


Security of Wi-Fi vs Bluetooth I am preparing a project for a client. It is a wireless device to be used inside a factory so the workers can interact with the factory without having to go to a terminal. In order to connect the device to the system easily I see two main possibilities: Bluetooth or Wi-Fi.

The client prefers to use bluetooth because it claims that it is safer, but I believe that it is quite the oposite (plus, it is much easier for me to use Wi-Fi).

The network to use will be al new, so I have complete control over what tecnology/protocols to use.

So what is safer, Bluetooth or Wi-Fi? How can I show it to the client?

Wifi hacking has more scene. So maybe this is because your client thinks is safer... but it is not. Anything can be hacked if you don't take the appropiate security measures. Both of them can be victim of DoS too.

Advantages of using wifi

Higher range, so if the factory is large, less hardware will be needed to cover all, son less money I guess.
More compatible hardware.

Advantages of using bluetooth

I don't know! maybe they are less people focused on bluetooth hacking, so less tools.

Anyway, I think (personal opinion) A wifi network can be a good idea if you do well the configuration. Some standard security advices:

Disable WPS
Use WPA2 AES encryption, is the strongest of the standard available for now.
Use certificates or if not possible, use very long non-existing in dictionaries passwords using lowercase, uppercase, symbols and numbers.
Use if possible Radius instead of PSK (if possible).
Use "clients isolation" if possible. Only if not needed to connect from clients to clients.
Your wifi network should be in a different network subrange with port filtering to assure only accessing to the minimum required services.
If your money is ok, use hardware WIPS (wireless intrustion prevention systems) to try to prevent DoS. This is not usual, is not cheap.

With that standard security measures, you have a good wireless networks. Anyway, always everything can be hacked, you know :)

EDIT
Regarding the key exchange on wireless networks and on bluetooth...

Bluetooth security is limited to key matching. In wireless networks the security standards have been raised with inclusion of new versions from the old-easy-to-hack WEP until complex key exchanges or certificate validation like on EAP-TLS.

Some other opinions supporting this on this article.

So finally my opinion too is Wireless is more secure, or at least, has more security mechanisms.


Storage of account password on keychain iOS to enable TouchID login Currently in the middle of a rather long-winded process of deciding upon the use of TouchID within an application being developed due, to security concerns, and wondered if anyone had any advice?

The idea from a product point of view is that a user can register with the application with a username/password (bog-standard flow in case of fall back for devices with no touch id) and then at a later date, if turned on via in-app preferences, use the TouchID system to 'login' to the application instead of typing a username/password again.

My concern is that this somehow means we have to store something on the device (retrievable upon successful touch) which can then authenticate the user and allow them access to the API (via JWT token, but probably doesn't matter).

This goes against almost everything I have ever read and been involved in with regards to mobile application development, which is storing anything sensitive on the client device is opening yourself up to an attack vector.

Yet - many applications already do this, so I am wondering what a typical process for enabling such a feature would be?

The app is sensitive by nature, has some personal information management which would be bad if leaked, if this makes a difference to the approach!

Thank you in advance

Suppose you have an iOS app that accepts a username and passcode. This login information would be entered by the user, then you could store that state by saving the credentials in the Keychain, which is the only place secure enough to store that information on device.

If the above is already in place, than adding Touch ID only increases security because the iOS Touch ID API works by simply unlocking keychain items. So you would use the LocalAuthentication framework to ask for Touch ID authentication. This API would then present the UI on the screen, send the encrypted fingerprint data to the Secure Enclave, and send you back a result that simply specifies whether the match was successful or not, optionally unlocking the associated keychain item for the user's login item. At no time is your app given access to the fingerprint data, and if you need further authentication you can associate a keychain item that would be unlocked on success.


Cuckoo Sandbox - Unable to enable internet access via hostonly & iptables I'm having some issues with my deployment of the Cuckoo Sandbox.  I have been unable to enable internet access for the VM via the hostonlyif, vboxnet0 and IPtables rules.

Here are some details regarding my configuration:

Host - Ubuntu 16.04LTS;
Host - hostonlyif (vboxnet0) is 192.168.56.1;
Guest - WindowsXP SP3;
Guest IP - Static at 192.168.56.19;

I can ping from Guest to Host and vice versa successfully.  I am using the following IPtables commands, which are straight from the Cuckoo virtual networking documentation:

    iptables -A FORWARD -o eth0 -i vboxnet0 -s 192.168.56.0/24 -m conntrack --ctstate NEW -j ACCEPT
    iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
    iptables -A POSTROUTING -t nat -j MASQUERADE

I am using iptables-save and iptables-restore commands to ensure I can reapply the rules after reboot.

All the documentation says that this should work, however, I am still unable to connect to the internet.

I have added a second adaptor using the bridged mode and was able to access the internet just fine, although Cuckoo didn't seem to want to use it, even after I edited the configuration files.

Does anyone have a clue as to how I might resolve this issue?

The iptables should really work.

Some more ideas:

You should check if the guest is really configured to use 192.168.56.1 as a gateway.
You should check your overall forwarding settings in the kernel to see whether it is not disabled for your vboxnet0 interface or overall:

$ sysctl -a |grep -e '\.forwarding'


What can be done to prevent disruption of hardware in the event of a powerful solar flare? I'm under the impression that a sufficiently powerful solar flare can temporarily disrupt and even damage electronics.

Are there any practical approaches that one could take to minimize this disruption? In particular, what can be done to protect mission critical hardware which needs to remain running during the event?

Shielding can be used to some extent. A Faraday cage, an underground bunker... can do wonders. Usually, the power grid will suffer most from a solar flare, because it is all unshielded obsolete under-maintained hardware, stretched to the max and beyond by competing regulations and market forces, and more often than not plain incompetence. So you first defence against a solar flare is an UPS.

Ultimately, protection against solar flares is similar to protection against the EMP from a nuclear blast, which is discussed in this previous question. Solar flares have the special characteristic of hitting a whole hemisphere at a time (the "day" half of the Earth), so if you want to maintain critical infrastructure through redundancy, then you have to spread it all around the World, literally.

Even more ultimately, if the solar flare is big enough, then we are all dead, and the question becomes moot.


EU GDPR - Data protection requirement standards missing? I'm reading about the GDPR here and there. However, I see no requirements on how data actually is to be protected like

Mimimum password length requirements
Second factor authentication
Backup protection policies

and the like.

What about a data subject giving consent but ONLY if they guarantee a second factor will always be required, for example?

Can companies be sued for bad/not compliant protection (before a breach)?

In the GDPR regulation (Article 39, on page 7), it says

  Personal data should be processed in a manner that  ensures
  appropriate  security  and  confidentiality of  the  personal data,
  including for  preventing unauthorised access to or use of personal
  data and the equipment used for the processing.

So this is down to the controller. If the controller is not willing to learn and adapt security controls and mechanisms then they may fall short and could result in a breach. The reason why the regulation may not put how to protect the data is that every company is different and will require different security measures. It's also good to follow certifications like Cyber Essentials and ISO 27001 to ensure the correct security controls and procedures are in place.

I'm not too sure on the legal side of being sued, but I suppose if it's in a contract of work stating certain security measures are in place then they are at breach of the contract.


Does stack (UNIX x86, x86-64, ARM) grow up or down, buffer overflow tutorials wrong explained? when I read something about buffer overflows on the stack, the most or some tutorials show me examples about overwriting local variables (pointers) and then overwriting pointers in the global offset table. But in some tutorials the stack grows upwards and in some it grows downwards, why? Is the architecture of every system in every tutorial different, I mean little-endian or big-endian. In the article of the Phrack magazine, the stack grows upwards and in the book the art of exploitation also. And in this article it grows downwards. But the operating systems in both tutorials are UNIX systems, so why there is such a difference?. And on my android phone the stack grows upwards and on my Ubuntu Desktop it grows downwards. It irritates me :(

The direction of stack growth is hardware dependent.  On x86 architectures, it grows downward, but it may be different on other architectures.


Anyone using Asirra in production? Are there similar alternatives? The Asirra project is a Captcha alternative that shows you pictures of kittens and puppies to fend off bots and prove that the end user is a human.

Is anyone using Asirra (or something similar) in production?  What alternatives are you aware of?

http://research.microsoft.com/en-us/um/redmond/projects/asirra/installation.aspx

Although I'd like to use images other than kittens, I noticed that from a implementation standpoint it's  entirely managed though client side javascript.  I would think that this type of solution would be easily cracked with a manually invoked form.submit method.

Is this technique common in the Captcha world?  Is there a way to control the logic at the server side?

What are your thoughts on its implementation, alternatives, and how a more secure version could be made?

Not relating specifically to Asirra, but wrt CAPTCHA in general, I will elaborate on @Graham's point and direct you to the following links:

"Has reCaptcha been cracked / hacked / OCR'd / defeated / broken?" on SO
My answer to "Practical non-image based CAPTCHA approaches?" on SO
Presentation I gave on this topic at OWASP in 2008
Best idea yet (obligatory XKCD)
RSnake's opinion of another "new" type of CAPTCHA (but mostly still applies to Asirra)
Bruce Schneier, but mostly the comments

In case you're lazy here are the highlights...
The 3 general ways of breaking CAPTCHAs are:

Broken implementation (e.g. wrong configuration, wrong settings, static images, exposing the answer, etc) - but probably does not apply to Asirra, unless its configuration-dependant
Inherent reverse-computability - If you can build a program to blur something that is still readable, I can build one to unblur it. I.e OCR is pretty darn good, at least if the image is readable by a human.
Putting a human in the mix, either by:

CAPTCHA farms: paying someone small amount of money, there is a MARKET for this: I've seen advertised on Ebay packages of 1000 CAPTCHAs "solved" for 4$, with a matching reliability % SLA
CAPTCHA Proxies, e.g. you can access pr0n if you solve this CAPTCHA... or even make a game out of it.

To sum up (as I've often done on this topic):

  CAPTCHA tries to solve the wrong problem, and it does it badly: even if it worked perfectly, the problem is not "I want to identify who is a computer and who is a human and allow only humans to use my site however they want", but rather "I want to prevent misuse and flooding on my site".
  We shouldnt be trying to turing-test the users, we should be limiting what they could do.

Or even better:

  Authentication (or identification) is a poor replacement for authorization.


Are paravirtualized drivers a security risk? Below is a copy of my answer that I gave in some other thread (Would running VMs inside of VMs be a more secure way to study viruses, etc?) about a topic of security of nested virtualization. I would like to know whether my answer was right of wrong. I'd like to know whether paravirtualized drivers are actually a security risk and whether SELinux (as sVirt) can do anything about it.

Me: (this was in mid-2012, before good support for nested virtualization)

  You can run VM inside a VM, but you probably won't be able to use
  hardware virtualization. It should still work thought, but you will
  probably have to use different hypervisors (example: VirtualBox for
  first VM, VMware for second). I think this is unnecessary and
  insecure. RHEL and Fedora (and maybe others) have built-in support for
  running KVM and using SElinux to restrict the VM process on the host.
  SElinux provides ample protection, but not against paravirtualized
  driver vulnerabilities. For maximum security, do not use
  paravirtualized drivers.

X:

  not in citation given - nothing I could find suggests that SELinux is
  ineffective when paravirtualized drivers are in use on KVM, and a
  quick Google search didn't turn up anything either. Do you have a
  source for this?

More than 2 years have passed

Me:

  I think the last part was my own idea and there is no other source.
  IMO, paravirtualized drivers are not subject to SELinux security
  controls because SELinux controls userspace processes, files, etc. I
  think paravirtualized drivers work by direct communication between
  guest kernel and hypervisor, which results in superior performance,
  but expose a part of hypervisor to the guest, that would otherwise be
  unreachable. I have no evidence for this, so I could be completely
  wrong.

Paravirtualized drivers will be a security risk only if the paravirtualization interface is designed in a way to leak hypervisor state or information to the guest. it is no more secure or insecure than having system calls in an OS or having applications talking to device drivers. If you think about it, guest talking to a hypervisor is similar to an application talking to the kernel.
The more entry points you add into the hypervisor, the larger your attack surface and the less secure.


How to encrypt more than 16 bytes using AES? I am trying to implement AES on an image of size 256x256 (65536 bytes) but AES works on 4x4 size of image (16 bytes).

What should I do? Can it be implemented or not? And if yes, then how?

AES is a block cipher, it works on 16-byte (128-bit) blocks. AES, on its own, can't work with data smaller or bigger than 16 bytes. Smaller data needs to be padded until they're 16 bytes, and larger data needs to be split into 16-byte blocks (and, of course, padded when needed*)

Luckily, there are algorithms that help you achieve just that (work on data larger than the cipher's block size), they're called block cipher modes of operation. They describe how the process of encryption and decryption using the block cipher should be.

Important: If you're writing your own implementation of AES to encrypt actual data for personal and/or professional use, then STOP NOW! Instead, use well-vetted, time-tested, and famous libraries for that. However, if you're doing that for educational purposes, go ahead, have fun.

If you want to use AES for confidentiality (i.e. to keep the image secret), use any of the modes offered by your library, except ECB which is not secure. If you also want to protect the image's integrity (i.e. to detect if it's been modified), use an authenticated encryption mode.

* There's more to padding than just the need to get to the block size, but I won't get into that. Read more about it if you're interested.


Is it safer to send cookies in headers than the URL? I have a browser extension. I would like to use this browser extension to send the cookie from site A to site B. I’m doing this because I want to scrape site A from site B, but this is obviously a use case browsers specifically designed against so I’m not sure how to handle it.
It doesn’t seem like I can use the normal cookie methods because of how my authentication is set up. I’m wondering: is it any riskier to do GET foo.com/?cookie=bar vs. GET foo.com header(cookie=bar)? I'm using HTTPS.

Putting an auth cookie value in the URL is a bad practice because it can be retrieved in the following locations (whether or not your are using https):

Referer Header
Web Logs
Shared Systems
Browser History
Browser Cache
Shoulder Surfing

So there is more risk that a third party impersonate the user session.
You should consult the OWASP about this case : https://owasp.org/www-community/vulnerabilities/Information_exposure_through_query_strings_in_url


Permissive CORS - Arbitrary Origin Trust, Remedial Action? I was completing an assessment for a client and discovered that web application implemented a Permissive CORS policy which allowed for a Arbitrary Origin Trust.
Request:
Host: [REDACTED]
User-agent: blah
Accept: */*
Accept Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Origin: https://arbitrary-domain.com
Connection: close
Content-Length:  16

Server Response:
Content-Type: application/json; charset=utf-8
Vary: Origin
Server: [REDACTED]
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://arbitrary-domain.com
X-Powered-By: [REDACTED]
Date: [REDACTED]
Connection Close
Content-Length: 6295

{JSON Content}

It was also discovered that the CORS Policy was configured using wildcards such as (*), meaning that any domain can access resources on this site. Shortly after this, I was able to exploit the issue and compromise sensitive information.
Researching fixes for this issue aren't very clear, or that I simply don't understand the remedial action suggested. I also see a lot of remedial action aimed at CSRF but not for CORS, so I am a little stuck on this. Exploiting this vulnerability appears to be a lot easier than fixing it.
My question is, what would the suggested remedial action be for this vulnerability? Is there a configuration that can be applied to IIS? What would one do to remediate this issue? As this vulnerability is pretty serious.
Any advice would be highly appreciated, thanks!
EDIT: I understand there is a whitelist approach to fix this issue but the ambiguity comes in where this whitelist is configured. Is there a configuration file that needs to configured on the host?

Thanks to Soufiane I was able to find the answer, links are provided below:
https://www.moesif.com/blog/technical/cors/Authoritative-Guide-to-CORS-Cross-Origin-Resource-Sharing-for-REST-APIs/
https://stackoverflow.com/questions/12458444/enabling-cross-origin-resource-sharing-on-iis7
Here is other research I did and they also provide fixes for other server variants such as Apache, Nginx and so forth.
https://stackoverflow.com/questions/1653308/access-control-allow-origin-multiple-origin-domains
https://stackoverflow.com/questions/24795268/how-to-allow-multiple-origin-domains-by-access-control-allow-origin-in-web-confi


Did DARPA's Cyber Grand Challenge winner actually discover previously unknown vulnerabilities? DARPA announced a winner on August 4, 2016 of its Cyber Grand Challenge DARPA Cyber Grand Challenge. The contest was described as

  designed to accelerate the development of advanced, autonomous systems that can detect, evaluate, and patch software vulnerabilities before adversaries have a chance to exploit them. The seven competing teams in today’s final event were composed of whitehat hackers, academics, and private sector cyber systems experts.

They described the actual challenge as:

  For almost 10 hours, competitors played the classic cybersecurity exercise of Capture the Flag in a specially created computer testbed laden with an array of bugs hidden inside custom, never-before-analyzed software. The machines were challenged to find and patch within seconds—not the usual months—flawed code that was vulnerable to being hacked, and find their opponents’ weaknesses before the defending systems did.

The winning system, Mayhem, was to be formally invited to participate in the DEF CON Capture the Flag competion, "marking the first time a machine will be allowed to play in that historically all human tournament."

I read and re-read the material at DARPA and I still can't believe that an automated system found anything on the level of the April 2014 Heartbleed bug. I am wondering if the vulnerabilities were more on the level of published Microsoft security notices or recommended updates or the like (in other words, the "bug finder" more of an automatic patch installer basically).

Does anyone know what was the technical level of the DARPA challenge test bed in relation to Heartbleed or similar actual vulnerabilities? I guess I will find out when Mayhem actually competes against humans in the CTF competition, but I am doubtful at the moment.

The DARPA test bed, CGC (Cyber Grand Challenge), was a modified Linux platfrom (DECREE). Its binaries (the compiled machined code for the system) contained only 7 system calls (e.g., terminate, receive, fdwait, allocate, etc.). Within the system code as a whole were DARPA crafted Challenge Binaries (CB) with one or more vulnerabilities to fuzzing, i.e., vulnerable to input of some character.

One of the early examples of fuzz testing was Steve Capps' "Monkey" to test for bugs in MacPaint by feeding random events to the code. "Monkey" alludes to "a thousand monkeys at a thousand typewriters will eventually type out the entire works of Shakespeare," i.e., if you send enough random or protocol crafted input to a program eventually you will find a way to crash it. Fuzz testing will typically not find security threats that do not cause program crashes, e.g., spyware, many viruses, worms, Trojans, and keyloggers. However, it will find exploits based on unexpected program input (or code errors related to program input), so may have been able to find the Heartbleed bug, which was a bug caused by improper input validation in the implementation of the TLS (Transport Layer Security) protocol (in OpenSSL).

The winning team, Mayhem, used a symbolic executor (Mayhem) in conjunction with a directed fuzzer (Murphy). A symbolic executor is familiar to those of you having worked with symbolic debuggers in integrated development environments, i.e., it is basically an interpretor that steps through the code and allows the assignment and tracking of symbolic values for inputs at various portions of the executing code. In other words, the Mayhem team was able to statically analyze portions of the CBs (Challenge Binaries) with Mayhem to detect (or analyze Murphy's suggestions) code vulnerabilities. This was a requirement of the DARPA challenge, i.e., to find a vulnerability and demonstrate it, i.e., POV (Proof of Vulnerability). Unfortunately, symbolic execution doesn't scale very well since the number of paths in a program grows exponentially and can go infinite with unbounded loop iterations, so heuristics or path-finding (enter Murphy fuzzer) to partially solve this path explosion problem (computing methods like parallelizing help also).

The DARPA CGC (the challenge) required the teams to not only locate vulnerabilities in the CBs (challenge binaries), but to document those with a POV (proof of vulnerability) and repair the vulnerability with a Repair Binary patch (RB). That patch would be tested for performance, both correct operation without the vulnerability as well as literal performance impact on the relevant code (execution time). This is all fairly amazing considering that a human was not allowed to contribute to any of what I just described.

You can read more at the blog of the winning Mayhem team here Unleashing Mayhem!, obtain DARPAs Grand Challenge rules and other documents here Darpa Grand Challenge related documents, read about fuzzing at Fuzz Testing and symbolic execution here Symbolic Execution.


Pseudo Random Generator is not initialized from the (entropy pool)? The RHEL5 manuals state that /dev/urandom will use the entropy pool until it's exhausted, and then it will resort to a fall-back pseudo-random algorithm, so that it will never block.

But when investigating the system, I've found that the pseudo-random generator (/dev/urandom) is initialised by /var/lib/random-seed as stated in the /etc/rc.sysinit start-up script.

But the /var/lib/random-seed itself gets its data from /dev/urandom o.O !! as stated in /etc/init.d/halt file script when entering runlevel 0 (shutdown) or runlevel 6 (reboot).

So /dev/urandom never uses the entropy pool?!

I am confused... any help would be appreciated please :)

/dev/urandom will always try and return the most random value it can.  In the worst case,  it will use cryptography to "stretch" the last bits of entropy in the pool to fill your request.  By contrast /dev/random will block until the entropy pool is full enough to fill the requested bytes,  so /dev/random will guarantee a more random value.  However /dev/random will block until the entropy store is large enough to fill the requested bytes,  which is unacceptable in almost all uses.  If the entropy pool is full,  then /dev/urandom and /dev/random are identical.

When rc.sysinit shuts down  it copies 512 bytes from /dev/urandom.   At this point its likely that the machine has been on for a while so the entropy pool has had a chance to fill.  There for this file is most likely a pure chunk of the entropy pool.   However if the entropy pool is not full,  its better to having something than nothing at all (Or even worse,  block until the entropy pool is full enough before shutting down).

On a Linux system it is very important that the entropy pool is populated during boot. To fill this need the shutdown action is to save the entropy pool to disk,  and the start-up is to re-load this entropy pool very early in the boot process. On a Linux system the ASLR'ed memory locations and TCP sequence values  are calculated with this entropy pool.   If the pool was flushed, then on each boot the memory space layout of daemon processes would not be very random and there for a process like your SMTP daemon could be exploited via a buffer overflow more easily.   This also affects your susceptibility to MITM attacks.  This is because it would be easier for an attacker to predict your TCP sequence values needed to complete the TCP 3-way handshake.

If you ever see a Linux distribution that doesn't restore isn't entropy pool at boot,  then its a vulnerability that need to be reported.

If you would like more information,  try reading the code comments in random.c


Can a HSM be used to make password hashing stronger? Say a database server has a HSM which is in use for encrypting (reversibly of course) credit card numbers. Is there any way a HSM could be used to add strength to a password hashing scheme? (Or are there any password hashing schemes that make use of a HSM to be more secure than pure software schemes)

You could, instead of hashes, use a MAC. That's a kind of hash function except that it uses a secret key, which is needed to recompute it. You would store the key in the HSM. The HSM would be needed to verify the password; if an attacker steals your database, he still cannot run a dictionary attack. This kind of scheme is sometimes called peppering and a HSM is the right way to use a pepper. To defeat such a system, the attacker would have to hijack the HSM and use it to "try passwords".


The level of security regarding a TeamViewer host deployment I'm a systems specialist in our organization and I've read a lot about TeamViewer security concerns over the last few years. Now I decided to come seek professional and objective opinions about the security of the following scenario:

TeamViewer Corporate license
TeamViewer account with a complex password and 2FA enabled
Full TeamViewer client for admin to give remote assistance (random password disabled)
TeamViewer custom host module with account assignment for the admin account (easy access/unattended access) enabled, so the deployment happens with the specific api token

On top of that there's a policy attached to the custom host module deployment that specifies the following things for every host:

Install all new updates automatically, enforced
Whitelist in use to allow connections only from the admin account, enforced
Prevent the unassignment of the assigned admin account in host modules, enforced
Any changes to host requires local admin password, enforced
Random password disabled on host modules, enforced

Does this setup look like it's secure enough to let those host modules run on computers so that the admin can take unattended access whenever needed? If not, please include reasons for it and/or tips and tricks to make it more secure.
Thank you!

In general with services, in your case Team Viewer, that you have security concerns about it because they communicate over non-trusted networks such as Internet, the approach that I follow is basically to tunnel the service from source with SSH. On the server side the service is only accessible from a trusted network and is not exposed to the Internet. On the client size, the user just need to make a ssh tunnel and use all the security that ssh brings you, and the configure your service to use the exposed port by Team Viewer.


Does TLS always use the same algorithms for both directions? Does TLS always use the same algorithms for both client to server and server to client communication or can they be different?

E.g. is it possible that the client uses AES256 to cipher the data before sending it, while the server employs RC4?

The cipher used is the same in both directions and thus the encryption algorithm is the same too. In detail: the client proposes some ciphers it is willing to use and the server picks one of these ciphers and sends it back to the client.


sqlmap cannot find a dispatched vulnerability I have a known sqli vulnerability that I'd like to try out with sqlmap in a web application; however, I don't believe sqlmap is able to figure this one out. Here's how the system works:

Inject on a given parameter, s, in Thread 1.
Thread 1 dispatches the information to a second thread.
Thread 1 returns an HTML message immediately always with a status of
"Pending"
Thread 2 now executes the sqli and writes a file to a location in the
web site I can look up. It also returns a Success message.

I cannot directly call the private method that Thread 2 executes, so I need to start with the dispatcher. However, I believe sqlmap can only find that this is a successful injection if it could read the outcome of thread 2. Does anyone have any idea how I could get sqlmap to understand this sequence?

This appears to be some type of what is known as Second Order SQL Injection.

Even if Thread 1 writes to a queue instead of to a DB, as the injection does not happen as a direct result of it, sqlmap cannot be used to exploit the vulnerability.

Sqlmap looks for error messages in responses or differences in timing (for blind SQL injection) to determine whether a page is vulnerable. Since these types of attack will usually be undetectable using these methods (unless it does alter the original page - but then you've got a latency issue), sqlmap would not be able to exploit it.


Telling the difference between a prepaid card and credit/debit card In order to stop people abusing free trials, we can make sure new users are not reusing data from existing users and therefore not just signing up with a new account every month.

It is reasonably simple to create an email alias, use a fake name etc, but getting a new credit card each month is tricky.

However, this could be done with prepaid credit cards - is there a way of identifying which cards are pre-paid and which are 'normal' when doing root-cause analysis?

can your payment provider help you?
some fraud services might be able to help you, such as https://www.maxmind.com/en/minfraud-services
buy a bin table of your own, but above-mentioned minFraud should do the trick, it has a per-transaction cost so depending on your volume option 2) or 3) might be more preferable
if you are doing 3d secure transactions, there's a hack: business cards & prepaid cards always return ECI 7, you can use an MPI service and avoid just those (skipping the rest of the authentication process if you don't need it)

Trick is, I am not 100% sure that official Visa/MC bin tables contain prepaid yes/no information or how up to date they are, if they don't then your payment provider, services such as minFraud or a BIN table you bought yourself might not do the trick 100% - so I hope 95% is good enough for you.

On the other hand, using an MPI to check for ECI 7 will result in some false positives (business cards, technical issues) and might not be 100% future proof or world-wide usable because it depends on Visa/MC rules that are out of your control, are time variant and geographically diverse.


Handling toxic data in a microservice architecture I'm trying to apply the principle that data is toxic asset in a system with many services through which this toxic asset must flow.

The system can be abstracted to 3 actors: clients, intermediaries, and (data) sources. Clients will eventually wish to view some sensitive data (think credit card numbers or PI info) that is housed in a secure data source. Intermediaries are the services in between the client and the source, and so must come into contact with this sensitive data, which is the whole problem.

For the purposes of this scheme, I want to assume that the client and the source are secure (not vulnerable to XSS, injection, etc). My goal is to design a scheme that will mitigate the threat of exposing sensitive data from intermediary services. The method of exposure could be anything, but may include disgruntled employees snooping for credit card numbers, or the service accidentally logging them to places that non-privileged admins can access.

There is an additional requirement that the intermediary can restructure the data (otherwise there would be no point to having an intermediary in the middle at all). For example, imagine the following payload coming from a source:

{"credit cards": [
  {
    "type": "visa",
    "number": "1234-5678-9012-3456",
    "expiry": "10-10-2020"
  }]}

The intermediary, say an HTML-rendering web-server, may wish to embed this credit card number in a specific part of its HTML response to the client.

My first question is does there exist any solution to protecting sensitive data that must flow through a network of microservices from those services themselves?

It seems that given the nature of sensitive data, it would require you to take care to ensure that any services which handle it are "pretty" secure. This makes data not only a toxic asset, but also infectious: as sensitive data proliferates through a web of micro-services, they all must be made bullet-proof.

I think I've come up with a sane way to solve this problem; however, given the constant reassurance that I should not, under any circumstances, roll my own cryptosystem I am less than confident about going with a home-brew solution.

Here is what I've come up with:

In our architecture, we use JWTs to manage user sessions, and so this gives us the ability to transmit extra information along with the user's session token through the system, with some guarantee that nobody has tampered with it.

My solution is for the client to generate a private/public keypair, and have their public key included in their JWT when they sign in. Clients will send the JWT (with their personal public key) through a network of intermediaries where it will eventually wind up at a data source.

From there, simply have the datasource encrypt - on a per-field basis - those fields which are deemed to be "sensitive" or especially toxic. So, from the previous example:

{"credit cards": [
  {
    "type": "visa",
    "number": "hQEMAwbqkJO6To1iAQf/UHf9ymLR8ejY/A1KouFCGoh9gBE71JgiAuQq5CMkuO7XLViDyf941dTUG==",
    "expiry": "10-10-2020"
  }]}

The intermediary is thus free to embed the number field wherever it likes, and it will never have access to the original value since it doesn't have access to the user's private key.

Of course, the client will then have to be smart enough to decrypt the field using its private key once the intermediary puts it in an arbitrary place in their own response.

My second question is thus, does this seem like a sane scheme to negate the "infectious" quality of toxic data?

Of course, I don't see any points of vulnerability above and beyond standard attacks against whatever encryption and decryption algorithms we choose to use, but that's kind of the whole reason one shouldn't roll their own cryptosystem :)

Thanks for putting up with the long read if you've made it this far!

Why pass toxic data through the intermediaries at all?

These intermediaries, no matter how many, need to have an API endpoint to retrieve the data itself from. Why not expose this endpoint via an API gateway? In order for your source to be secure, it must already be doing checks to see who can access what data. The clients would have the corresponding keys that grant permissions to said data.

Instead of encrypting the data, redact it, and replace it with a reference to where the un-redacted information is stored on the source server. This could take the form of replacing the value with a unique key, that when sent to the source server alongside the secret key will return the toxic data. It could also be a direct reference to the object id.

Think of toxic data as a block of uranium for use in a missile. Do you hide it in a box, and pass it along to every factory that works on the missile, or do you wait till the missile is finished, then retrieve the uranium from the stockpile?


Is it safe to store the password hash in a cookie and use it for "remember-me" login? I want to store an encrypted string of the password hash in a cookie and use the hash to lookup the user and log them in (if they want to be remembered).

Is this safe? The password is one-way hashed with SHA-512, 1024 iterations, using a timestamp for salt.

I imagine this would be unique because of the time-stamp salt.

No, this is not safe

You should generate a long random number and store it in a cookie. This random number is essentially just another password for this user. So, on the serverside, you only store a  properly salted hash of this random number.

You should only give out each number once and it should only be valid for 1 login. So allow for more than one of those hashes for each user. Upon successfully logging in, generate a new random number, give the new number in the cookie you give it to your user and store the (salted) hash of this number on the server side.

(On a side note, MD5 is not deemed good enough anymore for password hashing and a salt should be random; a timestamp is not random enough. Search for password storage here for more information on that.)


Do the servers see my IP when using a VPN? The innermost IP header is my publicly routable IP address that has been encapsulated. The outermost IP header is what is used for routing purposes.

When using a public VPN over the internet, the outermost IP header would be that off the VPN provider. The innermost IP header remains intact till it hits the destination, the server. This means that the actual identity of the source is never concealed from the end device. Is that right?

My comments may have been terse and vague because the reasoning behind this subject depends on an understanding of networking concepts as well as how VPNs behave. So here's the long version.

  The innermost IP header is my publicly routable IP address that has been encapsulated. The outermost IP header is what is used for routing purposes.

False (you can confirm this with Wireshark). This simply won't work, and we'll see why later.

When you start up a VPN client or server, a special interface is added to your system. On a *nix system, this will typically be called tun0 (assuming a TUN VPN, and where additional TUN devices follow the scheme tunN). This special interface is used for communicating over the VPN, and by default (for OpenVPN) is assigned addresses in the 10.8.0.0/8 range. For public, "privacy-providing" VPNs, they will also typically set your computer's default route to use the OpenVPN server on this interface, which is also in 10.8.0.0/8. If this is the case, all of your outbound traffic will have a source address in 10.8.0.0/8 and will be sent to the tun0 interface. The VPN client will then send the encapsulated traffic over your regular network interface to the VPN server.

This is what both IP headers would look like for a theoretical packet:

Outer Header: SRC=<YOUR_PUBLIC_IP> DST=<VPN_SERVER_IP>
Inner Header: SRC=<YOUR_VPN_CLIENT_IP> DST=<WHATEVER_YOU_ARE_ACCESSING>

The VPN server acts as a router. Once it receives your packet, it will route it depending on its destination address and the server's routing table. If this VPN serves a corporate network and static routes already exist on other routers back to the VPN range, the work is done here.

However, in the case of a public "privacy-providing" VPN, an RFC 1918 source address such as 10.8.0.0/8 cannot be routed back to across the internet, and thus can not be preserved all the way to the destination server. Instead, the VPN server or another router in their network must perform source NAT to rewrite the source address with the VPN provider's public IP address, so that the return traffic will come back to them. A connection tracking table records the original source address and port so that it will make it back to your client machine through the VPN.

While that was long and convoluted, it means that the answer to the following is "no".

  This means that the actual identity of the source is never concealed
  from the end device. Is that right?

When in doubt with these sorts of things, I highly suggest opening up a tool (e.g. Wireshark) to see how things are actually working.


clarification on how rainbow tables use multiple reduction functions to avoid collisions I understand how Hellman's time-memory trade-off tables work by creating chains of hash and reduction function results and storing the last result after a number of operations. since the reduction function maps from hash space (crapton of characters) into password space (let's say up to 10 characters), it's obviouts we are going to have a ton of collisions.

Rainbow tables try to solve this by using multiple reduction functions. I dont understand How or why that helps.

This wikipedia article seems to try to put some light into it, but I just cant make sense of what it's trying to say.

  Rainbow tables effectively solve the problem of collisions with ordinary hash chains by replacing the single reduction function R with a sequence of related reduction functions R1 through Rk. In this way, for two chains to collide and merge they must hit the same value on the same iteration.

OK, I think I figured it out.

I made an illustration since It seems to be the best way of explaining what's going on.

Rainbow tables use a different reduction function on each link in the chain (this can be viewed as a different function on each column, where chains are rows)

In the following illustration

H() is the Hashing function
R() is a common reduction function used on every link (not a rainbow table)
R1() to R3() are different reduction functions on every link (Rainbow table)
A-Z are plaintexts obtained by a reduction function
Hash1-5 are hashes obtained by the Hashing function

In the illustration you will find:

What happens during a collision in a Hellmans table (the predecessor of the Rainbow table, uses a single reduction function R())
What happens during a collision in a Rainbow table (identical to the Hellmans table, but uses different Reduction functions on each chain link)
What happens during a Collision occurring on the same spot on a Rainbow table (It's statistically unlikely, but if this happens then the chains end up being identical, but since this does not happen often it's not that much of a concern)


How difficult is it to crack salt portion of hash I write mobile application and I need to authenticate users against server. Server's side is written in php. I can't use cookies to store SID (Session ID), so I decided to send it at every request using GET method.

Later on, I decided that sending the same SID everytime is not secure enough, so I decided to use new string at every request. Server and Mobile client have stored same random string (let's call it salt). At the end of every request, server sends random string to mobile client and at the next request, mobile client sends to server hashed version of salt + random string. Server creates hash from salt + random string itself and compares it to one received from the mobile client to authorize it.

Now my question is:

If there would be a man-in-the-middle attack, how difficult it will be to crack the hash and find the salt portion of hashes?
How could I make it more difficult? (e.g. not using salt + random string formula, but salt_1st_half + random string + salt_2nd_half or hashing string multiple times based on length of username or other "tricks")

PS: I plan to use php's crypt function with blowfish algorithm at server

EDIT

  I decided that sending the same SID everytime is not secure enough

Why? Because I will transfer some sensitive user data (actual location,..), and anyone who would capture SID could sipmly change this data, or use current SID to pretend he is someone other and could get other sensitive data from application (and it wouldn't be any bug or application error, because regular user with that SID would have access to this data). This is why I decided to change SID after every request and add some calculations and validation of SID.

If your "random string" is really a "random string", then none of your tricks can do any good. For that matter, the salt won't make things better either. Neither the use of bcrypt (what PHP calls "crypt with Blowfish").

Indeed, all the games with salts and iterations are just ways to cope with the inherent weakness of passwords. Passwords are weak. They cannot help being weak: they fit in a human mind. So as long as human users are, say, human, we must deal with passwords, and since passwords can be (for most human users) brute-forced, we must apply "tricks" which make the attack harder. The two main tricks being slowness (making the hash function inherently expensive through many iterations) and salts (to prevent parallel attacks and precomputations). I have written extensively on the subject there.

However, if you have random strings between a computer and another computer (smartphones are computer), then no human, then no problem. A sufficiently long and sufficiently random strings defeats brute force by its sheer randomness. Salts and slowness do not bring any additional security: it cannot be brute force, period.

(Or, said otherwise, if your random string can be brute forced, then you are doing it very wrong.)

It all boils down to this sentence of yours:

  Later on, I decided that sending the same SID everytime is not secure enough

Why ?

Simply, why ? Why would it not be "secure enough" ?

There may be good, rational reasons. But you cannot make anything of value, in the domain of security, if you don't take the time to think your requirements through. Define your security: your goals, the attacker's goals, the attacker's powers, the assets at stake...

Anyway, if the communications between the application and your server need any kind of confidentiality or integrity or authenticity (I suppose this is the case, since you bother with authentication), then there is no escaping it: use SSL (also known as "HTTPS"). No SSL, no real security. But with SSL, things are fine. You can send your "random string" (which really is a custom session cookie) as is, it won't be intercepted by third parties, active or passive.


Finding SHA-2 collision What would be the implications if finding a collision in the SHA-2 hash function?

Would there be a greater impact if more than one were found, or would it be the same in principal?

First there are different types of hash collisions. The simpler and more likely case it that it is possible to create two documents which result in the same hash value ("collision attack"). The harder case is to find a collision for a specific given document so that both result in the same hash value ("second pre-image attack") or to find a document matching a specific hash value ("first pre-image attack"). This is also the case which has the more security impact.

A major use of SHA-2 is the creation of signatures. If it would be possible to create a document which results in the same hash as another given document one could successfully reuse the signature of the other document. This means it can be used to successfully claim that a document was signed by a specific entity even though this entity never signed this document.
One very important type of such documents are X509 certificates which are used for authentication within TLS (and thus HTTPS). Successfully forging such a certificate thus means that a man in the middle attack could be possible.
Other users of such signatures are S/MIME where forging a signature would mean that one could claim that a specific forged mail was signed by a specific person. And such signatures are also used for signing software and forging a signature here would mean to successfully pass through white lists where the trust to a software (and the ability to execute it) are based on the issuer of this software.

If it is not possible to create a collision to a specific document but to create two documents resulting in the same hash it would still be a serious issue. For example this could be used to create two versions of a contract which both result in the same hash. The cheating party then could later use the previously created different version of the contract with different rules and claim that this is the original version because it contains the same signature.

For more information see RFC 4270 - Attacks on Cryptographic Hashes in Internet Protocols. Interesting might be also Crypto breakthrough shows Flame was designed by world-class scientists where it shows how attacks against the the older hash function MD5 were successfully used in a real-life targeted attack.

  Would there be a greater impact if more than one were found, or would it be the same in principal?

While this might be worse it would probably not be much worse compared to the initial problem.


Why is blog spam always written so badly? Some spam messages fresh from my Wordpress filter:

  Asking questions are in fact pleasant thing if you are not
  understanding something totally, except this article gives good
  understanding yet.

and

  Thanks for any other informative blog. Where else may I am getting
  that kind of information written in such an ideal means? I’ve a
  project that I’m simply now working on, and I have been on the look
  out for such info.

Is it just that basically all blog spam comes from non-English speaking countries, or is there some kind of tactical decision being made about the language? I ask because when I first saw it, I thought perhaps they were being genuine but inarticulate.

The spammers are automatically generating new comments by taking existing comments and running them through a thesaurus program that replaces words with synonyms or related parts of speech. The result is a sentence which makes sense, but has word choices that no native speaker would ever make:

  Where else may I am getting ...

is clearly not something a native speaker would write, but

  Where else could she be getting...

is, and can be transformed by a simple substitution of pronouns and synonyms into the spam text.

This way, even if anti-spam forces have a huge database of known-spam comments, the spammers can generate infinitely many new ones that are plausibly English.

I long suspected this was the case but I recently got proof. I now occasionally get comment spam containing the entire substitution script; it'll be something like:

  I can't [believe/understand/comprehend] the [great/superior/amazing] [content/information/data]...

Since the spammers were likely non-English speakers to begin with, they didn't notice they were sending the script rather than the output.

If you examine a large enough corpus of spam, you can pretty easily figure out what algorithms they're using. It would be an interesting challenge in reverse engineering to write a program that deduces the algorithms used from the corpus.

  I ask because when I first saw it, I thought perhaps they were being genuine but inarticulate.

They fooled you once. It probably won't happen again!

Commenter TildalWave points out:

  none of the sample spam messages OP posted actually endorse any products, or are otherwise promoting any other cause.

Well let me give you an example: here's a comment that arrived a few minutes ago on my blog:

user name:  cuisinart compact toaster review
user url:   toasterovenpicks.com
user email: jeffryshuler@2-mail.com
user IP:    37.59.34.218
Comment contents:
One in particular clue for that bride and groom essential their
own absolutely new everything, actually a surname burned which has a mode,
which render nearly girl thankful recognizing their refreshing surname
therefore distinctively printed.

The product is promoted in the user's metadata, not in the content of the comment. The content is just an attempt to get past the spam filter.  (I suspect that in this case the text is not a mutation of an existing text but rather generated by a Markov process over a corpus of documents about wedding planning.)

Obviously anti-spam forces are on to this one too, which is why this was in my spam filter. My spam filter (akismet) on average lets through one spam for every 705 submitted. Again, that's what spammers are going for; they know that 99.9% of their work will never be seen by anyone. They're trying to randomly explore the space of false negatives in spam filters, a space which is getting quite small indeed.


Do spammers use legitimate email marketing companies? Every so often I will find myself on a mailing list that I know I didn't sign up for. This always gets me very cautious and I treat the junk mail as hostile spam - don't click, just delete and ignore. However, after regularly receiving mail from the same address (usually newsletters or training advertisements), I'll usually investigate to determine if I can safely unsubscribe rather than have to put up with junk in my inbox.

When I examine the Unsubscribe links in the mail, they'll often go to well-known email marketing sites like Constant Contact or Mail Chimp. I take this as an indication that it's generally safe to follow that link, and I will usually unsubscribe that way, especially if there are other indications that the source of the junk is legitimate. This way I only ever go to the website of the marketing company, not the originator.

Is it reasonable to assume that spam coming through legitimate email marketing companies can be treated as safe, or at least safe enough to unsubscribe? By unsubscribing, do spammers learn that my email address is active? If it is safe, is there a good way to determine which marketing companies are trustworthy enough that I can feel safe unsubscribing?

Most of the marketing companies will only bother you with spams(some of which may be non-security scams), but like you mentioned for unsubscribing we usually click on the link it guides us to a (3rd-party) safe email marketing sites.
But the question here is , how can we ensure that email marketing website(on which you are landing ) is not compromised?

Even i have faced this conundrum, so i usually create a separate email-id mainly for signing up on various blogs (like stackoverflow )
That way you never have to worry, even if the spammers know that your email is active.

Lastly, the only way i feel you can determine is if any marketing company is trustworthy enough is by adding a tag to where ever you subscribe (Ex: if email is name@org.com , give your email as name+site@org.com, you can test you by sending test mails). Refer to this link for more info!
That way if a company does not honor your unsubscribe request or sells your information you can find out(as you will get that tag in incoming email!)


Type of malware on adult sites What kind of malware is there on random adults site?

When I open a video in such a sites there is weird effect of opening another window of browser which is immiedetely closed or opening another tab after click on video player.

I am wondering what malware is that and for what purpose is this. Just to read about it more.

I guess to be safe the only way is to not enter such a sites, right ?

What you are seeing is not malware, but an ad. Adult sites will very often open one or more new tabs or even windows to partner sites when you click on the page. This is not malicious behavior, although it can be very annoying. Basic ad blocking software should take care of that nicely.

Most of the time when there is malware on adult sites, it is distributed through downloaded executables or through outdated Flash or Java applets. Unless you have Flash installed or are gullible enough to download and run programs from pornographic websites, you should be relatively safe. To increase safety even more, make sure your browser is always up to date to avoid vulnerabilities.


Decide to REST API Security I've developed an API. I got confused and I've been reading articles for days.
Actually my question is close to these but not exact (maybe a combination of them);
Securing REST API that will accessed from different clients
Secure no-login REST API for very few clients

I need to provide safety to my API. The API will used by client 3rd party applications. I've attached a schema the below.

What should I do?

HTTP-Basic with SSL\TLS, HTTP-Digest with SSL\TLS, OAuth 2.0 or what else should be?

Edit (2015-03-25):
This part was given up. Look at "Edit (2015-04-01)" on the below

I've decided to implement SSL + OAuth 2.0 (Resource Owner Password Credentials Grant).
If you think it's not convenient for the scenario, please inform me.

 +----------+
 | Resource |
 |  Owner   |
 |          |
 +----------+
      v
      |    Resource Owner
     (A) Password Credentials
      |
      v
 +---------+                                  +---------------+
 |         |>--(B)---- Resource Owner ------->|               |
 |         |         Password Credentials     | Authorization |
 | Client  |                                  |     Server    |
 |         |<--(C)---- Access Token ---------<|               |
 |         |    (w/ Optional Refresh Token)   |               |
 +---------+                                  +---------------+

        Figure 5: Resource Owner Password Credentials Flow

The flow illustrated in Figure 5 includes the following steps:

(A)  The resource owner provides the client with its username and
        password.

(B)  The client requests an access token from the authorization
        server's token endpoint by including the credentials received
        from the resource owner.  When making the request, the client
        authenticates with the authorization server.

(C)  The authorization server authenticates the client and validates
        the resource owner credentials, and if valid, issues an access
        token.

Edit (2015-04-01):

I've implemented OAuth 2.0 Client Credentials. And now I'm looking for how can I implement an SSL certificate for clients API request.

The client credentials grant type MUST only be used by confidential
   clients.

 +---------+                                  +---------------+
 |         |                                  |               |
 |         |>--(A)- Client Authentication --->| Authorization |
 | Client  |                                  |     Server    |
 |         |<--(B)---- Access Token ---------<|               |
 |         |                                  |               |
 +---------+                                  +---------------+

                 Figure 6: Client Credentials Flow

The flow illustrated in Figure 6 includes the following steps:

(A)  The client authenticates with the authorization server and
        requests an access token from the token endpoint.

(B)  The authorization server authenticates the client, and if valid,
        issues an access token.

What I would say about the options that you outline is that HTTP Auth with SSL is a simpler but less flexible option and Oauth2 is more complex but has more flexibility in what you can achieve with it.

One example, as you've noted in your ASCII art diagram, with OAuth2 it is possible to create a token which can be used in place of the password to authenticate requests. This is likely to be an advantage over HTTP Basic/Digest as it means that you don't have to store the users password on the client, you can just store the token.

So in general if you can implement OAuth2 well, I'd say go with that...


How to know if an ASP web page is vulnerable to SQL injection? I've some experiences of working with PHP web applications vulnerable to SQL injection and exploiting this type of vulnerability successfully but never tried to do this on a ASP based web application. When we try to find out if a PHP web application is vulnerable to SQL injection we usually add a single quote to the end of an input parameter like this:

http://example.com/index.php?id=1'

and if we get an error like this:

  You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''' at line 1

we know that it's vulnerable. In some cases we get a blank page or missing some data on page which can mean that its vulnerable.

So here is my question: If I add a single quote to the end of an input parameter in an classic ASP web page and I get a blank page or miss some data on that page, does it mean that it's vulnerable to SQL injection? And is there any other ways to know if an SQL injection vulnerability exists in an ASP web application?

Sorry, I want to expand a bit on your thought process.  It's not just an ' at the end.  I mean, that's a good, quick of finding a decent percentage of the holes.

Let me give an example of a vulnerability that this approach wouldn't find:

url: http://www.somesite.com/page.asp?name=kevin&status=live

--- code behind the scenes: ---
string table = "history"
if (status == "live") table = "current"
string sqlCmd = "select * from " + table + " where name = '" + name + "'"

... see the problem?  The last parameter in your url specifies the status, and the code is simply using a "is it X or not?" logic to it - it doesn't inject the actual value into the SQL statement, so it's not vulnerable.  But the other parameter is inserted into the SQL statement raw - which makes it vulnerable to injection attack.  So while:

http://www.somesite.com/page.asp?name=kevin&status=live'

... wouldn't have an error, this would:

http://www.somesite.com/page.asp?name=kevin'&status=live

So, realistically, if you're going hunting for SQL injection vulnerabilities, you need to try all the parameters in the URL - even parameters that are optional and sometimes aren't specified.

Final point - if you have access to the source code, it's easier to find this sort of stuff by actually looking at the code.  Basically, if you're building raw SQL statements and then calling EXEC, you've probably got problems.


Making transactions only, or almost only, by QR codes I have a OnePlus 6 smartphone and I recently opened a bank account in a bank which seems to me very innovative in the context going payment card (debit/credit) free (using only application and/or cash).
It will not necessarily be my main bank account and as of now I don't see myself putting most of my money there, but I want to put there about 2,000 USD for now.

I have the bank application on my smartphone and I can pay worldwide with it with no fees/commissions via QR code until a generous amount.

My smartphone barely has any applications installed besides WhatsApp and Gmail.
I don't use a PIN code on my Smartphones for about 10 years now (I do use a PIN code for bank application though). I also never used fingerprint in my smartphone.

My question

What security measures should I take to secure my smartphone properly if I go payment card free and manage all payments, worldwide, by smartphone?

Update

I take back the notion (if I ever published here one) that one should go payment card free; I had two cases - one outside the country of the aforementioned bank, where my account was locked (due to some dual SIM card related behavior) and the application's mechanism to unlock it was very unintuitive and inconvenient to utilize so in that case, if I would have been only with my smartphone and lose all cash, I would not be able to handle economically easily.

Therefore, I advise against that method; I personally believe that the method of Smartphone as primary economic instrument with payment card as secondary (and reserve) economic instrument, with no cash at all; is best --- but I might be wrong.

That probably depends on the banking application and how the bank allows you to recover a lost PIN. I would normally say "you should enable PIN or fingerprint authentication", but in fact you might not be required to. PIN/fingerprint is breakfast for security-aware individuals.
Let's analyse the few information you provided. That you are enabled to pay by QR and that you would like, as myself does, to manage all payments via smartphone.
I will not disclose the name of my bank, but will describe what major banks in Europe normally do. You did not describe how your bank works in the first place
Authentication at banking application level
Assuming you don't have fingerprints enabled, and/or if your bank app doesn't (yet) support that, most banks will, despite the great security APIs of Android, issue you a yet-another new PIN code that is valid only for themselves. It can be equal to your phone's PIN if they allow you to choose.
Since you have to reauthenticate at the banking application ever time you do something, from checking your balance to making a payment, they will be safe. Even if you lose your phone and who finds it has access to Whatsapp and all your emails, they will likely have no immediate access to your banking account. I will be writing a huge footnote.
That is the only security measure you can have, but depends on your bank. Note: we could write an entire book for this paragraph, including OTPs and PSD2 (European Payment Service Directive 2) but those will go beyond the scope of the question, which is about the security measures the OP can take.
Geolocation
A lot of banks require customers to disclose GPS location when doing anything. I am a bit skeptic about anti fraud systems, but at least on paper this works: they already know the location of stores where QR codes are exposed. Once you issue a QR payment, you are supposed to be at the place. QRs can still be sent over Whatsapp, printed and photo-copied for remote payments.
Root checking
Another things banks normally do is to limit or block functionality to rooted devices that do not pass SafetyNet hardware/software attestation.
Disclosure: I am Groot. I will never unroot. But I have to admit that they block root for a reason. Perhaps most of them because OWASP requires that.
In this case, payments with QR codes can be theoretically violated by a malicious root app that forces camera API to read a bogus static image with a QR code owned by attacker. Notice the emphasis on theoretically.
Footnote: recovering credentials on unlocked phone
This all depends on the bank. Losing an unlocked phone with access to email and messaging is dangerous per se, but might or might not be enough to steal money to you. I have already talked about banks requiring you a separate PIN/authentication to issue transactions.
But when you leave unrestricted access to your emails, danger is close. Let's put it extremely simply simple. If your bank allows you to recover a forgotten access code by simple means of SMS recovery and/or email confirmation, you are required to put additional security measures on your phone. A number of banks will at least require you to be physically at the branch before asking you for email/SMS confirmation. If your bank falls in this category, you still might have chances to live without PIN and fingerprints.
Summarizing
Most depends on the security model of your bank. It is trivial to require everyone to use a strong authentication to the phone, but as I have illustrated while banks do enforce their own security in banking applications, odds are that, according to the practices of your bank, you could have a big hole open in your security by leaving the phone unlocked.


Should we store web application files when we are constantly developing in encrypted directory? The problem with encryption is that it becomes slower:

https://askubuntu.com/questions/23489/what-is-the-performance-overhead-of-encrypted-home

It especially is important when you develop symfony applications, because symfony is slowest framework for development I have seen so far.

If you do not encrypt and your computer is stolen, then as I understand even if you have password when logging in to linux, somebody can load their own operating system and see unencrypted files, right?

If we know that computer is protected - like you do not move the computer from office and office has security system, then maybe it is not a problem.
But if you move your laptop everywhere, then the risk increases.

somebody can load their own operating system and see unencrypted files, right?

Yes. If you are not using encryption and an attacker gets access to your hardware, they get access to all your data.

  Should we store web application files when we are constantly developing in encrypted directory?

That really depends.

If this is a larger company, there should be a policy in place about this. Ask the relevant people about it.

If this is a small company and you are the one responsible for the decision, you need to weight the factors.

What is the cost of stolen source code? ie: How important is your source code? Is it open-source anyways? Is it something someone else could actually use? Or is it highly specialized software that is unlikely to be useful for anyone? Do you depend on the source being secret for security reasons (security through obscurity)? If the source is stolen, can you use other measures to punish the thief (legal avenues, etc)?
On the other hand, what is the cost of encryption? Have you measured the performance (my guess is that with decent laptops, it shouldn't be a problem)? How many hours would your developers loose if you used encryption?

After you weighted these factors, you should have an answer.

You could also try to find a middle ground. Eg have two laptops/computers. One encrypted which developers can take where ever they want, and one unecrypted that can only be in the office (ideally a desktop computer, so they are not accidentally removing it). This assumes that the source isn't so important that someone would break into the office (but if we assume that someone would to that, we could also assume that someone might tamper with an encrypted laptop to log the password).


how much of a security threat would this be? If I set up a Domain Controller server to be accessible from the internet via Remote Desktop Connection (through port forwarding in the router), how much of a threat would that be?

and if I have a strong administrator password?
and if there are users with weak passwords?

Which mitigation steps could be taken?

EDIT:  I perfectly agree with the idea "use the Domain Controller ONLY as a Domain Controller" expressed in the comments.

But there are cases of small companies (15-30 users) that do not want to purchase more than one server, nor buy a new hypervisor to host multiple servers on it.
In those cases the only server ends up doing everything...

You would have two types of risks:

There could be a flaw in the server code. This is a generic situation for every server, but a Remote Desktop server is known to be relatively complex, and thus probably has more exploitable bugs than, say, a SSH server. Microsoft themselves offers an additional product called Remote Desktop Gateway (previously known as Terminal Services Gateway) which acts as an intermediate step. The gateway runs a "normal" SSL server, on port 443, and can perform a user authentication, but it is much simpler (and therefore assumed to be stronger) than a full-blown Remote Desktop server, since it does not actually handle the Remote Desktop protocol -- it just forwards it to the actual Remote Desktop server.

Note that among possible "flaws" in Remote Desktop is configuration, in particular with regards to certificates. A basic Remote Desktop server can use various encryption layers, some custom, some encapsulating SSL. A critical point is that, depending on the configuration and on how the user handles it, the client might fail to properly validate the server's certificate (in particular when the server's certificate has been automatically generated and is self-signed). In that case, the client is open to a Man-in-the-Middle attack. There again, the Gateway makes things sturdier, in that it enforces a very Web-like SSL server model which is harder to configure wrong.
If a user is allowed to open a session on the server, on virtue of presenting a matching password, and that password is weak, then an attacker could run a dictionary attack, which means trying possible passwords until the right one is found. This would be an online dictionary attack, and you might be able to automatically notice such an ongoing attack by the huge amount of "failed login" events. However, if the attacker succeeds, then he gets to run arbitrary code on the machine. Privilege escalation on a local machine tends to work (locally exploitable flaws are much more common than remote flaws) so you basically have lost.

The only good defence against weak passwords is to educate users into choosing stronger passwords. As a mitigation measure, you can also restrict Remote Desktop access to some specific users; by default, only members of the local Remote Desktop Users group will be allowed to open a session. Your first step should be to actually decide who is allowed to do that on the machine (As @Hennes suggests, given that the machine is a Domain Controller, the list of people who are allowed to open a session on it should be limited to just the administrator; or you are doing it wrong).

Remote Desktop Gateway is not free and tends to require an extra machine. A cheaper alternative is to deploy a VPN solution like OpenVPN (the core software is GPL, no license needed). This is functionally equivalent. It won't do anything against weak passwords, though.


How to detect changing IP address and user agent on a HTTP session? I have some HTTP logs where I see the hacker changing his IP every request, and occasionally changing his useragent.

Is there a way to detect this automatically? Perhaps a snort rule? or any other way?

A lot of websites tie the session ID to the IP address, so a session valid ID valid associated to on IP address will be considered as invalid if presented by another IP address.

A more permissive approach might be, instead of blocking such access to simply log them and if needed send a warning to appropriate persons.

Be aware that some privacy protection tools rotate the IP address used (automatically switching from one proxy to another each n seconds for instance) and maskerade browser's user agent while keeping cookies and session information to allow normal browsing. Such tool will produce exactly the behavior you describe while not necessarily be used with any malicious intentions.

The measure indicated in the first paragraph will prevent people using such tool to access to your services. It's up to you, depending on your policy, to decide what attitude to adopt under such circumstances: block, warn, or simply log.


How do you make sure a pdf is deleted after being viewed in the browser? For things like images or html documents, cache headers make sure that the data is deleted when the browser is closed. However as PDFs are opened in a plugin, the cache headers do not seem to have the intended purpose. PDFs are often left behind in the temp folder on windows machines.

Are there any cross-browser ways of making sure they are removed from the computer?

The scenario is that I have some files on a server accessible via the Internet, and expect that users may read them on shared and/or publicly-accessible computers.  I don't want copies of these files left behind on such systems, and can't trust/expect the end-user to clean up after themselves.

For things like images or html documents, cache headers make sure that the data is deleted when the browser is closed.

Mr Unscrupulous Ninefingers the cybercafé owner has just recompiled Firefox to make it totally ignore cache directives.

My point being you cannot necessarily trust the client side to actually implement properly any of the protocols to which it should conform. Mostly, this is just because the developers felt it was unnecessary and the software is say 98% conforming, but it could be done maliciously.

  The scenario is surfing on a shared computer where you don't want to leave behind documents, yet you cannot expect the user to delete the temp-folder themselves.

The honest answer is that if it is important that your files are not on that computer, don't put them there in the first place. At all. Ever. Use a laptop with an encrypted hard disk and an encrypted VPN via free wifi so that the data is both protected at rest and in motion, assuming it might not get deleted.

I should also point out that deletion does not guarantee removal of the data. Literally, it means the entry of that file in the filesystem has been dropped so that the filesystem will happily overwrite it. Stopping the operating system immediately following your access and examining the hard disk would with a fairly high probability of success give me that file.

Edit: I would like to make some additional points regarding client side access:

A live cd image (on an actual CD) might help here. Once created, it cannot be modified except as it runs, so that pushes potential attack attempts to some form of pre-boot intercept, which makes any attack much more difficult. Clearly, however, there is an obvious downside: you need access to the appropriate network configuration information (subnets, proxies etc). Your local cyber cafe may not appreciate this. Another company's corporate network definitely won't.
Proxy servers. Unless you access this over a trusted, encrypted channel, a proxy server could well cache your document and still pass you the delete request, deleting the content from the client but not the proxy.
If you trust the shared workstation, i.e. it is part of your corporate network, I'd use another means to ensure this. No local storage would help, since then even physical access to the workstation isn't going to be of any use.

If your aim is just to remove the pdf, I can't really help. I've no idea how you'd do that. I'm not entirely sure how responses containing pdf files behave given http cache headers. However, I do think that even if I knew a way, it wouldn't represent security in the sense that it does not give you any real level of assurance as to the integrity of that file. Even if you encrypt the pdf, you must still ensure that your environment is free from key loggers and that the reader software you have installed can be trusted to decrypt the passwords without reasonably being subverted.


Automated tools for Cisco IOS config auditing? Are there any automated tools for auditing config files exported from Cisco IOS devices?  Free/Open Source is always nice, but anything that does the job would be of interest.

Cisco's own SDM (Security Device Manager) performs some basic auditing.  "Cisco SDM allows users to perform one-step security audits to evaluate the strengths and weaknesses of their router configurations against common security vulnerabilities."  For a list of features included, see AutoSecure Features Implemented in Cisco SDM .

Another well-known tool is Cisco RAT, available from the Center for Internet Security.

These are good starting points, but far from perfect.

A more recent option (which I haven't tried yet) is the Nessus IOS plugin from Tenable.

More ad hoc (single-function) tools can be found at

http://packetstormsecurity.org/cisco/page1/
and
http://www.cymru.com/Tools/index.html


Android anti-tampering and SSL pinning bypass solid implementation Is there any advance solution for Android application anti-tampering and bulletproof obfuscation implementation?

I have been already using following protections in my application:

Obsufcation using proguard
Anti-java hooking to restrict attacker from bypassing root detection and SSL pinning.

Does anyone have any bulletproof advance technique to implement such solutions? I have come across this solution. Can anyone let me know how effective and practical it is to implement?

Code Obfuscation

Obfuscation can only act as a hurdle for an attacker doing secure code review. Paid obfuscators such as Dexgaurd are far better than the free ones and can be used to considerably increase  the attack complexity. But, we should not completely rely on obfuscation as an attacker can spend good amount of time to deobfuscate and analyze the code.

Android Anti-Tampering

Android system is built on the top of Linux kernel. A root user(Rooting Android Device) in Linux system is a super user and has all the administrative privileges and so can do almost anything on the system. This includes bypassing the almost all the security implementations implemented in application/device. Therefore, I believe that there is no sure-shot solution to verify the integrity of the application.

Having said that, I suggest implementation of solutions that can help us to considerably increase the attack complexity and build somewhat tamper proof applications and SafteyNet Attestation API is one of them. I personally suggest the implementation of this API for implementing application integrity checks. It is a paid solution as the free quota is very limited. You must check the implementations guidelines properly and it should be securely implemented to get desired results.

For anti-hooking/debugging, I strongly recommend you to check Android Anti-Reversing Defenses that can be implemented to substantially increase the complexity.


How can you hide / fake your ip address without proxy / vpn? Question might sound impossible but I'm still serious. Downloaded a plugin for firefox called "Modify Headers" (https://addons.mozilla.org/de/firefox/addon/modify-headers/).

Set it up like that:

  Select Action: Add
  Header Name: X-Forwarded-For
  Value: Enter any IP address here.
  Add this and press start.

Now go to https://www.iplocation.net/find-ip-address or some other site and you will see that your original ip has changed without the use of proxy.

However, this doesn't work on all / many sites, but still, maybe there is a better way doing this so it works on all sites?

No, and you're not even changing your IP address with the method you've outlined - you're effectively claiming that you're a proxy for whatever IP address you provided in that header. It might work to fool some basic analytics tools, but your IP address would still be available to whatever servers you connect to (they'd need it to know where data should be going), and it wouldn't fool any authorities who wanted to track activity back to you.