Chrome and Firefox showing errors even after importing latest CA certificate for Burp Suite I am using Chrome 61.0.3163.100 and Firefox 39 on Windows 7 32-bit with Burp Suite v1.7.

I have imported latest CA certificate for Burp Suite. In spite of which it's not working for sites with HSTS and throwing following error in Chrome.

  NET::ERR_CERT_AUTHORITY_INVALID

CA certificate

In Firefox its showing following error:

  An error occurred during a connection to www.google.co.in. SSL received a weak ephemeral Diffie-Hellman key in Server Key Exchange handshake message. (Error code: ssl_error_weak_server_ephemeral_dh_key)

I have checked following sources:

Make SSL work with Chrome (yes, I read the installation procs)

Securing a Web application using HSTS

Burp Suite - Although my configurations are correct, still Chrome doens't allows me to access HTTPS sites and throws an error!

What am I missing ?

You get this error because Chrome expects a subject alternative name, as correctly stated in of the sources you've checked. This problem was fixed in Burp already. From the release notes for Burp version 1.7.20.

  Burp Proxy's generated per-host SSL certificates now include the site's commonName in the subjectAlternativeName extension. Apparently fallback to the commonName was deprecated by RFC2818 (in 2000), and browsers have recently decided to implement this.

But, you are using an older version.

  I am using Chrome 61.0.3163.100 on Windows 7 32-bit with Burp Suite v1.6.

Thus, you need to use at least version 1.7.20 to have this problem fixed.


What are the traces of a mysql attack on a server when the attacker has full permissions? I just turned my server off yesterday, after it began to distribute comment spam across the internet, at an astounding rate over 70 "spams"/min, bottom of the line 1/2 gig ram VPS. I'm still trying to figure out how there are doing this, but one possibility is an injected file, injected by MySQL. The reason I'm suspicious about MySQL is that I may have leaked the credentials of a user with full power... Oooopss (Don't ever trust a .gitignore if you don;t know exactly what you're doing)!

The question for real:

How could I tell if somebody tried to add/modify a file on my server, given full admin mysql powers. Bonus if I can find the file... I have something really special planned for it.* The biggest problem is I don't have a mysql query log :/...

System stats:

Ubuntu 14.0.4
Apache 2. somthing
MySQL ... ?
I can look if you need, but I don't want to turn it back on if it can be helped

* I'd never attack back... ever... I was just thinking something like deleting it character by character, slowly and deliberately. Maybe sending it to some laboratory to test vaccines on, pointy needles required!

Update: for those of you curious about what was really wrong with my server, I'd messed up a proxy pass to node so that anyone could use it.

Depending on the privileges the mysql user (the system-level account used to run MySQL) has and how MySQL is configured, the traces could be anything from a full audit trail in the MySQL log files, to no trace whatsoever.

Assuming the mysql user can't do anything but read and write files, your bet bet is to search the drive for files owned by that user.  MySQL doesn't normally create files outside its data directory, so anything you find outside of there is suspicious.


Why does airodump-ng shows 2.4GHz AP beacons, but wireshark does not? I'm debugging some edits I made to hostapd which requires me to capture some beacon frames, but I can only capture them with airodump-ng and not with wireshark.

I have a Panda PAU09 adapter running on Kali.

Method #1:

I fire up airmon-ng and put the Panda into monitor mode. Next I run airodump-ng to find the BSSID and channel of my system running hostapd. Then I run airodump-ng again to capture to a file. I open the CAP file in Wireshark, and there are my beacons. COOL! Exactly what I needed!

Method #2:

I put the interface into monitor mode and start Wireshark on that monitor interface. I set the filter to just look for beacons and see tons of them... but none from my AP. I remove the filter and see no traffic at all from the MAC. I even log into the hostAP system to verify the MAC and it is correct. No traffic from that device at all in wireshark, but plenty with airodump.

I'd really like to just use Wireshark.

Thoughts on how to debug?

Thanks.

airodump-ng will hop channels unless given a specific channel with the -c flag, whereas Wireshark is going to capture wireless traffic on whatever channel the interface is on, and does not dynamically adjust the channel. If there are other processes running on your system that manipulate the wireless card (e.g. scanning for networks), the channel may be changing unexpectedly. Or, it is likely not hopping channels, but is currently on the wrong channel.

You can manually set the channel by opening the "Wireless Toolbar" under the "View" menu in Wireshark, or using the iw utility:

# iw dev <interface> set channel <channel>

If you desire channel hopping, you could put the above command in a script that cycles through all available channels.

If you have the aircrack-ng suite installed, the airodump-ng command can tell you what processes may be using your wireless card so that you can kill them.


I would like to get scammed I would like to get scammed via email to have some fun. How can I achieve this? (I have looked online and have found no answers only how to not get scammed.)

Open your spam folder and just look :)

But seriously you could register a new throw-away email address and then:
- Google for popular scam things like viagra, etc and sign up for newsletters.
- Email about scam work from home jobs on Craigslist


XSS in input field bypass HTML entities I am auditing a web application and trying to exploit XSS in the value attribute of an input field. While fuzzing I figured out that the application is filtering < and > so I changed my payload but the application is converting " into &quot. Without completing the attribute value with the quote, the payload will not work.

The insertion point is marked with USER INPUT below:

<input name="xyz" value="USER INPUT" type="text">

How can I exploit this?

You can't. It sounds like they are protecting against XSS properly.

HTML entities (&quot;, &gt;, &lt;, etc.) are not interpreted as HTML and turning "dangerous" characters into entities is one of the ideal ways to protect against XSS.


Are there documented best practices when federating identity to a third party using OIDC? We are creating an OpenId Provider (using Identity Server 4) that has the ability to federate authentication to other IdPs based on email (eg, we first ask for email and then determine how to authenticate you, potentially by redirecting you to another OpenId Provider). I'm looking for documented best practices on this scenario, especially when dealing with sessions. Some examples:

When we are authenticating locally (not federating), we want to store a session cookie at the IdP to enable SSO scenarios. However, in the case of federation, we perhaps should not store cookies and should instead always redirect to the third-party IdP (who may or may not have cookies).
If the user is federated and the client requests a refresh token, we should request a refresh token from the third party IdP and give that to the client. In turn, when issuing new access tokens based on the refresh token, we should validate that the refresh token is still valid at the third party IdP.

Flows like these would give the third party IdP better control over security and session parameters specific to their needs. However, I have been unable to find documentation, standards or RFCs detailing these or other recommended flows when federating from one OpenId Provider to another.

Feel you, there is almost nothing documented to be an idp, but you can find a lot on how to be a sp.

As far as I understand federated identity, when you use idp1 and federate to idp2, idp1 acts as a client so yes, you should delegate almost everything to idp2 (request tokens, validate them, etc).

I also agree with

  we should not store cookies and should instead always redirect to the third-party IdP.

that should have cookies stored to mantain SSO.


What methodologies are useful when reverse-engineering malware / shellcode? Whilst I'm familiar with reverse engineering techniques from a technical standpoint, I've never found a good methodology for approaching and dissecting malware / shellcode. I've found hundreds of tutorials on the technical aspects of analysing malware, but very little on the actual methodology of approach.

A few questions to help you understand what I'm looking for:

How do you start analysis? Do you start at main and spread out from there, or do you have a better method?
How do you find and identify important functionality, or particular functionality that you're interested in?
How do you map out high level control flow?
How do you manage the helper routines you've identified? I find bookmarks to be insufficient, and notepad to be too primitive.
How do you avoid getting lost in the avalanche of assembly code?
Any other tricks / tips for approaching these kinds of tasks?

One method which I love is to use a API Monitoring software. My favorite is the one by Rohitab (google it) . I debug the malware in question and step through while I monitor API calls made on the software. This will provide you with a lot of information on what the malware is doing. For ex: monitoring FileRead and FileWrite calls will let you know what files the malware creates or reads. Note that this is somewhat of a gray box technique and not purely reverse engineering. Although, if you find something interesting in the API monitor, you will know in which part of the assembly the interesting part is.

Cheers.


Difference between Kali Linux and Santoku Linux I would like to know, before I will install Santoku, what are the differences between Kali Linux and Santoku Linux? I know that Santoku is dedicated to mobile security testing, but Kali has some tools for mobile.

I focus on comparing tools for mobile applicatation testing, which system seems to be better?

They both are similar in nature, just a Linux distribution with a bunch of tools pre-installed, you could take a vanilla Mint and install the software you need, so if you're debating which one to use you need to know what you will use it for, it comes down to the programs that you need and are comfortable using.

In my opinion, Kali is more complete, it comes with a much wider array of software, this also means its bloated, and at the end of the day I only use maybe 5 or 6 programs at most so having it installed is -for me- just the convenience of isolation inside a virtual machine with anything I could need.

Having said that, I do not think Kali linux comes with development tools.


Database hardening techniques So as I understand it database hardening is a process in which you remove the vulnerabilities that result from lax con-figuration options. This can sometimes compensate for exploitable vendor bugs.

Three main stages exist in hardening a database:

Locking down access to resources that can be misused.
Disabling functions that are not required.
Principle of least authority or least privileges.

There is a wealth of information for "locking down" RDBMS environments to harden them against attacks. However these resources don’t provide enough context on current exploitations for databases (if you don’t know what types of attacks exist and which ones are popular, how do you know if your hardening measures are going to provide protection).

A bad way for me to begin learning hardening techniques would be to list as many database exploitations out there and learning how each and every one of them work, that could take... a very long time.

So I am wondering where I can begin, resources available and current trends etc.

There are a few resources such as CIS. IF you want to by up to military standards, I would check out the STIGs (Security Technical Implementation Guides). They have STIGs for SQL Server, and you can check out the general DB reqs.

From your post, it is not clear if you are working in a web environment, but you probably want to know about SQL injection, etc. I'd start at OWASP. They have some general information on SQL injection, some secure guidelines, and some testing guidelines.

In terms for finding current exploits, you can search through CVEs.

If you provide us with some additional detail, we can provide some more resources. You may just want to check amazon for books on the subject that fit your style and focus.


Should I consider an Android Wifi sharing network as trusted? I frequently browse on my laptop through an AndroidAP network. The Windows firewall considers it as untrusted, as it does with every Wifi network by default.

Is this network accessible from the Internet ("accessible" as "accepting random incoming connections"), or does it already have a firewall so I can set it as a trusted network in Windows ?

This is a WiFi Access Point, not different from the one you may have at home, at an airport or at a café. It just bridges the GSM data capacities of the phone with its WiFi - allowing you to go from one to another.

This means that it is, from the perspective of your laptop, untrusted - like any other network before you make it trusted (because you own it (your case), know that it is correct, is a company WiFi, etc.).

It is yet another access point to Internet for your device, so you must decide how much trust you put in in (in your case, probably a lot).

From the technical perspective, you should protect this access point so that only entrusted users can access it. This means using WPA2 with a strong passwphrase and an up-to-date Android.


How to detect arp spoofing using iptable? How can I set iptables to detect arp spoofing on linux?

You can't. The iptables command is an interface for the netfilter module of linux. Its used to block, redirect,... traffic not to detect MITM attacks. You can detect arp spoofing using a Network Intrusion Detection System (NIDS) like snort for example.


Javascript Valuable Webpage Data When malicious users and attackers seek to steal data using XSS, they can send attributes like document.cookie to a malicious server, correct?  Does this attribute have all of a users cookies for a particular website or just one for the specific site the page has visited?

If writing a blacklist, what other attributes can an attacker find valuable besides page cookies?

In this particular case it would only have the cookie data of the website.

The idea of an XSS attack is to get a website the attacker does not control to embed arbitrary Javascript code in a way that when a user opens the website that Javascript is executed by their web browser as if it were normal Javascript embedded in the website. This can be used to gain access to any data which is available to Javascript executed on that website. Javascript can only access the cookie data of the domain it is executed on (and only those which do not have the http-only flag set). It is not possible to use Javascript alone to obtain cookie data from a different domain.

Regarding what other data an XSS attack can find: It can read the content of the HTML document it is executed on. So when the html document with an XSS vulnerability also includes any other personal information, that information can be extracted and sent to the attacker.


How to categorise web vulnerabilities in a report? What is a good way to categorise the vulnerabilities in IT security reports. Assuming it's about a web-based environments like:

Websites,
Web applications,
Web shops,
Any interface using web-technology and is accessible using a browser.

I'm currently using the OWASP top 10 from 2013 and optionally adding an extra category "other". Any thoughts on good alternatives?

This is highly opinionated and controversial, but I wanted to provide food-for-thought for you to make your own decision.

There's OWASP, CWE, and WASC. I don't like any of them.

Why shouldn't I use any of these categorization methods?

OWASP Top 10 attempts to provide a most common list at a high-level view of what has happened in the last two years. But when you are creating technical reports, attempting to map vulnerabilities to these high-level categories leaves a lot open for interpretation and a lot of room is left for things that don't fit.

Take these examples:

https://bounty.github.com/researchers/bburky.html
https://bounty.github.com/researchers/joernchen.html

"Mercurial remote code execution in Importer" - Missing Function-level Access Control? According to OWASP, that's not appropriate. https://bounty.github.com/classifications/missing-function-level-access-control.html even says it is for controlling access to sensitive data, not for preventing arbitrary code from running.

But there's more.

"Git LFS code execution" is put under "Other." "GitHub for Windows remote code execution" is under Injection.

What do these three have in common? They are code injection. But under these OWASP mappings, they are three different things. Does that make sense to a manager that has to review your report? Call it what it is - Remote Code Execution. How it came about, how to fix it, those are separate things from what the problem is, the problem is executing arbitrary code or commands.

Why should I use these categorization methods?

Mapping to some parent categorization can make reporting easier when providing how often the organization encounters XSS or other problems.

Final word of caution

The industry has some problems to fix, and I think this is a big one. 10 categories is not enough for mapping. 25 categories is getting better, but your organization may be more targeted for mobile applications with web API endpoints, for which categorizing as "Injection" doesn't work as well as categorizing as LDAP injection, or something else.

The choice is of course yours, but over the years, this is what I've learned.


Is it safe to commit ascii-armored symmetric private key to VCS? What is the risk of committing an ascii-armored symmetric private key to VCS where the password lives outside of source control?

This is a private closed-source repo.

Two helpful topics:

When can I commit a Private Key to source control?
Is it bad practice to add an encrypted private key to source control?

I would strongly recommend AGAINST it ...

Passphrase on a SSH key isnt meant to protect it indefinitely ... it simply buys you time. If you brute force a password on a program or website it could lock you out after a specific number of tries.  It could also notify the powers that be that someone is attempting to break in.  A SSH Key is simply a file though ... if someone obtains it they can throw rainbow tables at it all day every day for years if they want to and then it is no long and IF they crack it but WHEN.

this picture is outdated, but it gives you an idea of how bad of an idea it is ... the fact that the picture is outdated should give you an even better idea

https://www.grc.com/haystack.htm


Can an ISP see hostname of VirtualBox I know ISP see the hostnames of devices connected to them
Does ISP see the hostname of VirtualBox Machines ?
Also do they see MAC address of Virtual Machines ?

TL,DR: Don't worry, your VM's MAC/Hostname/IP are safe from your ISP.

Your ISP knows the MAC of the modem/router connected to their network, the WAN IP of this router, and nothing else. Anything from your internal network is hidden from them.

Who can see the MAC and hostname and IP from your virtual machines? It depends on your virtual machine network settings. If the virtual network card is defined as bridge, anyone on your local network can see it. If you define as anything else (NAT, host-only, internal network), nobody can see anything but your host.

No matter what, MAC addresses are visible only on the local network. Local MAC addresses don't travel outside of your network. This question have a lot of info on MAC addresses, so you can get a lot of useful knowledge.

Hostnames are only a matter of convenience. You don't want to call your computers by IP address, so you give them any name you want. And outside your network, they don't make any sense either. If your desktop is called darkbox, nobody outside of the LAN can know anything about it, like IP or MAC. Even if MAC and IP addresses on the local network means nothing elsewhere. Probably your computer have an IP from the 192.168.1.0/24 network, like almost everyone else.


Are these gpg commands identical? I've found gpg -c < unencrypted_file > encrypted_file this command from https://askubuntu.com/questions/27770/is-there-a-tool-to-encrypt-a-file-or-directory this page, but in gpg manual it says gpg --output test.gpg --symmetric test.out something like this. I couldn't find anything about first one is an alias on the manual page so i want to see is there a difference and tested like this:

create 500Mb file first

  dd if=/dev/urandom of=./tmpfile bs=1000000 count=500

  time gpg -c <tmpfile> file1 (19 secs)

  time gpg --output file2 --symmetric tmpfile  (21 secs)

  time gpg --output file3 --symmetric tmpfile  (21 secs)

  time gpg -c <tmpfile> file4  (20 secs)

second command seems a bit slower to me, is this because of coincidence or are these commands different?

edit: gpg version is 1.4.20

Yes, these commands are effectively the same:

gpg -c < file > file.gpg
gpg --output file.gpg --symmetric file

First, -c is just a shorthand for --symmetric:

 -c, --symmetric             encryption only with symmetric cipher

Also note that the characters < and > are used in Bash for I/O redirection, they are not part of GPG's option syntax.

What's going on here is that GPG can take input from either stdin or a file specified as an argument. Instead of giving the filename as an argument, < FILE just feeds it via stdin. When GPG notices that input is given via stdin, it will print the output to stdout by default instead of creating a file (unless you use --output). So you can just redirect stdout with > FILE to write the encrypted data to a target file.


Win2012R2 TLS1.2 Mutual authentication - change cipher specs from server side after no certificate from client? I am testing a .net based application running on a Win2012r2 server providing a http-based web services and relying on windows's SChannel for implementing tls1.2 mutual authentication against tls1.2 only capable clients.

Mutual authentication has been working so far very nicely (client certificate are properly validated against the list of trusted issuers defined and active on the local computer certificate store).

Yesterday I came across the following scenario that somehow puzzles me:
even if the client is presenting a certificate length of 0, the handshake seems to be technically successful and does not result in an Handshake Failure or an Handshake alert:

(on server side) Server Hello, Certificate, Server Key Exchange, Certificate Request, Server Hello Done;
(on client side) Certificate, Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message (however the test client is not providing any client certificate - client certificate length of 0 - during the handshake);
(on server side): change cipher spec, Encrypted Handshake message;

Why is the Server side not terminating the handshake (Handshake failure or alert) after getting no client certificate ?

Could it just be the way that wireshark is interpreting / parsing the handshake process ?

Is this something configurable / tunable at SChannel level or can only be adjusted at application level ?

It is fully valid that the client responds to a certificate request by the server with an empty certificate. It is up to the server how to deal with this case, i.e. if it will treat a client certificate as optional or if the certificate is required.

I'm not familiar with SChannel but with OpenSSL you can set SSL_VERIFY_FAIL_IF_NO_PEER_CERT in SSL_CTX_set_verify if you want to make the server fail if no client certificate is send if you set SSL_VERIFY_PEER only than the client certificate is optional.

SChannel has probably a similar mechanism but it is up to the application to use it. Thus look into the configuration of your HTTP server. In case of IIS this is described in the documentation which says that you can configure client certificates to be ignored, accepted or required by the server.


Theoretical home grown password options, or what is it that SCrypt, BCrypt, PBKDF2 does that is so special? I'm developing a personal web framework, nothing internetty, and probably not even anything that will ever go on my personal LAN. And looking for password advice people seem to only recommend those libraries in the title. I'm doing this to learn security from a development perspective, and again, I'm aware this isn't best practice I want to learn by implementing it myself (and hassling the community with relentless questions).

Currently my routine does 4096 rounds of salted SHA512 (a number plucked out of thin air - I'll concede thats one thing they probably have sorted) like so:

string randomdatabasesalt = "whateverdatabasesalt"
user = "username"
string password = "whateverpassword"
for (int i = 0; i < 4096; i++)
{
  password = SHA512(user + randomdatabasesalt + password);
}
store (user, password);

Now if I feel the need at a later date I can add more rounds to everyones hash (pre-breach of course) and can strengthen it without anyone needing to reset passwords, all reasonably easily. Or if SHA2 becomes completely broken with regards to cracking speed, I can rehash those hashes and add it into the routine with noone being any the wiser though that may be an undesirable waste of cycles.
So whats wrong with this approach - other than the random rather than computed selection of rounds? Is it just the lack of peer review or do the aforementioned libraries do something I'm not taking into account?

Secondary question, would adding the salts each pass somehow weaken the hashing? Is it better to salt just the initial hash then loop through? Example:

string password = "whateverpassword"
password = SHA512(user + randomdatabasesalt + password);
for (int i = 0; i < 4095; i++)
{
    password = SHA512(password);
}
store (user, password);

Well, it is a mixture of "no peer review" and "something you do bad". The thing you are (apparently) doing poorly is your salt selection: you call it "randomdatabasesalt", which hints at the idea that you would use the same salt value for several hashes, if you had to store several password hashes (e.g. because your framework has several users). This is a sin: it voids most of the reason why you would use a salt in the first place. Salts should be per-instance: each user should have his own salt, and the salt must be changed when the user changes his password.

As for the rest: anybody can create a cryptographic scheme that he cannot break. The hard part is to create a scheme that nobody else can break it either. The really hard part is to make sure that nobody else can break it (because we want security, but we also want to sleep at night).

Cryptographers thus rely on peer review and slow-paced development. When they want to design a new function, they organize a competition in which people are encouraged to submit candidates, complete with specification, test vectors and reference implementations; and then they spend some time (years) to try to break each other's creations. Survivors are then deemed "probably secure". This is what was done for AES and SHA-3, for instance. And, right on cue, there is an ongoing competition for password hashing functions.

This presentation is a nice introduction on password hashing, and lists some features that good password hashing functions should have. Have also a look at that answer.

(One way of designing cryptosystems which does NOT work is a fast comment-modify cycle. It usually happens as a dialogue between a wannabe designer, and an amicable and knowledgeable cryptographer. The designer, full of zeal, will submit an endless stream of minor variants of his scheme, each adding some random construct to answer to the last comment from the cryptographer. This always ends up with the cryptographer being fed up and ceasing to respond; the designer then claims victory and writes a colourful Web page, and then fails to become rich overnight when the rest of the World does not acknowledge the genius of the new algorithm.)


Do readers for the "Mifare DESFire EV1" smartcard really need to know the card's secret key in order to authenticate the card? I'm trying to understand the security of a contactless smartcard system, used for access control and payment. The card is a Mifare DESFire EV1 implementing ISO 14443 (see the this documentation collection).

I've read about side channel attacks targeted on extracting the private key from the smartcard (see Side-Channel Analysis of Cryptographic RFIDs with Analog Demodulation). They were successful but appear to be quite difficult to perform.

As I understand the authentication process of such cards, the reader and the card  must both prove their knowledge of the secret key by a challenge-response procedure (the protocol is not public but has been reverse engineered in the paper Cloning Cryptographic RFID Cards for 25$ in chapter 3.2.). So all the reading devices must know the secret key, too. But there can be many readers from many vendors (e.g. coffee machines, small USB readers at cash registers, access control panels…), do all of them really have the secret key? Is there a standard on how the key has to be stored? It may be possible in some cases that the cards are authenticated over the network but I know that some of the devices work offline.

I'd expect them to be a quite promising attack vector, as coffee machine vendors generally don't care much about security. Are there any papers describing a successful attack? Or is there just a similar chip in any of these readers where the key is stored in the same way?

Edited:
OK. As there is request for "short answer" here is "executive summary" here it is:

Question: “So all the reading devices must know the secret key, too. But there can be many readers from many vendors (e.g. coffee machines, small USB readers at cash registers, access control panels…), do all of them really have the secret key? Is there a standard on how the key has to be stored?”

Answer: “Yes. Apart from remote/server initiated communication with DESFire card, all readers has to know secret keys too.
And Yes – there is standard on how the key has to be stored – use of Secure Access Module – MIFARE SAM (currently AV2 model).

All content below you can forget if not interested ;)

There are basically two families of MIFARE cards: MIFARE Classic and DESFire (and similar derivatives).
Additionally there is MIFARE Plus, which has been targeted initially at MIFARE Classic markets (which it fully supports, if configured to do so), has two additional security modes of operation, which add more security to MIFARE Classic infrastructures up to a level similar to DESFire.

There are many authentication protocols used among those MIFARE families, some are quite similar but sometimes differ in small details, which may lead to reading infrastructures NOT being capable of handling another protocol even if they look very similar at first…

What is more important to your question about DESFire EV1: the basic approach for reader side security is the usage of so called "Secure Access Modules" (SAM), which are specialized smart cards, providing security related functionality to the readers/terminals. The SAM holds all keys and also has an engine to conduct security protocols, used within the secure communication between the card an the reader. This is the anchor of reader security in terms of DESFire EV1 usage. The keys might me also be derived individually for each card, so they do NOT use the same key for all the of card's authentication and encryption protocols. The key in a SAM module can be securely uploaded to the SAM in field by using additional encrypted protocols from the host OR by a batch offline upload (from an USB stick for example).

Some RSA based protocols are also supported for signing/verification to ensure some actions are authenticated without the use of shared keys protocols.

The SAM is cleverly planned and pretty solid in terms of security, so putting such a SAM module in a vending machine supports all security requited. Even a DESFire card modification, initiated by a remote host, can be securely established as the SAM can act as a “secure proxy” by establishing a secure channel towards the host and another one towards the card, providing a “re-encryption proxy” in the middle. Of course SAM is standard card being “client” and any command exchange, so the reader has to support those protocols by sending, receiving, forwarding APDUs between participating parties.
The SAM also supports direct connections to the reader's chip, acting as a transparent proxy.

It supports 2DES, 3DES, AES, CRYPTO1, RSA, and some proprietary variants of standard algorithms.

SAM has even cleverer concept of “operation counters”, which helps to address the security threat of being stolen and used frequently: each operation decreases a counter. The counters must be periodical increased by a host initiated action, online or offline. Encrypted and signed “scripts” must be brought to the SAM in a way (e.g. USB stick). The keys can be also versioned to support secure roll over of keys during the system lifetime.

The SAM itself has access control logic, based on strong cryptography, to enforce the designed security model. A carefully planned and designed Key Management scheme, supports secure key distribution among the system's many players. Usually, the initial SAM content is distributed by a secure SAM personalisation and controlled delivery to appointed participant (like vending machine vendor), who already has some authentication keys to get initial access to allowed SAM/DESFire card operations. One of typical operation can be authentication keys exchange IF those keys are assigned only to particularly player.

Another comment to UID, its cloning and so on: modern MIFARE products support separate commands to access a RandomUID, to be used in anti-collision protocols, and a static UID to identify the card (optionally also protected by authentication and encryption protocols providing a “secure channel”). This gives to system designers the proper tools to enhance protection against UID cloning or emulation. But many “security designers” are quite lazy anyway and don't use those possibilities even if they exist…


SSH key strength factor besides key length (say ed25519 vs rsa-4096) I am not of the field of IS but I want to secure my humble VPS and I cam across a clashing of opinions between 3 IS guys: 2 say that ed25519 ssh keys are a bit more secure than ssh-rsa of 4096 bytes and one says that in our era, there isn't a significant different at all and either will be just fine for me.

While I don't know who's "right", I went to do some limited reading (limited as I don't have the knowledge to fully understand every passage I read on the subject), and I found out by all that has to do with bytes, public ed25519 keys have much fewer bytes than public ssh-rsa 4096 keys, and hence their private keys are also much shorter.

My question can hence be comprised of the following two questions:

If so, and I'm sorry I think you I need to go and learn 6 months of cryptography --- How are these more secure? I am feeling there is another criterion for their alleged superiority here, and it's not just the amount ob bytes. It's something with formatting.
If it's is only formatting, couldn't we implement this formatting to ssh-rsa 4096 keys? I mean if ed25519 keys contain about 90% less bytes, and we implement their special formatting to ssh-rsa 4096 keys, couldn't we create the most powerful ssh public key ever until now?

Right, welcome to a crypto-nerd battle. Let's try and break this down.

Key length: ed25519 is from a branch of cryptography called "elliptic curve cryptography (ECC)". RSA is based on fairly simple mathematics (multiplication of integers), while ECC is from a much more complicated branch of maths called "group theory". In short: ECC keys can be much shorter and give you the same security level because the mathematical problem they are based on is much more complex. This is far deeper than formatting differences. That's a bit like saying that index cards at the library vs google is a formatting difference.

Security: people tend to like ECC over RSA because the keys are smaller and the computations are faster for the same security level. Below is a table showing the security level comparison of RSA (labeled as Integer Factorization, or IF) vs ECC [source]. You can see that ECC keys really do get the same job done with a smaller key.

So you want to compare RSA-4096 (not in the above table) against ed25519 which has ~ 140 bits of security and is comparable to ~ 3000 bit RSA according to its inventor. Remember that bits is a log scale: 129 bits is twice as secure as 128 bits; 140 bits is 212 = ~4000x as secure as 128, so RSA-4096 might win, but really, anything above 128 bits of security is overkill unless you happen to be a military organisation or a bank.

For putting thumbtacks into your wall, should you use a sledgehammer or a wrecking ball? The correct answer is: whatever.


possible to exchange public and private exponent in RSA? We are implementing https with a third-vendor SSL library in our embedded system. Because of the chosen small public exponent in RSA 2048, encryption is much faster (approx 120ms) than decryption (approx 3100ms).

Could we exchange the public and the private exponent after key generation? That would shift the heavy lifting to the client (usually a PC) and makes it easier for our embedded system. I don't know, if there are some restrictions e.g. in certificate structure what forbids this.

Exchanging the public and private exponents in RSA incurs two problems:

It does not work.
It is insecure.

The "does not work" is about existing deployed implementations of SSL in clients. Though the formal definition of RSA allows for an arbitrarily long public exponent, some widely deployed implementations of RSA expect the public exponent to fit in a 32-bit integer (in particular, Windows' CryptoAPI).

The point about insecurity is that a too short private exponent weakens the system. An attack has been demonstrated, which shows how to recover the private key if the private exponent length is less than 29% of the modulus length; this means that if you use a 2048-bit RSA modulus (as you should), and you set the private exponent length to less than 600 bits, then an existing, already described an implemented attack applies. The collective wisdom of cryptographers is that private exponents significantly shorter than the modulus are too huge a risk.

Therefore: no, you should not try to shorten RSA private exponents, however tempting it may be.

If you are short in computing power, then you might want to investigate alternative algorithms based on elliptic curves. An "ECDSA_ECDHE" cipher suite would avoid RSA computations, and should provide substantially better performance for the TLS handshake (however, it won't be compatible with IE 8 on Windows XP as a client).


Protecting my high-value passwords against offline attacks Summary

I'm a LastPass user, but I have concerns about storing high-value passwords, like my bank password, online.  I've read some posts on this topic but still have questions.

How safe are password managers like LastPass?
Does the average user really need a password manager?
Is saving passwords in Chrome as safe as using LastPass if you leave it signed in?

Threats

I'm looking for a solution that addresses the following threats (LastPass handles #2 and #3 but not #1):

The attacker gets my encrypted passwords and has enough resources to break my passphrase.  The attacker decrypts my online banking password offline, logs in, and steals all my money.
The attacker tricks me into entering my password on a different site than I intend (phising).  The attacker gets my online banking password, steals all my money.
One of my high-value accounts gets compromised.  The attacker uses my password there to guess passwords to my other high-value accounts.

I have 4-5 online accounts that I consider high-value enough to be worried about these threats.

Questions

First, are there any more important threats that I'm overlooking here?

Second, how can I address these concerns?  I was thinking of having a password manager store a random salt for each high-value account, hash this salt with a "master" password, and use it as the real account password (a bit like PwdHash).  Neither the real account passwords not the master password would be stored anywhere (encrypted or not).  This seems to force the attacker to try their password guesses against the online service, rather than being able to break them offline.

Note that this "master" password, which is used to derive the account passwords is different from the lastpass' "master password/passphrase", which is used to encrypt the stored data.

Does this scheme address the threats above?  Any software that implements this for Chrome on Linux?

I've used both KeePass and LastPass, and I'll share some of the things I found helpful when deciding to use a web-based password manager.

There's a paper by some folks at Berkeley who analyzed various online password managers. This link points you to that paper. LastPass fixed the bookmarklet issue.

For threat #1: A strong master password (read: long and random) should not be crackable, assuming that the password manager developers did their job properly. I have to rely on the crypto pros to make that evaluation.

Now that LastPass has been hacked I guess I'll get to find out if they did.

For threat #2: Phishing threats are very real and can defeat 2FA (see this Brian Krebs piece). I don't see how LastPass avoids the kind of attack Krebs describes. He recommends banking on a live CD to avoid system compromise.

For threat #3: don't re-use passwords.

If your major concern is that someone might get your encrypted password database, then you're somewhat more secure with KeePass or other local solution than with LastPass. However, that's not total protection. If your system gets compromised, or you get phished, local storage doesn't protect you.

The threat I think you're overlooking is this one: do they even need your password to get into your bank, etc? Matt Honan wrote about this.

If there is an easier way into your bank account than brute-forcing your database password, then that's the threat you need to worry about. I hope the links I provided were helpful.


Is the Extended Key Usage extension mandatory on the web? Do web servers reject certificates that do not have an extended key usage with TLS WWW Client Authentication set (if client authentication is required)? Similarily, do Browsers reject certificates that do not have an extended key usage with TLS WWW Server Authentication set? The Extended Key Usage is often flagged as non-critical so theoretically implementations MAY ignore it but the question is whether most implementations require an extended key usage to be present?

Also... where exactly is specified what these two key usages mean and what implementations must do with it? https://tools.ietf.org/html/rfc5280#page-44 does not really specify the meaning behind these key usages (except for what the name TLS WWW Client/Server Authentication already tells you).

For client certificates, see this post. It contains evidence that the NSS library invalidates client certificates which do not follow RFC 5280, Section 4.2.1.12.:

  This extension indicates one or more purposes for which the certified
  public key may be used, in addition to or in place of the basic
  purposes indicated in the key usage extension.  In general, this
  extension will appear only in end entity certificates. [..]

  If the extension is present, then the certificate MUST only be used
  for one of the purposes indicated. [..]
  Certificate using
  applications MAY require that the extended key usage extension be
  present and that a particular purpose be indicated in order for the
  certificate to be acceptable to that application.

For server certificates, it is not that clear. The CA/Browser Forum Baseline Requirements do not specify a policy regarding these usages for end-entity certificates.

According to the above RFC excerpt, applications can optionally impose requirements on the EKU extension in certificates. I can only think of OpenVPN as an example (when using X.509 certificates for authentication). With OpenVPN, the client and server certificates are usually signed by a single CA. By using the TLS Web Client Authentication or TLS Web Server Authentication EKU, it can prevent clients from impersonating servers using their own client certificate.

As for the meaning behind these key usages, the name is pretty self-describing. To understand the background, read Section 2 (Requirements and Assumptions) of RFC 5280.


How secure is a Windows PC that is routed through a Linux PC? I have a Dual PC setup. Two PC's are networked together via crossover cable. The Windows PC is running Windows 7 SP1 64-bit and the Linux PC is running Slackware 14 64-bit with iptables.

My firewall and routing is essentially:

{DROP All protocols and ports}
{ACCEPT specific protocols and ports}

# Rules to route from Windows PC to Linux PC
$IPTABLES -A INPUT -i eth1   -s 192.168.1.10   -m state --state NEW  -j ACCEPT
$IPTABLES -A FORWARD -i eth1   -s 192.168.1.10   -m state --state NEW  -j ACCEPT
$IPTABLES -A FORWARD -o eth1   -s 192.168.1.10   -m state --state NEW  -j ACCEPT
$IPTABLES -t nat -A POSTROUTING -o eth0   -s 192.168.1.10  -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward

{DROP everything not contained in any of the above rules}

Assuming that the Windows PC is virus-free and/or hypothethically invulnerable to viruses/trojans/backdoors etc., how secure would the Windows PC be with a properly set up Linux firewall?

Would the Windows PC still need a firewall?

In the scenario you describe, your Linux box is essentially acting as a network firewall for your Windows machine. So your question basically boils down to "Do I need a host-based firewall if I am already using a network firewall?"

The answer to that question is no, you don't need one. However, it would be helpful to use one. See the concept of Defense in depth.

A good explanation on what host-based firewalls can do compared to network firewalls can be found in this question.


What information to provide when submitting a vulnerability report to a bounty program? After finding a vulnerability in a program, one can submit it to a bounty program, such as ZDI. According to ZDI's website, they will examine the vulnerability and possibly offers a bounty. If the researcher does not accept the offer, they promise not to use the vulnerability information. However, I guess some people might not completely trust the bounty program and would like to provide limited information in their submission.

My question is, what is the general practice for providing information to/negotiate with a bounty program? I am thinking about providing software version, OS version, general description of the vulnerability and some proof, such as the info at crash and analyze results by tools like !exploitable Crash Analyzer. However, although the bounty program such as ZDI encourages the researcher to submit a PoC, the PoC will basically disclose the vulnerability entirely. Thus, the PoC will not be included at least in the initial submission.

Please provide your answers and comments regarding this issue. Thank you!

ZDI, and other similar programs WILL NOT accept anything without reporting on the full vulnerability. There is no sanitizing data. You either trust them, or you don't. Sample applies for all programs listed on BugCrowd. With ZDI, this is what I found has worked best to minimize the amount of time you'd need to wait:

Full detailed report of the bug
Proof of concept
Troubleshooting (step by step guide to exploit including debugging)

What ZDI and others do, is take a look at what you're submitting, and go through the process of validating this. The Proof of Concept is not required, since their staff can make their own PoCs but it minimizes the amount of time spent waiting.

Troubleshooting output (e.g., WinDBG, OllyDBG, ImmunityDBG) helps them in seeing what is affected (EIP, EBX, ECX, etc) when something is overflowed for example. It isolates address space, or illustrates what you did for something like nopsledding, etc.

Now I infer that you're concerned that you will submit something, they will offer minimal, you'll say forget it, and they will go ahead and report it/fix it/etc it anyway. This is not the case hence you signing a non-disclosure agreement with them. So again:

Vulnerability - needed to determine the extent of potential damage if
X occurred
PoC - not necessary but helps proving exploitation against an
application
Debugging/troubleshooting data - aides in illustrating what, how, and
why something got exploited

There is no "partial" submission since they will be spending MONEY (time, resources) to figure out what the issue (if any is). Not chance any theories. The amount of money they offer, is based on how widespread the application is in use (e.g., Microsoft exploits command big bucks versus say MyRandomApplication.exe).


Which factors should you take into account when deciding whether users should be informed of a penetration test? Say you are conducting a penetration test of an internal network. The internal network comprises of workstations, servers and company and contractor laptops.

In an ideal world, the penetration test would just go ahead, simulating what an attacker would do given access to the local network. However, sometimes it is wise to let users know ahead of time.

Advantages include minimal disruption to business processes because users can inform their managers if the testing is likely to interrupt their work or cause other problems.

Disadvantages of informing users is that they may act differently than they would normally. For example, they may disconnect from the network, or they may disable software or enable firewalls that weren't usually active, affecting the results of the penetration test.

Which factors should you take into account when deciding whether users should be informed of a penetration test?

In the UK, law is a strong factor. The Human Rights Act 1998 states:

  Everyone has the right to respect for his private and family life, his
  home and his correspondence.

So if any users that are caught up in the penetration test have an "expectation of privacy", then you are required by law to inform them prior to any testing. Note that just because they are in the UK does not mean they have an such an expectation - this would be down to the company's policies (e.g. Acceptable Use policy and Internet and Email Access policy) and contract of employment.

This page is a useful resource regarding pen testing and UK law.


Dotdotpwn - Different text patterns I have perhaps a fairly straightforward question about the tool dotdotpwn.

Firstly, it seems like an awesome tool for generating the beginning of a directory traversal string, and the fact that it detects the OS and tailors itself accordingly is great - the trouble I am having is trying to figure out what text string I should use if the server is a Windows server?

I get that "root" is a good string for Linux as it tests for /etc/passwd, but I am struggling to find a good string for windows. I tried a few different ones, and it seems to struggle with characters such as [ and ] that I seem to find in examples of a boot.ini file. Can I just use "boot" as the first line seems to be [boot loader]?

I'm not sure if I am missing something fundamental here,
   Cheers!

It depends on the file you're trying to match. By default dotdotpwn does not require string matching (-k). It is required if you specify a specific file to look for or you are experiencing false positives. As a general rule I tend to look for c:\windows\win.ini as this file is present on all versions of windows unlike c:\boot.ini. By examining a known good win.ini file you can look for a keyword you like, otherwise -k 'mci extensions' should do the trick.

You didn't give an example of the commands you wrote so I'll just guess that you didn't correctly quote or escape the [, ] or space characters. Dotdotpwn will match on the word boot, without the brackets, but a more accurate match reduces the likelihood of false positives.


What allows for reinfection of the same PUP after quarantine and removal? I use an antimalware program- the scan finds a PUP (Potentially Unwanted Program), which is quarantined and removed. It comes back! I am guessing it is stored somehow to resurface after normal shut down and reboot. Where can this be hiding out? Someone suggested Google Drive? PUP's location in file says C User (my Wife) App Data Local Google Chrome User Data Default Extension then a string of random letters. It found this same instance 40 times of the same PUP on recent scan, but I thought this was taken care of when I first found this along time ago. I can find the same string of letters if I search verbatim in Google search. Google Forum said: I'd recommend running a scan on your computer with a trusted anti-virus software. If the scan detects any suspicious programs or applications, remove them immediately. Which is what I have done over and over..

If the program is in Google Chrome's User App Data folder, it is probably being downloaded as a temporary internet file.  Every Time a user browses a website, the page is downloaded to that folder.  So either your wife has downloaded multiple versions of a malicious file, or she keeps going to the same page to download the PUP.  To eliminate the possibility there are just a lot of instances of the file, try deleting Google's entire folder in App Data and restarting the browser.

Other more advanced techniques could include a root kit, or a malicious version of chrome, but these are less likely.


Is return oriented programming applicable to pure Java code? I'm interested in ROP in the context of Java. For now, I don't consider the native code of the Java virtual machine.

Is return oriented programming applicable to pure Java code?

In "pure Java", there is no buffer overflow or use-after-free or double-free or anything like that. This is what the "VM" part of "JVM" is about. ROP is something that you use to leverage an initial breakage whereby you succeeded in overwriting the "return address" for some function, and induced the CPU to jump where you want. By definition, these conditions cannot arise in "pure Java", so ROP is irrelevant. It cannot happen.

Of course, if the JVM implementation has an exploitable bug, or if native code is invoked, then everything about buffer overflows comes back. But then, you are talking about using ROP in some C/C++ code, and no longer about Java.


Can my physical location be detected with double VPN? My company's laptop has a VPN installed that connects to the company's network. No other VPN software can be installed. However, I have a VPN router that has ExpressVPN installed so all devices connected to this router has VPN connection.
If I am out of state or in another country and set my location to my home state in the VPN router, then connect to my company's network, can my physical location be detected in anyways?
I have disabled the browser location.

If you connect to the company VPN through your routers VPN the source IP seen by the companies VPN is the exit of your routers VPN. This way your company will not see the real IP address, assuming no other leaks exists.
But, the company will see the properties of the IP address from the VPN exit. It can find out that it is not an IP address given by your ISP. It might even be able to associate the IP address with a given VPN provider (i.e. ExpressVPN in your case). Thus, it might not know where exactly you are but it can deduce that you attempt to hide your real IP and that you are therefore likely not at home.


How to secure android REST basic authentication credentials against reverse engineering? As far as I know, in basic REST API authentication, username and password to access web service resources are baked into the app's code.
On the other hand, it seems not difficult to reverse engineer an app's .apk file to get the java code containing the REST credentials.

So I'm wondering if there are ways to secure the credentials against reverse engineering revelation?

The best practice is to not store the access credentials within the program. Apps do not always contain (unless they are badly designed) any specific credentials within themselves to access the API.

While adding credentials into the code may deter general attackers it will not stop attackers who can open up the package and extract the details. As something that can be cracked by a few is considered vulnerable too the right way to implement it would be as follows.

Add not credentials into the APP
When the APP is installed generate credentials and register with the server. (could be username and password or could be a client side certificate)
Obtain an access token using these credentials.
Use the access token to access the API

As you can efficiently control the registration process and can permit access to secure parts of the API based on the access token your implementation should be secure enough if you use SSL/TLS for them.


Preventing insecure webapp on subdomain compromise security of main webapp I want your help on getting more concrete information on a type of vulnerability that I remember vaguely.

I vaguely remember hearing about a year ago that if you set up a webapp on a subdomain, and that webapp gets compromised, then your main webapp (on the root domain) could be compromised as well, because (and this is the part that's vague in my memory) the browser has some assumptions about the two different webapps being the same entity because they're from the same root domain.

I heard that this why Facebook originally hosted their developer forums on a different domain instead of a subdomain of facebook.com; because the forum app was far, far less extensively audited for security problems than Facebook itself, and they didn't want any security holes in the forums to allow an attacker to gain access to Facebook itself.

(To clarify, these attacks are based on the browser, not on some kind of connection between the two servers.)

My question: Do you have the specifics of what those vulnerabilities are and how I could protect against them so I'd be confident that an attacker getting access to one webapp couldn't get access to a different webapp on the same root domain?

This sounds like an insecure cookie scope.  If the application is scoping its cookies to .domain.com then XSS in a sub-domain can lead to an account compromise.

As long the applications are on separate servers, they are not sharing the same database account and cookies are scoped properly there shouldn't be a concern.


Attack against OTP Cipher What would be an attack against an insecure instance of the OTP cipher given two challenge ciphertexts using the same key in order to get the plaintext? I've tried to implement some approaches with Python but it did not work.(I'm a beginner in cyber security)

How does a One-Time Pad work?
Imagine you have a message M which is encrypted with a key K, which then results in a ciphertext C. Let us assume that the process through which the encryption occurs is an XOR, which I'll show by the ^ symbol. Furthermore, we assume M, K and C all have the same length. So we know:
M ^ K = C

Assuming an attacker has access to C and wants to recover M, this is cryptographically impossible. Why? Because even if an attacker tried every single possible key K, they would receive every single possible message M'. It is impossible for them to tell which is the correct message. In fact, they could simply look at every single possible message of that length and they would not be any wiser.
However...
Why is it called One-Time Pad?
Because the same key can only be used once. If you use it twice, certain issues arise.
Let's take the same scenario as above, but now we have two messages M1 and M2, one key K and two cipher C1 and C2.
M1 ^ K = C1
M2 ^ K = C2

The curious thing about XOR is that it is a "reversible" operation. That means XOR'ing something with the same value twice results in the original value:
X ^ X = 0
X ^ 0 = X

therefore

X ^ Y ^ X = Y

Order of operations does not matter, just like in addition. Let's assume that the attacker has C1 and C2, but not access to M1 and M2.
C1 ^ C2 = (M1 ^ K) ^ (M2 ^ K)

Since order of operations does not matter, we can remove the parenthesis and group the K together:
C1 ^ C2 = (M1 ^ M2) ^ (K ^ K)

We learned above that a value XOR'd by itself is 0, and that a value XOR'd by 0 is itself. As such, we can simply remove the right parenthesis and get:
C1 ^ C2 = M1 ^ M2

This means that you now have access to two plaintext messages XOR'd to each other. This is a lot more information than just the ciphertexts.
How can I go from there?
Let us assume that a message is only uppercase ASCII and spaces, and you know the following:
     C1 = 55 3a 90 26 b3 b6 48 37 6f c1 45 f7 e8 47 61 78 21 52
     C2 = 42 33 97 55 ca b0 4e 37 61 ca 24 f9 e6 34 66 71 2f 44
C1 ^ C2 = 17 09 07 73 79 06 06 00 0e 0b 61 0e 0e 73 07 09 0e 16

At first glance, this may not seem to tell us a lot. After all, it's just some hexadecimal, right?
Well, if you look at the values in the last line, you see some low values and some high values. Let's look at the high values, the first one being 0x73, which is the ASCII value of the lowercase s. Why is this interesting? We know that it's the result of the XOR of the message M1 with M2, and both can only be uppercase and spaces. If you look closely at the ASCII value of a space, you see it's 0x20 or 0010 0000 in binary. Meaning that XOR'ing with a space only flips one bit. If you look at the ASCII table, you will notice that uppercase and lowercase characters also only differ by one bit. This was done so that "to Upper" and "to Lower", as well as "toggle case" functions only had to operate on one bit.
So we know the following:
Either of the following is true:

The fourth byte of M1 is S
The fourth byte of M2 is _
The fourth byte of K is 0x75

or

The fourth byte of M2 is S
The fourth byte of M1 is _
The fourth byte of K is 0x06

(Note that I am using _ to represent a space for better visibility)
We cannot yet tell which one of these is true, but we know they are mutually exclusive. If you have more messages C2, C3, etc. all encrypted by the same key, then you can simply determine which one is the one with the space, as all others will return either valid lowercase ASCII symbols or 0x00.
In fact, let's assume you intercepted a third message C3, with the value 4826f938d2a63b596dcc45f8e8347778354e
Now you know:
     C1 = 55 3a 90 26 b3 b6 48 37 6f c1 45 f7 e8 47 61 78 21 52
     C2 = 42 33 97 55 ca b0 4e 37 61 ca 24 f9 e6 34 66 71 2f 44
     C3 = 48 26 f9 38 d2 a6 3b 59 6d cc 45 f8 e8 34 77 78 35 4e

C1 ^ C2 = 17 09 07 73 79 06 06 00 0e 0b 61 0e 0e 73 07 09 0e 16
C1 ^ C3 = 1d 1c 69 1e 61 10 73 6e 02 0d 00 0f 00 73 16 00 14 1c
C2 ^ C3 = 0a 15 6e 6d 18 16 75 6e 0c 06 61 01 0e 00 11 09 1a 0a

This already gives us a bit more information. A lot more, in fact. First of all, let's have a look at the above hypothesis: We know either M1[4] is _ or M2[4] is _. Since C1 ^ C3 (and thus M1 ^ M3) does not result in a lowercase ACII character, we know both M1[4] and M3[4] are not spaces. Therefore we know that the first of our two hypothesized cases is true, and we know a bit more about the key and the other messages:
     C1 = 55 3a 90 26 b3 b6 48 37 6f c1 45 f7 e8 47 61 78 21 52
     C2 = 42 33 97 55 ca b0 4e 37 61 ca 24 f9 e6 34 66 71 2f 44
     C3 = 48 26 f9 38 d2 a6 3b 59 6d cc 45 f8 e8 34 77 78 35 4e

     M1 = ?? ?? ??  S ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
     M2 = ?? ?? ?? __ ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
     M3 = ?? ?? ??  M ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??

      K = ?? ?? ?? 75 ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??

C1 ^ C2 = 17 09 07 73 79 06 06 00 0e 0b 61 0e 0e 73 07 09 0e 16
C1 ^ C3 = 1d 1c 69 1e 61 10 73 6e 02 0d 00 0f 00 73 16 00 14 1c
C2 ^ C3 = 0a 15 6e 6d 18 16 75 6e 0c 06 61 01 0e 00 11 09 1a 0a

We can also see that M1[3] ^ M3[3] and M2[3] ^ M3[3] result in printable characters, so we know M3[3] must be _ and therefore K[3] = C3[3] ^ 0x20, which is d9.
After doing all of this, your grid should look like this:
     C1 = 55 3a 90 26 b3 b6 48 37 6f c1 45 f7 e8 47 61 78 21 52
     C2 = 42 33 97 55 ca b0 4e 37 61 ca 24 f9 e6 34 66 71 2f 44
     C3 = 48 26 f9 38 d2 a6 3b 59 6d cc 45 f8 e8 34 77 78 35 4e

     M1 = ?? ??  I  S __ ??  S __ ?? ?? __ ?? ??  S ?? ?? ?? ??
     M2 = ?? ??  N __  Y ??  U __ ?? ??  A ?? ?? __ ?? ?? ?? ??
     M3 = ?? ?? __  M  A ?? __  N ?? ?? __ ?? ?? __ ?? ?? ?? ??

      K = ?? ?? d9 75 93 ?? 1b 17 ?? ?? 65 ?? ?? 14 ?? ?? ?? ??

C1 ^ C2 = 17 09 07 73 79 06 06 00 0e 0b 61 0e 0e 73 07 09 0e 16
C1 ^ C3 = 1d 1c 69 1e 61 10 73 6e 02 0d 00 0f 00 73 16 00 14 1c
C2 ^ C3 = 0a 15 6e 6d 18 16 75 6e 0c 06 61 01 0e 00 11 09 1a 0a

Are we stuck now?
This is as much as you can infer with 100% certainty. Now you can start to make some educated guesses. For example, you can see that M2 there is a three-letter word starting with Y and ending in U. You can make an educated guess here and assume that means "you". And indeed, if we assume that, we'd get the following:
     M1 = ?? ??  I  S __  I  S __ ?? ?? __ ?? ??  S ?? ?? ?? ??
     M2 = ?? ??  N __  Y  O  U __ ?? ??  A ?? ?? __ ?? ?? ?? ??
     M3 = ?? ?? __  M  A  Y __  N ?? ?? __ ?? ?? __ ?? ?? ?? ??

      K = ?? ?? d9 75 93 ff 1b 17 ?? ?? 65 ?? ?? 14 ?? ?? ?? ??

The other characters seem to fit. M1 forms the word "is" and M3 forms the word "may". Since those are legitimate English words, you can be pretty certain that those are correct. Furthermore, note that some of the XOR'd messages result in 0x00, which means that these must be the same letter. For example, even though you don't know what M1[13] ^ M2[13] is, you know that both of these letters must be identical.
Keep going from there and see if you can crack the rest.


Is it safe to set up IP address to domain name redirection? We recieved the following e-mail with from one of the UI developers

  When we browser site with IP: http://x.x.x.x/, it doesn’t
  redirect to http://www.our_website_name.com. This could cause duplicate
  content problems if a search engine indexes site under both its IP and
  domain name.

  Can we set redirection from IP to domain?

Now, I don't see that any of the search engines have indexed our IP address and I believe that the chances of a search engine indexing an IP address is close to nil if there are no links floating around in the internet with the IP address instead of the domain name. My question is:

From a security point of view, is it safe to redirect an http request for direct IP address to the domain name?

I know how to deny/block or redirect if the request is for direct IP address and I see dozens of instructions online how to do it, but why do people do that? Can I go ahead and set up this redirection (IP address to domain name) with no security concerns?

From a security point of view, is it safe to redirect an http request for direct IP address to the domain name?

yes, usually it is no problem. if you are in super-paranoid mode you might follow the approach below.

Traffic that goes to the IP directly, even if there are domain names registered, are usually scanners and bots, and maybe, every now and again, a developer. Search engines don't access IPs directly, except when you have no domain names configured.

This is a quite legitimate catch-all setup for nginx that defines a response to any access that is not defined through a virtual-server-conf (it just returns HTTP Status 400):

server {

    listen 80 default_server;

    access_log off;
    error_log off;

    # basically just return an error
    return 400;

}


Securing a Ubuntu system on Amazon Web Services I'm in the process of setting up a Ubuntu server on Amazon Web Services / EC2, which will need to host the following:

A relatively simple Java-based website (using the Noir framework)
A Java-based web service and REST API
Some method of logging in remotely via SSH or equivalent so I can administer the server

Before I open it to the public, what are the key steps I should take to ensure this type of server is secure?

Have a read of the answers on the Hardening Linux Server question for guidance on the server part.

Using EC2 shouldn't change your basic security concepts - but be aware of the implications of using a cloud service, especially in the following areas:

availability - for a single instance, you could find you have less control over availability
security of hypervisor - you have little control over their end so need to trust Amazon, but make sure your login to Amazon is protected at your end

SSH definitely is a good idea - and using certificates is recommended over solely using username and password.

As regards securing java - that could depend on a wide variety of factors. Possibly worth asking a separate question.


Question on information retrieved from systems that could potentially lead to exploits Usually it is advised, when one wants to secure an application, to "provide" as little information, or better yet, no information at all to unauthorized (possibly malicious) users. I'm thinking of information like OS, app version, etc.

My question is the following:
I have a web application that allows access only from specific IPs, the rest of the world gets an HTTP Forbidden response. I was wondering, in the context of security mentioned above, is there anything wrong? I mean I guess an intruder would know that an HTTP server is running but would not be able to access it.

Is there a security issue because of this? Could it be improved somehow?
UPDATE:
I am also using authentication via username and password but if the source IP is not in the allowed list they do not get a username/password prompt page. Just forbidden

If your web server is only serving specific IPs, it's probably a better idea to only allow those IPs in your firewall.


Is there any risk from attempting ssh authentication to a rogue server? Suppose I'm about to connect to a new (unauthenticated to me) server. I've previously provided my ssh public key to the server owner (who populates it in the appropriate authorized_keys file). The server owner can't securely provide me with the host public key information in advance and says that as long as my public key is known only to us, security will be maintained.

Other than the case where a rogue server also/already has my public key, is there any chance I might divulge my credentials (or otherwise compromise security) if my ssh session to this unauthenticated server is (from the beginning) directed to a rogue server (e.g., one acting as MiTM)?  Some of the answers here seem to suggest that there is a potential issue--perhaps depending on the version of SSH used?

In the comments OP separated his original question into two different questions, the first of which has already been answered, as pointed out in the comments.

Question 1:

  can client public key be used to authenticate server

The answer is no. (See, Does git use the ssh user keys or the repository's deploy keys for encryption?).

Question 2:

  is there any harm in being promiscuous with your authentication attempts (e.g., attempting to authenticate at a known-but-potentially-unfriendly server using the client credentials intended for another server)?

Harm can mean various things. But, I think OP is asking about whether or not simply trying to authenticate using ssh keys to a rogue server will somehow leak information about his private key (stored only on his client machine).

With this definition of "harm" the answer is no.

When you try to authenticate to a rogue server, you will receive that server's public key (in its certificate). This will allow you to authenticate the server and you will see that it is rogue and not connect. So, this doesn't expose your private key in any way.

But what about the case where you do attempt to connect to the rogue server? Suppose that the rogue server does have your public key. In this case you still don't leak your private key by attempting to connect, since it is your (ssh) public key that is used by the rogue server to authenticate you. The rogue server can send you a challenge encrypted with your public key. Then you can decrypt it with your private key and prove you are who you say you are. You only send back the decrypted challenge, you don't send your private key or any info about your private key. And this should not leak any information about your private key (with the caveat that I'm assuming that modern public key crypto such as RSA and/or ssh is/are not broken).

I would also like to reemphasize that fact that I'm assuming the question is only directed at connection attempts. I'm not considering the fact that a rogue server might spoof a user/pass login and harvest your credentials that way, or some other malicious behavior such as logging your IP for a subsequent retaliatory attack, etc.


Does Apple maintain the security of the built-in Ruby? Does Apple maintain the security of the Ruby implementation that comes by default in OS X?

I recently heard about CVE-2013-4073, but when I ran "Software Update..." on my OS X Lion box, it didn't update Ruby. Also, I've never noticed a Software Update that changed the Ruby that OS X supplies.

I checked the version of Ruby, and it was prior to patchlevel 374

ruby 1.8.7 (2012-02-08 patchlevel 358) [universal-darwin11.0]

If Apple doesn't do security updates for the built-in Ruby, does that mean that it's a potential security risk, for example if a careless user decided to use it for programming-related tasks?

They do provide security fixes relating to Ruby - for example the fairly recent Security Update 2013-002 includes some Ruby stuff, as did 2013-001. They don't seem to have patched CVE-2013-4073 yet, but to be fair that vulnerability is only a couple of weeks old.

As you imply in your question, the non-careless developer will never try and run a production web app with built-in stack components, but will download and install a separate copy somewhere else and keep that patched and updated appropriately. For one thing, they're very likely to want something more modern than 1.8.7!


What are the serious weaknesses in this free password management system? I want to protect my passwords for free and store them on a machine that might get stolen but have the passwords very securely backed-up in the cloud, again for free, and minimize the total lifetime inconvenience of password management system changes and minimize the risk of transcription errors that might result from porting.

Some systems deviate from the usual 2-tuple access allowed by a user name and password. For example, for some systems I would store a 3-tuple because an email address may be allowed as an alternate user name. Others have a 4-tuple to allow for a password hint and secondary password. The diversity of systems has me preferring that the password file be free-format text.

My solution has been to cut-and-paste my free-format text file into CryptoTE and then encrypt the file using my ubuntu user password and upload the encrypted file to Google Drive (manually). My criteria are satisfied because

CryptoTE is free for personal use
Google Drive is free and uploads via SSL
Google Account has a 2 step authentication that allows a level of security that I feel is very secure and yet still has convenient recovery protection
Google is too large for it's business plan with respect to Drive to be often disrupted in a lifetime. It is certainly going to be larger than any pure-play password protection company for a long time.
CryptoTE has a free-format text GUI that is devoid of formatting that might cause the contents to be hard to port
I can migrate from a free-format linux text file to CryptoTE via a cut-and-paste
I can migrate from CryptoTE via a cut-and-paste if that is ever going to be necessary because of the introduction of features that I might forget to eschew
in the event I might someday use Windows on a daily basis, I can migrate using 'todos', or migrate back using 'frodos', and be comfortable because both line delimiting standards are decades old and likely to persist. (This step is probably unnecessary if CryptoTE for Windows exists, but why be married to CryptoTE if you don't have to be.)
unlike some encrypting text editors CryptoTE does not leave un-encrypted temp files somewhere on the drive

Other than 1 - using a file password that is not the same as my ubuntu password, and 2 - obtaining and maintaining (or freezing) my own source code that does what CryptoTE does, and 3 - remembering to upload, what should I do to make this more secure or better in any aspect, while still meeting my criteria?

Issue 1 is not a big deal because I can just use a good password for my CryptoTE file.

Issue 3 is not a big deal because the probability of a computer being stolen is low. If a computer is stolen the worst case is that a cloud backup is one or two versions old if I forgot to upload the latest.

Issue 2 is the only one that worries me, however this is not a prohibitive issue. It will not be a worry at all with a little one time effort.

I note that Google Drive has an ugly user interface that might have the user accidentally sharing files but the interface might get better with time, and in the meanwhile, at least it is CryptoTE protected.

Compared to a typical password manager, the use of a simple text file has the following disadvantages:

Vulnerable to shoulder surfing. The content of a plain text file will be completely visible to anyone around you. While you scroll the file and copy-paste the relevant information for login, other people around you (either advanced attackers with recording devices or just ordinary nosy colleagues) will be able to see the passwords. Password managers don't display passwords by default, and you can copy-paste them (or use autotype or autocomplete) without ever seeing any sensitive data.
Doesn't have features that could sometimes mitigate some risks or be useful in other ways. Password managers often have auto-complete features that allow you to auto-type passwords only if the URL is as expected, and that can mitigate the risks of phishing (if the form isn't on the right page, you will notice that autocomplete won't work). Password managers also might have generators that help you create new random passwords, or might have ways to manage password expiration, or might have features that allow you to share passwords with other people without sending them (only in online password managers).

You should not be too worried about portability in the long term, as long as you keep backups and migrate or convert data if it is ever needed. You use passwords every day, it's not like something that will be sitting there for several years and might cause unexpected problems when you find out that "oops, this format stopped being supported years ago". If I'm not mistaken, KeePass version 2 does not use the old KDB format used by version 1 anymore, but that format can be imported. So it's not like a popular format will die all of a sudden. If you want to be safer, you will also be usually able to export to formats like XML or CSV that you can keep (encrypted) for backup.


Security over multi-streaming such as SCTP I refer to multi-streaming as the ability to send two or more streams of some unit of data (block, byte streams) in one established association/context.  SCTP is an example and the protocol I was thinking about when this question came to mind.  How could I efficiently secure data sent over multiple streams?

What I see in many documents is something equivalent to N handshakes have to be performed for N streams.  This seems to be suggesting each stream is independently secured.  A counter example would be to add multi-stream-over-one-stream to TLS instead of naked TCP.  But that would not include independent loss/order recovery.

What I was wondering about is making security more efficient over multi-streaming (like SCTP) by first securing one stream then using that stream to secure more streams without the full handshake.  If stream 0 is already secure and a sender wants to start sending some data over stream 1, my idea is to generate a random key and send it over stream 0 with info that it is for securing stream 1.  But is this safe even when stream 0 is already secure?

I was thinking of using SCTP (for other reasons) and do security management over stream 0 and data over streams 1 and up.  EDIT: The idea is to speed up starting to send data by the sender generating a key for a new stream X (X > 0) and sending that key over stream 0 and then sending encrypted data over stream X.

This question is the inverse of Has networking using multiple “unrelated” connections to share an encrypted data stream been researched?  The streams I want to secure are related by being part of the same association with no intent to bond them (they would stay independent).

[...] my idea is to generate a random key and send it over stream 0 with info that it is for securing stream 1. But is this safe even when stream 0 is already secure?

You can do that legwork yourself, but I don't think you'll have to.

RFC 3436 says that you can do a full TLS handshake on the first stream and then an abbreviated handshake (using TLS session resumption with the session ID from the full handshake) on the other streams.

Would this work for you?

Further reading

There is a discussion of "TLS over SCTP" vs. "SCTP over IPSec" in this paper: JOURNAL OF COMPUTERS, VOL. 2, NO. 4, JUNE 2007, Secure End-to-End Transport Over SCTP


Are passwords comprised of key sequences on a keyboard any less secure than the same characters but jumbled up? Here are two passwords:

5678%^&*tyuiTYUI

and

8^tyU75%*IuY6T&i

Both have the same number of characters and in each the characters are identical, the only difference is that the first arranges those characters in a pattern that lends itself strongly to muscle memory by following a simple geometric pattern of keypresses.

Are then any significant differences from a security perspective?

Yes! Especially when faced with draconian password complexity requirements, users frequently choose passwords like the first one: keyboard progressions, keyboard walks, keyboard patterns, or whatever you like to call them. And attackers are well aware of this.

Whether conducting an online (brute forcing) or offline (hash cracking) attack, an attacker knows that the most profitable method is usually some variant of a dictionary attack: using a collection of common passwords and trying them. Pretty much every dictionary built using passwords collected from real data breaches contains at least a few variants on the keyboard-pattern method, most commonly "1qaz2wsx" and friends.

Beyond the static dictionary method, the mental algorithms people use to create these passwords are quite simple, and there are lots of programs that generate these passwords rapidly in order to try them all.

From an information-theoretic standpoint, the second password has more entropy, since each character is a random choice from a set of 16 characters. Knowing that they come from a small grouping reduces the entropy somewhat, but it still remains fairly good. The first password, on the other hand, is much simpler. You can think of entropy as "how hard would it be to explain how to type my password?" Here's how I might try to explain your first one:

  On a US-standard keyboard, start at "5":

  Type 4 keys to the right, then return to your starting position.
  Hold "shift" and repeat step 1. Release "shift."
  Move down a row and repeat steps 1 and 2.

Compare that to your second password, which would have to have a procedural step for each character of input. There's no good way to compress it, so it has lots of entropy. Even if I know which 8 keys you've chosen, and that each of them is pressed once with shift and once without, that still leaves (assuming totally random choosing) 16! ~= 2^44 choices, meaning about 44 bits of entropy, which strangely enough is the same amount claimed by the "correct horse battery staple" method.


OWASP ZAP: Add parameter to every request I am testing a website that makes heavily use of REST API endpoints. After authentication, the app adds the authentication token as part of every request in the form of:

OPTIONS
https://www.target.com/api/Action/some-action?data=foobar&access_token=THISISTHETOKEN
User-Agent: ...
Accept: */*
..
Host: target.com
Length: 0

How can I force that every request (inside the spider, scanner, etc.) uses this predefined parameter such that I can browser authenticated?

Update:

I tried creating a Http Sender Script but I fail at modifying the http url parameters:

function sendingRequest(msg, initiator, helper) {
    var token = org.parosproxy.paros.network.HtmlParameter
    token.setType(org.parosproxy.paros.network.HtmlParameter.Type.url)
    token.setName('access_token')
    token.setValue('foo')
    print('token: ' + String(token))
    msg.getUrlParams().add(token)
    print(msg.getUrlParams())
}

You can setup a Replacer rule or create an Http Sender script.

For a Replacer rule select the type as "Request Header String" then set the regex as something like (http://example.org.*) and the replacement something like $1?myParamToAdd=someValue (Note this replacer example is untested.)

For an HttpSender script something like the following should work:

var URL_TYPE    = org.parosproxy.paros.network.HtmlParameter.Type.url;
var HtmlParameter = Java.type('org.parosproxy.paros.network.HtmlParameter');

var paramName = 'myParamToAdd';
var paramValue = 'someValuetoAdd';

function sendingRequest(msg, initiator, helper) {
  if (!msg.getRequestHeader().getURI().toString().contains(paramName + '=' + paramValue)) {
    //You might want to add a check here for the proper domain or path as well..
    var urlParams = msg.getUrlParams();
    var newParam = new HtmlParameter(URL_TYPE, paramName, paramValue);
    urlParams.add(newParam); // you could print this if you need to see what's up
    msg.setGetParams(urlParams);
  }
  return msg;
}

function responseReceived(msg, initiator, helper) {
  //Nothing to do here
}


Challenge, Authentication and session key I programmed an application on Linux using C, I added an authentication and cryptography layer that's going like this :

1 -client sends connection request. -server send a random challenge to client. -the client adds a salt to the challenge and hash it using SHA1 then sends it. -the server adds the same salt and hash the challenge with SHA1, and compare the received result.

2 -In the positive case, the server asks the client for login and password. -the client sends the login and password(salted and hashed with sha1) . -the server search for the login and hashed password in a file .

3 -If the client has sent a valid login and password, he is authenticated. -A key session is generated by concatenating The hashed challenge received And the hashed password..

4 -the key session is used to encrypt data with AES256

I want you to tell me what do you think about it, Is it secure ? Is there any attacks that can break that sequences in any step...? Thank you so much.

Your protocol is quite underspecified, but some remarks can still be made:

In the first step, either the "salt" is chosen randomly by the client and sent along with the hash value, in which case this step appears completely useless; or the salt is not sent by the client, but is a pre-shared secret value between client and server, in which case it is not a salt but a key, and the rest of the protocol is completely useless.
In the second step, the client sends his login and "hashed password" where the hash uses some salt. If the client always sends the same hash value, then presenting that hash value grants access: it is password-equivalent. Any attacker observing a connection (purely passively) then learns enough to fake the authentication, so the protocol would be utterly weak.

If your protocol has to have any value, then we must assume that things go that way:

Client connects; server sends a random value N (technical term is a nonce).
Client sends another random value N' to the server (and also sends a hash value computed over the public values N and N'; that hash value serves no useful purpose).
Client sends the user name L and the value h(N+N',P) where N and N' are exchanged nonces, P is the user password, and h is a "hash function" which somehow combines N and P (there are a lot of methods to do this combination, many of them being weak in more or less subtle ways).
The server has a copy of P and thus can recompute the value h(N+N',P) and see if it matches what the client sent.
Client and server use another function h' to compute h'(N,P) and use that value as a shared key to do some symmetric encryption for the rest of the data.

Assuming that you did everything properly and used hash functions in a proper way and did not forget to add integrity checks and took care of the gazillions of implementation details which can plague the best designed protocols, then you will have obtained, at best, TLS-PSK. There are two inherent and unavoidable weaknesses in that protocol:

The server must store a password-equivalent secret. If an attacker gains a read-only view of the server data (a usual consequence of SQL injection attacks or stolen backups), then he learns enough to authenticate as any of the registered users. This is considered bad. See this blog post for a discussion on that subject.
A passive attacker learns enough to run an offline dictionary attack: the attacker just has to observe one authentication, and then he can "try passwords" on his own machines; he just enumerates possible passwords until he finds one which matches the hash values he observed. This, again, is bad, because passwords tend to be vulnerable to such an exhaustive search. Online dictionary attacks, where the attacker must talk to the genuine server or the genuine client for each password try, are much less a concern, because the server can enforce strict limitations on the number of tries per second; whereas an offline attack is limited only by the computational power that the attacker can muster.

The proper way to do a client-server password-based mutual authentication is to use a password-authenticated key agreement, which results in a shared secret suitable for symmetric encryption with integrity checks. This basically means TLS-SRP. 15 years of implementations and attacks and fixes have demonstrated that designing and implementing a secure protocol of that kind is not easy at all.


Are the cascading ciphers in Veracrypt susceptible to the meet-in-the-middle attack? (MITM) Veracrypt offers cascades of ciphers.
Are these cascades (at least those comprised of two ciphers) susceptible to the meet-in-the-middle attack? Why not?

For example:

  AES-Twofish

  Two ciphers in a cascade operating in XTS mode (see the
  section Modes of Operation). Each 128-bit block is first encrypted
  with Twofish (256-bit key) in XTS mode and then with AES (256-bit key)
  in XTS mode. Each of the cascaded ciphers uses its own key. All
  encryption keys are mutually independent (note that header keys are
  independent too, even though they are derived from a single password –
  see Header Key Derivation, Salt, and Iteration Count). See above for
  information on the individual cascaded ciphers.

Meet-in-the-middle:

Yes, it is vulnerable to a meet-in-the-middle attack. In particular, the three 256-bit ciphers do not provide you with 768-bit security. Instead, it provides "only" 512-bits of security, and a proper meet-in-the-middle attack would require an obscene amount of storage space to pull off as well. This is not a problem though, because the cascading ciphers are not used to increase the keyspace. In fact, the largest hash that is used to derive the password has a 512-bit output. The real reason multiple ciphers are used is to alleviate concerns that one or more of the ciphers has a fatal cryptographic weakness that allows for breaking it faster than brute force. Whether or not this is a reasonable concern is debatable, as all the options are quite solid, but that was the intention.


File upload vulnerability I am trying to pentest a webapp challenge.
Is the following control code vulnerable to file upload? I would like to upload a php shell...

I am able to upload shell.php.jpg file but I receive the error when I load the file location.

function limitText(limitField, limitNum) {
    if (limitField.value.length > limitNum) {
        limitField.value = limitField.value.substring(0, limitNum);
    }
}

var input_file = document.getElementById('image_file');
input_file.onchange = function() {
    var extension = $('#image_file').val().split('.').pop();
    switch (extension.toLowerCase()){
        case 'png':
        case 'jpg':
        case 'jpeg':
            break;
        default:
            alert('Invalid file name');
            $('#image_file').val("")
    }

    return;
};

It looks like you're only looking at the file extension.  This is not effective.  For a description of why, and a list of viable protections, please refer to the OWASP article on "Unrestricted File Upload".

Excerpt:  (Some of this may not be directly applicable to your environment, but I'm not editing those out.)

  Using Black-List for Files’ Extensions

  Some web applications still use only a black-list of extensions to
  prevent from uploading a malicious file.

  It is possible to bypass this protection by using some extensions which are executable on the server but are not mentioned in the list.
  (Example: “file.php5”, “file.shtml”, “file.asa”, or “file.cer”)
  Sometimes it is possible to bypass this protection by changing some letters of extension to the capital form (example: “file.aSp” or
  “file.PHp3”).
  Using trailing spaces and/or dots at the end of the filename can sometimes cause bypassing the protection. These spaces and/or dots at
  the end of the filename will be removed when the file wants to be
  saved on the hard disk automatically. The filename can be sent to the
  server by using a local proxy or using a simple script (example:
  “file.asp ... ... . . .. ..”, “file.asp ”, or “file.asp.”).
  A web-server may use the first extension after the first dot (“.”) in the file name or use a specific priority algorithm to detect the
  file extension. Therefore, protection can be bypassed by uploading a
  file with two extensions after the dot character. The first one is
  forbidden, and the second one is permitted (example: “file.php.jpg”).
  In case of using IIS6 (or prior versions), it might be possible to bypass this protection by adding a semi-colon after the forbidden
  extension and before the permitted extension (example:
  “file.asp;.jpg”).
  In case of using IIS6 (or prior versions), it might be possible to bypass this protection by putting an executive file such as ASP with
  another extension in a folder which ends with an executive extension
  such as “.asp” (example: “folder.asp\file.txt”). Besides, it is
  possible to create a directory just by using a file uploader and ADS
  (Alternate Data Stream). In this method, filename should end with
  “::$Index_Allocation” or “:$I30:$Index_Allocation” to create a
  directory instead of a file (example:
  “newfolder.asp::$Index_Allocation” creates “newfolder.asp” as a new
  directory).
  This protection can be completely bypassed by using the e.g. control characters like Null (0x00) after the forbidden extension and
  before the permitted one. In this method, during the saving process
  all the strings after the Null character will be discarded. Putting a
  Null character in the filename can be simply done by using a local
  proxy or by using a script (example: “file.asp%00.jpg”). Besides, it
  would be perfect if the Null character is inserted directly by using
  the Hex view option of a local proxy such as Burpsuite or Webscarab in
  the right place (without using %).
  It is also possible to create a file with a forbidden extension by using NTFS alternate data stream (ADS). In this case, a “:” sign will
  be inserted after the forbidden extension and before the permitted
  one. As a result, an empty file with the forbidden extension will be
  created on the server (example: “file.asp:.jpg”). Attacker can try to
  edit this file later to execute his/her malicious codes. However, an
  empty file is not always good for an attacker. So, there is an
  invented method by the author of this paper in which an attacker can
  upload a non-empty shell file by using the ADS. In this method, a
  forbidden file can be uploaded by using this pattern:
  “file.asp::$data.”.
  In Windows Servers, it is possible to replace the files by using their short-name (8.3). (example: “web.config” can be replaced by
  uploading “web~1.con”)  Sometimes combination of the above can lead to
  bypassing the protections.

  Using White-List for Files’ Extensions

  Many web applications use a white-list to accept the files’
  extensions. Although using white-list is one of the recommendations,
  it is not enough on its own. Without having input validation, there is
  still a chance for an attacker to bypass the protections.
   - the 3rd, 4th, 5th, and 6th methods of last section apply here as well.
   - The list of permitted extensions should be reviewed as it can contain malicious extension as well. For instance, in case of having
  “.shtml” in the list, the application can be vulnerable to SSI
  attacks.