My app requires passwords be checked *locally* - how can I avoid security issues? I have an app in which there's a Main Account Owner who has a completely secure server-side-checked password, hashed and salted, which is great. No worries there.

But each account also has a list of 'employees' and the full employee table is regularly downloaded for storage locally on the app devices. The full table, including the password field, has to be available offline so it has to be downloaded and stored, and the password has to be checked rapidly.

Is it better practice to store a "PIN" rather than a password in this situation? Is there any use in encrypting these passwords? What sort of encryption can I do that would be extremely fast and easy to implement across languages?

This particular password/pin, keep in mind, doesn't actually give access to a lot of app features, this simply allows them to log in and log out, so realistically the lack of security isn't disastrous -- there's not much someone could do maliciously even if they had one of these passwords.

I think you have two choices:

Perform proper password security and send down hashes for the local system to verify
Use a "PIN" rather than a password to minimize harm if credentials are stolen.

To recap what you are asking, the obvious issue is that having to send down the credentials in some form increases the risks of credentials being stolen.  With password reuse a never-ending problem, passing people's passwords around for local validation is a danger to your users more than anything else.

Encryption doesn't really help a ton (or maybe depending on your security concerns) because regardless of what hoops you make the app jump through, the app still has to be able to verify the passwords offline, which means that there is a way to get back the plain text passwords.

Hashing

Probably the most secure way to use actual passwords is to just follow standard protocol and use a secure password hashing algorithm.  Obviously you therefore don't want a fast aglorithm, but I can't imagine the phone will be so much slower at hashing as to cause painful UI problems.  Obviously you'll have to reproduce your hashing algorithm on your phone - presumably that won't be too much of a problem for standard hashing algorithms.

The hashing provides a basic layer of protection against the passwords getting stolen in transit or from the phone.  Obviously though it won't protect weak passwords against brute forcing.  However, if these passwords aren't connected to user details otherwise (for instance email addresses), then that is less of an issue - every password I ever used could be splashed publicly across the internet but it wouldn't matter if my email address isn't connected to them.  If you can make sure that the passwords are not connected in any way to any personal information, then there is less of a concern.

PINs

The other option would be to use a PIN, as you mention, and make it definitively a PIN - numbers only.  This will keep people from reusing their password.  However, it won't keep people from reusing their ATM PIN number, so I would still keep these credentials far from any personal information.

In short, if all you have is a password or PIN then it is no longer really a password - it is just a unique identifier assigned to a user.  This is much less dangerous to have stolen (or at least, only dangerous to your app and what that unique ID allows a malicious user to do).  Therefore the best option is really just to make sure that these local passwords are never connected (or connectable) to actual user information.


Choosing TLS / SSL cipher suites - What considerations are there? Most of the advice on choosing cipher suites I find tends to be one of these forms:

Here's a string to paste into your application, or
Here's a list of 30,000-foot generic criteria to use ("favor stronger ciphers") (gee thanks)

The former tend to be outdated quickly and don't really educate the reader on why those ciphers are ordered in that way. The latter tend to be so open-ended as to be useless.

Instead, what I'd like to know is:

Is there a generally accepted criteria for determining which ciphers to support, and in what order? Most importantly, why are those criteria important?
Presumably, some ciphers are tougher to crack than others. Some are faster than others. Some may have other perks or considerations I don't even know about. Are there resources for figuring this out without getting a graduate degree in cryptanalysis?

Is there a generally accepted criteria for determining which ciphers to support, and in what order? Most importantly, why are those criteria important?

Case 1: You control both ends of the communication.

1.a. (sorry to repeat part of your question but you have no choice than) Use the highest suite components which are supported by your chosen software.
 1.b. If that does not satisfy your needs then create your own implementation of a suite component which is not yet implemented but is published and peer-reviewed in academic environment.
 1.c. If that still does not meet your needs, invent your new algorithm and wait for it to be peer-reviewed before implementing it.

Case 2.1: You don't control the peer, but you are in need of information exchange under his conditions (ex. you are visiting a website, let's say your bank online account)

Accept the highest combination the peer is offering. Lookup online each algorithm details/weaknesses and evaluate what are your loses if/when your communication is compromised. Constantly monitor changes in peers offering.

If you find these loses unacceptable then find alternate means of exchanging information (ex. go to the bank office instead)

Case 2.2: You don't control the peer, but you wish to reach an intended audience (ex. you are selling openvpn accounts)

Constantly monitor progress in cryptography and always offer the highest suites available.
Constantly monitor existing suite for weakness (ex. subscribe to alerts regarding the software you use and the algorithms that are implemented) and when a new weakness is published, evaluate how is that impacting the numbers of intended audience (assuming that you will drop the vulnerable suites knowing that by doing this so will potentially reduce audience)

To summarize all three cases, the strongest criteria is:
In what degree a leak or altering of information I exchange is affecting me, my friends, my business or my business partner(s) and how much do I care about it?

  Presumably, some ciphers are tougher to crack than others. Some are faster than others. Some may have other perks or considerations I don't even know about. Are there resources for figuring this out without getting a graduate degree in cryptanalysis?

Just stay up to date with current official cipher suites list and always choose the highest available. Keep an eye for example on what NSA recommends for their internal use. An expanded view of @bonsaiviking's answer linked in the first comment of your question is detailed on Google's Online Security Blog


Is the following PayPal Vulnerability a design/implementation flaw? I am trying to understand the logic behind following vulnerability, I believe this a design flaw not only an implementation.

To me the problem with the two-factor authentication service at PayPal is that the server does not distinguish between authentication request coming from the mobile app and the web-app. For that reason when the server disable the two-factor authentication based on the mobile app request it got disabled for the user account, and not only the user mobile app.  Is my interpretation correct?

PayPal Vulnerability

Post: PayPal Vulnerability

Status: Published

Vulnerability Description:
It has recently reported that Paypal two factor authentication security measures can be bypassed.   The vulnerability or flaw pertains to the way that PayPals authentication flow works with the services mobile apps for iOS and Android. PayPal gives users the ability to utilize two-factor authentication in a variety of ways, each which  creates a one-time passcode for login. Two-factor forms are available to be used on the official PayPal website, but is not supported by PayPal mobile apps.
Here is how it worked:
When PayPal servers responded to a POST request sent from the mobile app for a two-factor enabled account. The application would show an error message telling the user two-factor was enabled and not supported, initially sending the user back to the login . But when the value in the server’s response in regards to the two-factor authentication is changed to “false”, the application would simply allow the user into the account, bypassing all forms of two-factor protection.

The vulnerability is in the fact that the application enforces second-factor auth verification client-side.

That is, the service itself does not require two-factor authentication, ever. But it is willing to process two-factor authentication if requested, and if the client app learns that account has two-factor enabled, then the app will attempt verification.

But if the client doesn't find out (or is modified to not care), then it won't request verification. And the backend service won't complain either.

The vulnerability can be summed up thusly: "Two-factor authentication is not enforced." Whether that's a design flaw or an implementation flaw depends on whether they meant for it to be this way or whether it was an accident. They haven't said either way.

Note that this vulnerability was discovered back in August by Joshua Rogers. The attribution you've supplied is incorrect. http://blog.internot.info/2014/08/paypal-complete-2-factor.html


Is it possible to hack WPS PIN of routers that lockout exponentially after failed tries? I have been interested in Wireless hacking lately, and I can do dictionary attacks, and some other type of attacks. Though, I wanted to hack my ASUS RT-N12D1 router's WPS PIN. ASUS doesn't alllow to change the WPS PIN to a custom value and it ships with prespecified WPS PIN.

Anyway, I enabled WPS, and tried to hack it using wifite, reaver, and bully, but I just wasn't successful with any of these tools. Because, the router is a bit new, and as long as I know new routers have some protections against known WPS attacks, such as locking the WPS after a few failed attempts, and after more failed attempts the lockdown time increases exponentially I guess, until it is completely locked and you need to manually switch it off/on.

Are there any known working methods in order to hack WPS PIN of a router that locks WPS after a few attempts?

This is happening because your AP is able to filter out the MAC address and block it after an x amount of requests. What you need to do is to change the MAC address every x requests so the router won't be able to lock you out.

Use reaver mac address changer: Reaver -i mon0 -c x -b xx:xx:xx:xx:xx:xx -vv --mac=vv:vv:vv:vv:vv:vv

Warning: This might crash your router do to an overload of requests...


Protect Raspberry Pi's physical sd card to be swapped Scenario:

In a company there are Raspberry Pis which are connected to its network environment. A person with bad intentions could swap the SD card and replace it by his own which makes the Pi to a "sniffer" or the person could use it in other harmful ways.

My thoughts about preventing such an attack:

A locked Raspberry Pi case which is a physical barrier for the attacker.

Not the topic of this question:

Protecting/encrypting the data on the SD card.

The question:

Are there any other ways to protect against such a threat?

You must use Full Disk Encryption on the sdcard used to boot the Pi. Using it, if the attacker gets the sdcard away, it will not be able to read its contents. This will protect the 802.1x credentials stored in the card.

Second, use 802.1x authentication on the network. 802.1x requires login and password for the client to get an IP address. Without a valid login and password, the Pi will not be able to join the network even if the attacker plugs the network cable on it.

With this, you will have to connect a keyboard and monitor to the Pi, to enter the disk password and the 802.1x credentials. If this Pi is to run a secure environment, keep a know good disk image somewhere else and reflash the card every time the Pi is shut down. This will prevent the attacker from coming in, shutting down the Pi and backdooring the bootloader (the Evil Maid attack). This is required, unless you want the attacker to get the 802.1x credentials and full disk encryption key at the same time.

Bonus point: nobody without valid credentials will be able to get to an unsupervised room and plug in a laptop.

Forget MAC address authentication, it's trivial to change the MAC.


Nexus 7 (Or any other good android tablets) For pen testing I'm considering investing in an android tablet for pen testing. Does anyone know how capable they are with pen testing? Can they compile code or forward packets? Are any applications that work on linux going to work on them?

Small update: Kali Linux NetHunter was released last month and appears to be the de-facto standard for pen testing from an Android platform

Because of the support for recompilation of drivers that are known to support monitor-mode and/or frame injection, it appears that testers are sticking to the Broadcom chipsets (BCM). bcm4xxx are especially popular on Android devices, especially and notably Samsung.

Working out of the box, you have the Samsung Galaxy S II and the Nexus One. Recently added out of the box support for the HTC EVO 4G is also currently available. Using CMC or similar technique (AOSP would just be too annoying), one could add in the drivers to other devices with similar BCM chipset WiFi boards.

Ideally, you'd use a Samsung Galaxy Note for the CMC conversion of the driver over to at least monitor-mode standards. Theoretically, wash(1) should work in both passive and active modes, but the active WPS attack in reaver would likely require some additional driver modifications.

However, with Complete Linux Installer (on a rooted device) or Ubuntu noroot, one could install BackTrack 5r3 with aircrack-gui-m4 and Johnny (or additionally, even Reaver Pro if the reaver bits are working) for excellent X11 GUIs to control attacks.

Outside of WiFi Analyzer, Fing, Shark, and zAnti -- I would definitely add in X-plore and androidVNC. Some apps are better done without X11, and some GUIs from X11 simply are not yet replaceable via the Android SDK, Play Store, or alternate app market.

My suggestion would be to wait for the Samsung Galaxy Note 2 to arrive to your US carrier (note that there is an international version already available, certainly preferred over the US versions for a variety of reasons) and purchase then, helping along with the development of that platform for penetration-testing specifications.

I have personally added the vulscan NSE script to zAnti to make it that much more powerful. Along with a BackTrack 5r3 install via Complete Linux Installer, it would be possible to run Metasploit (any web edition such as Community or Express) on the web ports and access it via an Android browser, in addition to running Nessus and accessing it with the Android SDK app.


OneDrive: How can Windows Security's "Remember my credentials" feature be misused? Here I'm entering credentials for OneDrive:

If I check Remember my credentials, I assume that malicious code running as my user account can get access to some token and use that to interact with OneDrive as if they were me.

My question is, what beyond that can malicious code (running as my user account) do with the "remembered" credentials?

Can they be used to authenticate as my user for services other than OneDrive?
Can they be used from another PC?
Do they ever expire?
Can they be copied elsewhere to perform an offline brute-force attack to get the original credentials?

I assume what is remembered is the OAuth2 refresh token.

In this case,

no, it can't be used for other services.
yes, it can be used from another PC. From the server side, it's no difference. Maybe a different IP, but that could be your "first" computer too
this token is valid for at least 6 month in Onedrive (https://github.com/OneDrive/onedrive-api-docs/issues/124) (altough changing your password invalidates it immediately)
no, the token alone, without server access, isn't related to login name and password.


Android Root Certificate Issue I'm trying to intercept requests using OWASP ZAP proxy and Burp Suite. My current configuration is my android phone (One Plus 5 Android Oreo 8.1) has installed both certificate from ZAP and Burp. But issue arise when I've changed my ZAP certificate in ZAP Proxy. So with the new certificate on ZAP Proxy, the normal way to do was to install the certificate into my Android phone. But with an existing ZAP certificate in place, I can't do that.

If I attempt to remove the old ZAP certificate from /system/etc/security/cacerts , reboot, install the new certificate and reboot again, the certificate will not be shown inside the credential storage.

Moving on, I've tried to remove the new certificate and place the old certificate back and reboot, the certificate will now appear in the credential storage.

Why would I not choose to just import the old certificate into the new ZAP proxy? Because importing certificate into ZAP requires the format of both the certificate and unencrypted private key. (https://github.com/zaproxy/zap-core-help/wiki/HelpUiDialogsOptionsDynsslcert)

I've actually encountered this issue not only with ZAP certificate but also with Burp certificate, trying to install a new certificate with the same name does not work. If anyone has any solution, please do help me.

For references:
This is my steps inserting custom certificate into Android phone. (https://blog.ropnop.com/configuring-burp-suite-with-android-nougat/)

Convert the Owasp Zap certificate
from .cer to .der using openssl or using web service for change the format (https://www.sslshopper.com/ssl-converter.html) and follow the same process that do you see in (https://blog.ropnop.com/configuring-burp-suite-with-android-nougat/)


How to encrypt a short string to a short ciphertext using an asymmetric encryption? I am using RSA to encrypt some text, so my system has already generated private and public keys.

These keys I would like to use to encrypt/decrypt a short text (16 chars).

The main condition is: the ciphertext should be as short as possible.
Minimal length of the ciphertext is more event more important than total security. The attacker won't be able to choose plaintext.

Question:
Is there a method, which would allow to create a short ciphertext using RSA private key?

EDIT:
What I really want is to be sure that the text has not been changed and that it really comes from the application.
The typical solution would be - to sign the text. But the usual RSA signature would be too long to be entered into mobile clients, where I would implement this system.

My idea was to encrypt a known text with a private key, so that it can be decrypted with a public key. This would provide enough safety to trust, that the encrypted text comes from base, since you need the private key for encryption.

Advantage: you only need to enter a short ciphertext string to validate the encryption, assuming that I can find an encryption method which can preserve the text length after encryption.

"Encrypt with the private key, so that it is decrypted with the public key": this is a flawed analogy, by which RSA signatures were first described, but even with RSA it does not work.

What you want is really a signature algorithm, however you want to call it. It is possible to define signature algorithms based on the RSA core operation, and it has been done, and it is called RSA. Anything which is RSA-based will involve some modular exponentiations working on, and yielding, big integers of the same size as the modulus. So a RSA-based signature with a RSA key worth that name (i.e. at least 1024 bits) will necessarily include a 1024-bit integer, so its size will not be lower than 128 bytes.

There is a possible twist in that RSA is a signature algorithm "with recovery": though the signature will have size at least 128 bytes, it is possible to embed in it some extra data (part of the message which is signed). There is a standard called ISO 9796-2 which does that; it has some shortcomings but it can be used. However, though this standard will make the total signature size overhead rather small, it won't please you, because you want to limit the size of that which is entered by a human user. The benefits of ISO 9796-2 are for long messages.

Algorithms producing short signatures are an active research area. Roughly speaking, if you target a security level of n bits (meaning: an attacker would have to invest in a computational effort of size 2n to be able to produce a fake signature -- but the effort may possibly enable him to produce millions of fake signatures for the same cost):

With DSA and derivatives (e.g. ECDSA), the signature size is 4n bits.
With BLS, the signature size is 2n bits (but the maths are hard to understand and there is no standard yet).
There is an absolute theoretical minimum of n bits.
We don't know good algorithms between n and 2n bits, although we know some of questionable security.

You might be able to fix that, though, by changing your models. Signature algorithms are meant for one thing: to allow someone to verify a signature without giving him the power to produce signatures. Depending on your exact context, it is possible that you do not really need this separation of roles. Maybe it is not a problem if whoever verifies a "signature" could potentially create signatures of his own. If that is the case, then you can use a MAC which can be considerably shorter (e.g. 32 bits might be sufficient in your case) and also much easier to implement (hint: use HMAC/SHA-256 and truncate to the desired size).


Is WebGL a security concern? Is WebGL a potential security problem due to the low level access it provides?

For example, a web page can attempt to compile and run any shader source it wants.

It seems that security would especially be a problem with open source web browsers, as an attacker could more easily find vulnerabilities in the implementation.

Yes, WebGL is indeed a potential security risk, though the magnitude of the risk is hard to assess and open to debate.  There are some tricky issues here.  The browsers have put in place some defenses against the security risks, but there seems to be some debate about whether those defenses will prove adequate in the long run.

One major risk is that WebGL involves running code directly on the video card, and exposing APIs that provide direct access to video card APIs.  The browser does attempt to sandbox this code (to a certain extent), and browsers do enforce a number of security restrictions designed to prevent malicious behavior.  However, many of these APIs and their implementations were not originally designed to be provided to untrusted entities (they were only usable by native applications, which are fully trusted), so there are concerns about whether exposing them to arbitrary web sites might enable web sites to attack your system.

There was one high-visibility white paper (see also the sequel) which looked at the security of the WebGL implementation in browsers at the time, and found a number of vulnerabilities.  They found some memory safety issues in several WebGL APIs, and also found some attacks that would allow one web site to read pixel data of other web sites (which could enable a breach of confidentiality).  See also this third study, which demonstrated the existence of these vulnerabilities on a number of browsers and web cards (at the time).

Browsers have responded to this with a variety of defenses: they have blacklisted video cards with known security problems; they have tried to fix the known memory safety problems; and they have restricted use of WebGL per the same-origin policy, to prevent a malicious web site from using WebGL to spy on users' use of other web sites.

There is some ongoing debate over whether these defenses will prove adequate in the long term.  Microsoft has taken the position that WebGL is too great a security risk and the existing defenses are not robust enough.  On the other hand, Mozilla takes the position that the defenses they have put in place will be adequate, and that WebGL provides important value to the web.  Ars Technica has an excellent round-up of the issue; and here is another press report.

P.S. I completely disagree with your statement about it being particularly a problem for open source web browsers.  That's a myth.  See Open Source vs Closed Source Systems, which already covers these arguments.  (See also Chrome vs Explorer - how to explain in plain words that open-source is better? for additional thoughtful discussion on this topic.)


Do Cyber Range(s) detect Business Logic Security Failures? I had been studying Cyber Ranges for a while & found out there applicability in defense, military control systems, enterprise & in medical. I'm interested to know if the stimulation which is carried out by these Cyber Ranges have the capability or would ever gear the capability to detect Business Logic Threats on Application Tier?

If this is already something which's accomplished by AI, I'm not sure I had found out any such sample working or enterprise usecase whereby it says so. Having said that - does Cyber Range detect Business Logic Threats which are seemingly wild or just rely on the high level detection of Network Stimulated Attacks?

p.s. Cyber Range uses virtualization to reduce costs which otherwise could require high-end hardware to stimulate larger scale organizations. These organizations would surely have internal applications, external applications & the logical aspects of it.

edit: To be precise I'm asking if current cyber range are capable to stimulate a large scale organization with obvious business logic threats which can be unleashed by manual security assessment efforts. Are these business logic security proactively detected while the stimulation is done?

Cyber ranges can be set up to simulate anything you want.

Most commonly they are used to simulate vulnerabilities so people can learn to exploit them but it would be easy to setup a misconfigured application which allows for business-logic exploitation. There are some intentionally poorly written web apps that simulate shopping carts and also a fake bank where you can play with business logic a little bit on Damn Vulnerable Linux. Possibly not the same type of business logic that you have in mind but it does exist already.

If the network you are simulating also has detection capabilities you could also simulate the defensive tools in use and in that situation you could have a Cyber Range which does detection. This is useful for practicing evading defenses.

That said the tools which typically would spot business logic threats frequently fall into a different category, Fraud detection, and these are not normally something you would see in most Cyber Ranges at this time. You could deploy them but it's so specific to a given business/organization that it's simply not something people would commonly train on. Again, you could do this if you wanted.

The following may be a good Cyber Range platform to get you started:
https://opencyberchallenge.net/

Per edit to question: Cyber Ranges can be made to simulate huge networks with thousands of hosts fairly easily. That said, getting specific business logic and business logic monitoring into that environment would take additional work and is not something commonly done but it is something that can be done. At this time I think the answer for most ranges is that what you are asking about would almost never be detected because it's not a typical goal for these ranges. As I said earlier though you can set these up to simulate anything you want so if you want to simulate tests against systems with fragile business logic issues and monitor that you definitely can but it's not something you will find commonly done at this time.


Creating a website to test my scanner that I scripted Hi I looked around on Google and this site for about the last hour and I couldn't find anything that gave a direct answer to my question. I changed the code around in a scanner that I used in the past, I've used other web hosts in the past to create my websites for testing, but this time I wanted to use WordPress for hosting. I wanted to know if anyone else has ever tested scripts or ran scanners against their own WordPress site and haven't gotten into legal trouble. The other hosts that I have used in the past didn't mind but I'm trying to figure out if it breaks any tos even if I am the owner of the site but wordpress would be hosting it. Just trying to see if anyone on here knows WordPress's Legal TOS well. Tried to write the question the best I could.

I'm fine with a short or long answer

Are you sure you need to have an externally hosted website? A lot of the testing I do happens on a virtual machine -- I install a flavor of linux, apache webserver, the software package, and fire away. With a virtual machine, you have the following assurances:

You will not disrupt other people's websites.
You will have access to all logs and all parts of the system.
You will be able to conduct your work privately, a key part of the responsible disclosure process.
You won't piss off your hosting provider or Wordpress.
You don't have to pay money. (Whoo-hoo!)


What does EMET do for Windows 8.1? I recall seeing, upon release of Windows 8 a while ago that a number of new mitigations and memory protections had been put in place but i'm unsure if these are the same protections offered by EMET. Based on the bypasses discussed it appears that KASLR and SMEP are something specific to Windows 8 (but not present in EMET).

Does EMET add any additional memory protections on windows 8 and higher?

Additionally, while EMET does certificate pinning nicely enough are there any other tools that offer Certificate pinning for Internet Explorer, Chrome AND Firefox? This paper recommends using a tool called Convergence but that appears to be firefox only and I'd like to be able to support as much of the enterprise environment as possible.

Finally Given that both EMET 4.1 and EMET 5.0 have been successfully bypassed is there any point to using them? Is there a preference (in terms of the security provided) to use one or the other (especially since EMET 5.0 seems to contain a lot of issues with crashing applications)?

KASLR and SMEP are kernel-mode protections, applying ASLR to kernel space and enforcing privilege ring boundaries on execution respectively. EMET is solely a user-space protection tool, and as such is not involved with KASLR or SMEP.

You should also be aware that EMET is not a magic bullet. It is designed with two goals: to raise the cost of exploit development, and to reduce or eliminate the efficacy of existing pre-written shellcode.

So, to answer your question regarding EMET and Windows 8.1, the answer is yes, there are plenty of protections that EMET offers:

SEHOP

SEHOP is a mechanism designed to prevent stack buffer overflow exploitation via SEH handler overwrites. EMET hooks the OS functionality which provides exception handling and inserts a check to ensure that the handler has not become corrupted, primarily by verifying that the handler address is one which came predefined in the application.

Dynamic DEP

Data Execution Prevention allows for hardware enforcement of execution access flags on memory pages. The normal configuration for an OS is to have DEP enabled for services, and then have applications opt-in based on a compiler flag (which is stored in the PE header, under the Characteristics field). EMET allows you to specify a policy that forces DEP on for a process, even if it wasn't compiled with this flag. It also has an additional benefit: it specifies the DEP policy for the process such that calls to SetProcessDEPPolicy from within the application cannot override this flag, so ROP chaining to that API won't disable DEP and allow for trivial stack execution.

Heapspray Protection

This protection is just designed to protect against stock shellcode pulled from frameworks like Metasploit. It pre-allocates common page addresses used in heap spray attacks and sets the memory to be inaccessible. This is useful because a lot of existing drive-by attacks use these addresses, and you can essentially prevent all of those attacks from working by allocating the pages they're looking for. Of course, someone who knows what they're doing can just re-write the shellcode, but it raises the bar to make it more difficult for script kiddies who only know how to use Metasploit or PoC scripts.

Null page allocation

Same as heapspray protection, except that it allocates a block of read-only memory at the null page address. The goal is to prevent null page dereferences from doing anything funky, though they freely admit that this is just a defense-in-depth measure as null page derefs aren't really exploitable bugs.

Mandatory ASLR

Like DEP, ASLR has to be compiled in with a flag, which again is set inside the PE header. The problem with ASLR is that even if your main program executable is marked as ASLR, it only has to load a single non-ASLR DLL into its memory space to result in a potential ASLR bypass - once there are known blocks of code in predictable locations, an attacker can build a ROP chain. Mandatory ASLR forces all loaded modules to be marked as ASLR-enabled, even if they're not compiled as such.

However, in Windows 8 (and 8.1) this feature does nothing if the native enforced ASLR implementation is enabled, because it does the same thing at the OS level.

Export Address Filtering

EAF monitors read operations on the Export Address Table (EAT) to ensure that reads are only coming from areas of application code, rather than shellcode. This is intended to make it difficult for shellcode to scan a module's EAT to find an API, where the module address is leaked in some way to facilitate such a trick. This is another mechanism where they use heuristics to guess whether the caller is shellcode or not, and isn't foolproof. It's just designed to catch out the low-hanging fruit.

EAF+

This is an extension of EAF, but it can be used in conjunction with or independent of EAF. It checks whether the stack pointer is within an allowed range, and whether the stack and frame pointers are mismatched. EMET 5.0 introduces a "valid modules" list for processes, and when it is populated EAF+ also detects if a read is to the EAT pointer for those modules, and monitors reads of the MZ and PE headers for the executable in memory to prevent EAT / IAT scanning.

Bottom-up Randomisation

Also known as bottom-up ASLR, this randomises the location of bottom-up allocations such as the stack and heaps. It's an additional countermeasure to ROP that just increases the amount of entropy in the layout.

Anti-ROP

This is a whole suite of protections that help prevent ROP from being successful. It monitors LoadLibrary calls to prevent loading DLLs from UNC paths, prevents memory protection APIs from making the stack executable, checks that APIs are properly called (i.e. with a CALL, not a RET), tries to follow back the call chain to check for ROP-like behaviour, and attempts to detect stack pivoting (incl. checking ESP / EBP against values stored in context snapshots used in certain APIs). All of these together create a headache for anyone trying to build a working ROP chain.

Attack Surface Reduction

ASR allows you to whitelist which DLLs an application is allowed to load. This is useful for a large number of reasons, including blocking malware from doing DLL injection, preventing unsafe plugins from loading (e.g. Flash), and stopping exploits from utilising LoadLibrary for nefarious purposes.

Advanced Anti-ROP

This feature adds more anti-ROP features. It hooks deeper functions, e.g. ntdll's memory allocation functions, so that it becomes more difficult to bypass the anti-ROP checks. It also tries to catch out shellcode that contains a copy of a function prolog, executes it, and then jumps past the real prolog to get to the real function, as a form of hook bypass. Finally, it bans the ntdll!LdrHotPatchRoutine function to prevent abuse of the hotpatch functionality.

Certificate Pinning

This isn't a mitigation in the same sense of the others, but it enforces certificates in IE so that they can't be easily replaced.

The point I'm trying to make, here, is that EMET has a whole host of protections which, when enabled in tandem, make the exploitation process significantly more difficult. EMET is not trying to prevent APTs and nation states from breaking stuff. They're trying to make it more expensive (in terms of time / money / skills) to build working exploits, so that it's less profitable for bad people to try. They're also rendering most shellcode which isn't specifically designed to avoid EMET inoperable, which is a large percentage of the market. It's absolutely worth enabling it.

With your concerns about stability with certain applications, you just have to work out compatibility with different protections. EMET 5.0 has reporting features which log detections, so you can go through and attempt to identify problems. Start with all the major protections enabled and turn others on or off as you go, until you reach a balance.

As for certificate pinning, it's largely browser specific. There are, of course, plugins for Firefox and Chrome that do this, though I've been underwhelmed by some. Certificate Patrol is popular, but I find it way too noisy to be useful - you just learn to click OK blindly. Chrome does have the --hsts-hosts command line option, which looks great, though you'll need to do some manual work to get it set up right. Firefox now pins several sites by default, as does Chrome, which means you're already protected to some extent. Unfortunately, it appears that there's no simple way to manage your own pinning across all browsers in your environment, and you'll have to do the manual work.

Sources:

EMET 5.0 User Guide
Announcing EMET 5.0
SEHOP - TechNet / MSEC
Certificate Patrol
Manually enforcing HSTS in Chrome


Writing my own encryption algorithm I am currently studying IT at college (UK college aka not University) and the coursework is boring me to death. I have been coding for quite a while now mainly in OO languages such as C# and Java but often get bored and give up quickly because the majority of it is boring UI stuff I hate doing, the projects I come up with rarely have much to do with code design and actually creating algorithms. I want to start writing my own algorithms of sorts and start moving away from the user friendliness side and start learning things that interest me, namely cryptography and compression. I want to write my own encryption algorithm, to encrypt the bytes of a file or string. I have a few questions:

Where would I start with this, What books/materials are recommended
for starting with cryptography?
Do I need extensive cryptography knowledge to get started on a basic
algorithm?
Will C# be OK for putting an encryption algorithm into practice?

Any help would be sincerely appreciated. I want to start writing code so when it comes to applying to uni, I have something to show for all of my bold claims on my application!

Of course you can start small and implement your own algorithms. But do not assume they provide any security beyond obfuscation.

The difficult thing when it comes to cryptography is finding reasons why something actually is secure. You won't be able to decide that within months and if you feel like you are at that point, you are most probably wrong.

It is much easier to find reasons why things are insecure than reasons why they are secure, so if you want to start somewhere, develop your own algorithms until you think they are secure and then try to find out why they are not and find ways to attack them.

Most mistakes are made when implementing algorithms. So if you want to get a well paid job you could learn how to implement that stuff correctly.

I would recommend starting to implement something like AES and than continue to different operation modes like CBC or CCM and find out why randomness is important. Continue with SHA-2 and HMAC and proceed to asymmetric cryptography. Always check what others did and why they did it and have a special look at side channel attacks and how they are performed. If you are at that point you will find your way to go on.

The reference to start with would be the "HAC", which is freely available online: http://cacr.uwaterloo.ca/hac/

[Edit]
A suggestion from JRsz which shall not be buried in the comments. A good book for beginners: http://crypto-textbook.com/


How to give someone access to a file, on a website, securely without relying on a single password? I have created an online donation form for a Public Library.  The form collects names, phone numbers, emails, addresses (a lot of personal info). The form is submitted to a PHP script that saves the information to CSV file and forwards the user to a PayPal checkout form for the donation amount they entered. People are unable to access the CSV file because there is a .htaccess file with the following:

Order Allow,Deny
Deny from all

The people at the library would like to be able to access the information to send out thank you notes and for there records.

How can I give someone access to a file, on a website, securely without relying on a single password?

I though of using Basic Authentication but it relies on a single password that can be easily brute forced or too complicated to remember.  Additionally, it could be socially engineered, or forgotten.

Keep in mind I do not have shell access to the server or to the Apache config files.

The canonical answer would be — using cryptographic tokens.  In some countries or organisations, such tokens or ID cards may already have been issued and widely available.

But given the context, you should probably consider alternative delivery mechanisms.  For example, an automated nightly email to a librarian, with the newly added relevant entries in it, does not need introducing any new authentication mechanisms, has a fairly limited — and generally well-understood — maintenance expense and attack profile, meshes well with many modern styles of office routine, and has only one moving part that can be directly nudged by an attacker from the website end.  You should consider if the email needs to be encrypted or not, and which fields are relevant in its context, of course.


Router password vs MAC filtering? I just bought a Galaxy S4, and it didn't connect to the WIFI in my house (I have a 14$ router). After a bit of testing, I've decided to leave my connection open without a password, but added the devices manually to the whitelisted MAC addresses.

Is that safer than having a regular password, that can be broken with brute
force, or another technique?
Is there any other solution that I can try connecting my cellphone to the router?

The errors I got were "getting IP Address", and after that "error: connection too slow....". I have a good connection.

MAC filtering is not a part of the 802.11 spec, and is instead shoved into wireless routers by (most) vendors.  The reason why it's not a part of the 802.11 spec is because it provides no true security (via kerckhoff's principle).

In order for wireless to work, MAC addresses are exchanged in plaintext (Regardless of whether you're using WEP, WPA, WPA2, or an OPEN AP).  For encrypted wireless, the MAC address is either a part of the initial handshake (used to derive the session key), and/or exposed during pre-encryption communications.  In addition to all of these reasons, MAC filtering is also much more of a pain in the butt to upkeep than instituting something like WPA2-PSK.

Simply put, MAC filtering is not something that needs to be "cracked."  In open networks, people simply only need to sniff the air and they will be able to see what devices are working, and then they can use one of many, many extremely simple tools to change their MAC address.  In encrypted networks, they will need to sniff and grab a new handshake (which can easily be forced via a deauth attack).  From there, they have access to your network.

My suggestion is to use WPA2-PSK with a strong key for personal networks or WPA2-Enterprise with a strong EAP mode (PEAP or TLS) for enterprise networks.  The main difference between the two of these, aside from the method of authentication and authorization, is that with WPA2-PSK, if someone knows the PSK and can capture the handshake of a user, they can decrypt their stream.  That is not possible with WPA2-Enterprise, because it uses EAP, which has a different encryption key per individual via the EAP mode.  This is important because you wouldn't want just anybody with access to the network to be able to decrypt the CEO's wireless communications.

It is also important to note that with WPA2-PSK, your ESSID does play a part in the security of your network because of the following:

  DK = PBKDF2(HMAC−SHA1, passphrase, essid, 4096, 256)

Essentially, WPA2-PSK uses your ESSID as the salt when running PBKDF2.  For this reason, you should also attempt to keep your ESSID unique, to avoid attacks using rainbow tables.

In summation
 - MAC filtering does not provide any level of "true" security
 - Use WPA2-PSK if possible (Most smartphones do support it)
 - Try to have a unique ESSID


PCI Compliance for attachment in email I am wondering if they are any PCI compliance issues around users of a service sending email with attachments that may or may not contain sensitive information through said service?

As an example, if I were to to sign up to a service that lets me generate a document and I send that document to another person through the services web dashboard.

If you're asking whether a generic email provider such as gmail has PCI compliance issues because of what it's users may do, then no.  Consider the DSSv3 definition:

  PCI DSS applies to all entities involved in payment card
  processing—including merchants, processors, financial institutions,
  and service providers, as well as all other entities that store,
  process, or transmit cardholder data and/or sensitive authentication
  data.

While the situation you're talking about involves a case where the service provider is used to "transmit cardholder data", a generic email provider is not an "entit(y) involved in payment card processing" (at least not insofar as it's customers use it to send email; it may be insofar as it might charge those customers, but that's a separate issue).

The individual sending the mail has PCI obligations because it's their data, the carrier does not because it isn't.


inject update-motd.d 00-header to run a script on ssh login Is there a way to inject the 00-header to trigger a script that executes a shell upon ssh login.
I'm facing a scenario where the 00-header has root privileges and I can modify it. I'm trying to have it spawn a root shell when I ssh into the machine as a regular user.
sysadmin@********:/etc/update-motd.d$ echo "/bin/bash -i" >> 00-header

That didn't work... it didn't trigger a shell when I ssh'd into the machine... it did edit the 00-header file

The exact implementation is going to vary depending on which GNU+Linux distribution you are using, but it is probably safe to assume that those scripts are running under a separate user/process and not in a way that would ever allow you to interact with a command; it looks like the output may be written to a file and then displayed to you.
Also, you will probably need to make that script executable if you haven't already.
Instead, do something that doesn't require interactive input, such as creating a setuid shell binary or granting your user increased privileges.


Intercept https traffic Is it possible for a packet sniffer such as wireshark to be able to decrypt the traffic generated by a https connection from a browser ? I do not have control of the server, but I have control of the client browser (such as, modifying firefox options to force http, if that's possible, or giving it the client private key if it's somewhere on the firefox folders).

Thanks.

Firefox and Chrome use the NSS library which supports generation of SSL key logfiles. This file van be specified by the SSLKEYLOGFILE envvar.

Configure the SSL key log file at Preferences -> Protocols -> SSL and you can capture and decrypt on the fly.


Erasing Truecrypt keyfile(s) after volume has been mounted To improve security to some extent, I use keyfile generation technique (to change an existing file into an actual keyfile).

The actual keyfile is stored on volatile file system that doesn't survive computer reboot.

The question is, whether I may erase and delete the actual keyfile after the volume ahs been created?

If yes, then it could be safely overwritten and destroyed immediately after usage, further enhancing security associated with using truecrypt.

To improve security to some extent, I use keyfile generation technique (to change an existing file into an actual keyfile).

Are you using an external tool to do that, or something built-in to TrueCrypt? AFAIK you can use any type of file as a TC keyfile, but the file is used as-is, no transformation is done. From the docs:

  Note that TrueCrypt never modifies the keyfile contents. You can select more than one keyfile; the order does not matter. You can also let TrueCrypt generate a file with random content and use it as a keyfile. To do so, select Tools > Keyfile Generator.

Whatever method is used to "turn a regular file into a keyfile", you must make sure it's deterministic (i.e. always generate the same keyfile given the same input), otherwise you can't throw it away after use. And of course, if you generate it from a random source, you must keep it to be able to unlock the volume later.

  If yes, then it could be safely overwritten and destroyed immediately after usage, further enhancing security associated with using truecrypt.

I don't see how that will enhance security. If the original file is sufficient to decrypt a volume, an attacker that has access to it can also do the same, regardless of how many intermediate steps there are to transform it into the resulting keyfile. Same with keyfile+password vs. original file+password. That means you have to protect this file as well as you'd do with the keyfile.

You could argue that using an arbitrary file is safer than using a "standardised" keyfile, since there are so many of them in your computer, and the attacker must know which one is the key. A 64 byte file with random data "stands out in the crowd", so they would in principle be the first ones to be tried. That's a bit like "security though obscurity", but if you have no better way to protect your keyfile, this should give you a little more protection.

However, I must point out that since TrueCrypt accepts many keyfiles at once, and it does its own hashing to combine them together and with the supplied password, you shouldn't need to perform the intermediary step yourself (that just potentially increases the attack surface).

And for a reason to have many keyfiles: if your storage media has N files and K of them will be used as keyfiles, the total number of combinations your attacker must try is N! / (K! * (N-K)!). By carefully choosing this number you can make it much more difficult to brute force it, even if the attacker has access to all your files and a lot of time and resources to try them. (just make sure to scatter the keyfiles through different folders...) It's up to you to decide the tradeoff between security and convenience, since supplying all those keyfiles also has its cost - in user patience, which can be very limited.

Update: as per your comment, you're using 20 files out of 1000, which in principle would take a long time to crack (1.6 * 10^10 years at 1000 tries/second). However, you mentioned that the files are chosen based on user input, so I must point out this fact:

Despite the large number of possibilities to choose those 20 files (5.3 * 10^20 ~ 68 bits of entropy), not all of them are equally likely to be chosen, since the process is not random. In fact, each sequence of user inputs (lets call that a "password") will deterministically lead to a single combination. Thus, the entropy of your scheme will be at most the same as the entropy of your "password" (capped at 68 bits). In other words, an attacker that knows your process needs only to redo the same (against a list of "password" guesses) to get a viable combination of files - a better result than trying all them at random.

Also, you must make sure the logic for choosing those files does not leads to too many collisions. If two or more inputs lead to the same set of files, either of them can be used interchangeably. If that happens, the resulting entropy can be even lower than you'd get by simply using that user input as a password. And, unnecessary to say, using a password with more than 68 bits of entropy will have no effect (i.e. 11 characters or more), since at this point collisions are guaranteed to happen (contrast to the max 512 bits of entropy that you can get by using a random keyfile, or about 420 by using a random password with 64 printable ASCII chars).


How private is RAM from other users on a VPS? Can I safely assume that my RAM never can be accessed by another user on e.g. EC2 or Digital Ocean, if we suppose that I trust my provider and we don't consider possible bugs (such as Heartbleed) in my environment.

tl;dr: Virtual machine RAM is reasonably private, given your stated assumptions.

I'm not an expert on virtual machine security (real experts, please come correct any errors in this post), but I found this question interesting enough to do some Googling. Here's what I found.

From a NIST publication titled Security Recommendations for
Hypervisor Deployment:

  One of the common threats in virtualization platforms is a malicious
  VM accessing areas of memory belonging to other VMs. This is called a
  VM Escape attack. Processors with virtualization extensions provide
  safety against this through features such as Direct Memory Access
  (DMA) remapping limiting DMA access to what is valid for the VM (i.e.,
  preventing a VM from performing DMA beyond its allocated area).

This paragraph is saying that hardware-accelerated virtualization (which is pretty much all virtualization you will encounter in 2015) can enforce memory access restrictions pretty well--at least better than software-only virtualization.

The NIST paper goes on to suggest the following:

  Security Recommendation HY-SR-6: The ratio of the combined configured
  memory of all VMs to the RAM memory of the virtualized host should not
  be very high. A typical ratio adopted is 1.5 : 1. In other words if a
  virtualized host has 64GB of RAM, then the combined configured memory
  of all VMs running on it should not exceed 96 GB.

  Security Recommendation HY-SR-7: The hypervisor should have
  configuration options available to specify a guaranteed physical RAM
  for every VM (that requires it) along with a limit to this valu, and
  to specify a priority value for obtaining the required RAM resource in
  situations of contention among multiple VMs.

Popular virtual hosts, like EC2 and DigitalOcean, are likely to follow these guidelines for security and performance reasons. Their VMs would run rather slowly if they oversold the RAM. However, for a less popular VM host, I would not know if they followed the guidelines or not. Depending on the workloads of the guests, the host might find it profitable to oversell.

Now remember that the host can definitely store the state of your RAM, and any sort of vulnerability that allows arbitrary  code execution on the host can result in the reading of arbitrary VM RAM contents.

The NIST paper also suggests a vulnerability where the images used to create virtual machines are compromised, causing VM users to spin up instances that are already compromised. Amazon and DigitalOcean are likely to follow the NIST recommendations here as well--that VM images must have valid digital signatures and that the images for new instances cannot be modified from a machine running existing instances. Once again, a cloud hypervisor run out of some college dorm room might not have equivalent security on the images.

The whole NIST paper is worth reading--it is not very long--and so are the following Stack Exchange questions:

Memory Dumping - Cause for concern in Virtualization?
Does a Virtual Machine stop malware from doing harm?
Can a virtual machine (VM) “hack” another VM running on the same physical machine?
How secure are virtual machines really? False sense of security?
Are there ways to protect the guest kernels at the hypervisor level?


Brute force attacks detection risks I would like to ask if using brute force attacks on some websites or online services can be risky in any way for the hacker?
Let's say that someone is using medusa tool to crack password on his account at some server. Is this visiable for administrators and risky somehow for the potential attacker? Or is it just seen as a milions tries to log in to the particular server and not as a threat?
Can simple antivirus with firewall like lets say Avira detect this kind of penetration attempts?
Do you actually think that anyone is looking at the login attempt logs or are they just ignored by the administrators or do they even exist on a regular server? I know that I sound like a beginner because thats who I am, but i cannot find much information about it on the internet.

You didn't mention specifically whether you're referring to an online or offline brute force attack, but seeing as you mentioned medusa I'll assume online.

You also haven't said what protocol you're trying to brute force over or what application you're trying to log into. Eg. web app over HTTP, RDP, FTP?

  Is this visiable for administrators

Definitely. It's not certain that they log it but most HTTP servers store access logs and most login systems also record failed login attempts in some way.

  Or is it just seen as a milions tries to log in to the particular
  server and not as a threat?

No one would legitimately make millions of log-in attempts. If anyone did happen to look at the logs and notice it they'd certainly assume it was a threat.

  Can simple antivirus with firewall like lets say Avira detect this
  kind of penetration attempts?

Can't speak specifically for Avira but there's a chance your attack may also be seen as a DoS if the volume is high enough. Also, it's common for online applications to run an IDS (intrusion detection system) or a WAF (web application firewall) which would be more likely to detect things like this.

  Do you actually think that anyone is looking at the login attempt logs
  or are they just ignored by the administrators or do they even exist
  on a regular server?

As an example, HTTP access, SSH login attempts, etc. will be logged on just about every server. Whether anyone looks at them depends highly on who's running it. You can assume that most large scale systems will have considerable log monitoring in place.

There's also software that watches log files for failed password attempts and bans them automatically, such as fail2ban.

I think you've also discounted application level controls against brute forcing - any well designed login system will lock you out after a certain number of password failures.

Even in the case of an offline attack there's ways of detecting it, such as a honey pot account or honey words that will hopefully lead the attacker to log into an isolated account and alert you before they can log into a real account.


Is "Windows" mode inherently more secure than Forms authentication for .NET web apps? We have a web application being reviewed and I see the usual section in Web.Config:

<authentication mode="Windows">
  <forms loginUrl="~/Account/Login" timeout="10800" defaultUrl="~/"/>
</authentication>

The discussion here is whether this is inherently more secure than Forms authentication. One side of the argument is that Windows is fine as the user needs to have a Windows account to use the system.

My argument is "Sure, that's true but it doesn't mitigate every attack vector" and only provides the appearance of security.

Compounding this problem is the membership provider referencing a non-existing database connection and poor error handling, but this is a secondary problem.

What's the best argument to put forward around Windows Auth being treated as the panacea for web application security issues?

In my experience, the biggest problem is that Windows authentication tends to conflate authentication and authorization. Just because a user has a Windows account does not mean they should be able to access a resource!

A simple example would be machine accounts. In an Active Directory system, machine accounts get Kerberos tokens just like users do. Most implementations of Windows auth I've seen trust that just because a user can be positively identified (authenticated) they are also authorized to access the protected resource, so any machine account will be able to access the protected resource.


iOS VPN profiles - are the signing certificates global? Can this be a MITM exploit? I have installed an app on iOS to connect to a well-known VPN service. The app requests installation of a profile onto iOS, which as far as I can see are a collection of 7 certificates - 5 of which are signing certificates.

As a novice in this area who's sought to self-educate on the internet I may well have misunderstood. But, in theory, if 'rogue' signing certificates were installed in iOS wouldn't that allow a MITM attack to go unnoticed? That is, for a modified SSL certificate to be sent to the client, and the 'rogue' signing certificate confirm that the certificate is valid?

If that is the case, I am somewhat concerned about installing these signing certificates within iOS. Are the certificates global? So that, for instance, Safari would rely on them when verifying an SSL cert of a website? Or are they 'sanboxed' to the use of the VPN service? I've tried finding this information but can't seem to find any information on it.

Any help you can give would be greatly appreciated.

Thanks.

PS As an aside, even if there is no issue in installing these, I think vendors ought to let people know exactly what they're doing by installing certificates. With no information at all, the temptation might be to blindly install them.

No.
The profile you're required to install contains the parameter (and the certificates as well) to establish a secure tunnel between your endpoint and the VPN provider.
Once connection have been established,  at worst the ISP could perform (in abstract) the MITM attack because all your traffic is redirected throughout their server.
Perhaps, if you're concerned about privacy, keep in mind that all your browsing will be logged from VPN provider...

You can always have a look inside that certificates by using the apple configurator utility. You'll better understand how do they work on your phone policies.


How to stop other websites from sending cross domain AJAX requests? From two different applications, I was able to send cross-origin requests. Though the browser returns a "cross origin" error my server is still receiving and executing the request. For example, from a remote site I can invoke cross domain request using

$.ajax({
        xhrFields: {
            withCredentials: true
        },
        data:{ my: 'a' },
        url: 'http://MyApp/Page',
        type: 'POST'
})

I know that the browser does not return the response to script, but my server page still executes.

Let's say a innocent user is logged-in a site http://example.com. This application will accept POST requests to insert a record. When the innocent user visits  http://HackerSite.com, the http://HackerSite.com will be able to send a POST request to http://example.com via AJAX. How can this be prevented?

As well as via a cross-domain AJAX request with credentials, the POST in your example could also be sent by using a standard form without AJAX:

<form method="post" action="http://MyApp/Page" name="hiddenFormInIframe">

<input type="hidden" name="my" value="a" />

</form>
<script type="text/javascript">
  document.hiddenFormInIframe.submit();
</script>

This would also include cookies in the request.

The vulnerability you are talking about is called Cross Site Request Forgery.

You can guard against the POST being submitted from another domain by sending a header in your AJAX request and then checking the header server side. A common header to use is X-Requested-With. This header cannot be sent cross-domain via AJAX due to this header not being in the safe list (without CORS being enabled on your server). A HTML form cannot send this header either.

Only the following headers are allowed cross domain via AJAX:

  Accept
  Accept-Language
  Content-Language
  Last-Event-ID
  Content-Type

The X-Requested-With header is automatically set when using JQuery and you can check for this in your ASP.NET code.

However in the past there have been some exploits via plugins such as Flash where headers could be set that were not possible via a browser (e.g. Referer) so to guard against this it is recommended to use the synchroniser token pattern which involves setting a token in a hidden field or in a header. This token will be validated as well as the authentication cookie for all requests with side-effects. That is, requests that change, submit or delete (normally POSTs).

For more info on CORS see here: http://www.html5rocks.com/en/tutorials/cors/


How bad it is to install another company's root certificate to your server? Our company uses a web server with a couple of web sites on it (private and public, over HTTP and HTTPS, some low risk and some high risk including online payments or other sensitive data for example).

In our last project, we communicated with a partner company through web services. They wanted to use their own certificates, issued by themselves, to secure the connection. So we had to install their root certificate "PrivateCompany Root CA" on our web server.

Just how bad is this exactly? In what scenarios our security can be tampered with?

So we had to install their root certificate "PrivateCompany Root CA" to our web server.

Why? Globally trusted CAs are useful in general purpose clients like browsers.

But if you consume specific web services from a custom client you can add that CA locally. Every decent SSL client allows you to influence certificate validation. For example by specifying a custom list of CAs.

If you you do it this way, that CA can only be used to intercept those requests. Since the CA and the target domain are owned by the same entity, this doesn't pose a big risk. It's safer than using the standard CAs.

  Just how bad is this exactly?

If they (or somebody who managed to steal their CA cert) are in a MitM position relative to your server they can intercept any SSL traffic where your client uses the global CA storage. It's not limited to their domain.


How to re-issue the secret key in Session Resumption? https://wiki.openssl.org/index.php/SSL_and_TLS_Protocols  : Session Resumption

(snip)

  the protocol provides ways to reuse existing credentials to reissue
  new secret keys for new connections ( new TCP connections ) or to
  renew existing connections.

As per OpenSSL wiki: we can re-issue the secret key which was derived from master secret using session resumption.

I use session ticket-based session resumption. How can I re-issue the secret keys from the existing credentials?

I think you can't
I'm not sure. But I think if you resume, then you're stuck with the old keys. If you want to rekey, then do one of these things:

Start a new session right away.
Or, alternatively, inside the resumed session use "session renegotiation" to rekey. There is an original, insecure, and an updated, secure, version of renegotiation.

Update
This bit sounds interesting. But I don't really understand it. Sounds like you could sort of do a "rekey-lite":
Liberally reformatted from the Client Hello section of the TLS 1.2 RFC:
The ClientHello message includes a variable-length session identifier.
If not empty, the value identifies a session between the same client and server whose security parameters the client wishes to reuse. The session identifier MAY be from

an earlier connection,
this connection, or
from another currently active connection.

.

The second option is useful if the client only wishes to update the random structures and derived values of a connection, and
the third option makes it possible to establish several independent secure connections without repeating the full handshake protocol.


Complexity of web certificate attacks I heard a while ago about someone exploiting md5 weaknesses to create a web certificate with the same md5 that a different certificate has.

They were able to create a certificate through bad issuing policies and i think they had 200 ps3 calculating.

So I wondered, is it possible to scrape the whole web for certificates and create a database with all of them and use brute force to create a certificate that has the same md5 as one in the database?

So my question: Does anyone know the math behind this? I mean how many unique md5s are there?  I think its 32^16.  How many certificates are there with md5 (including outdated, they will still work) then estimate hash/min for an average computer.

I know that a lot of certificates have changed to sha1. I must say that I don't think this is possible but its a thought that have bugged me for a loooong time now and i need input! There's a lot of md5's but i have a fast computer ;)

MD5 has been deprecated due to the ease in which you can find a collision: a few years ago I wrote a paper showing how to generate an MD5 collision in under a minute.  This has since been refined to just a few seconds.

Generating two different postscript documents with the same MD5 sum leverages the fact that postscript is a computer language and postscript viewers evaluate this language.  It's a neat trick.  It works like this: File1 has a binary block Q, then some code, then document A, then document B.   When you display File1, it runs the code which examines Q then displays A.

Now we make a copy of File1 called File2.  We modify only Q to Q' which has the same MD5 sum as Q.  This means that File2 has the same MD5 sum as File1 since nothing else changes.  But now when we display File2 it runs the same code, sees Q' and outputs document B.  Cute!

But here we are using the fact that collisions are easy to find in MD5.  No one (as far as I know) can invert arbitrary MD5 digests, nor can anyone find a 2nd input to match a given file's MD5 sum (this is called "second preimage resistance").

So what you suggest above is still infeasible.  The math you asked for: MD5 outputs 128 bits, so the chance that a random digest will match a given one is $1/2^{128}$ and it will therefore take an expected $2^{128}$ trials to reproduce a desired digest.


What can I do if my bank thinks my date of birth is "known only to me"? My bank has recently replaced passwords with occasionally asking me information that is "known only to me". Such information includes my date of birth, postcode, and my mother’s maiden name.

Obviously these details are far from qualifying for "known only to me", and what’s worse, I can’t change these when they are compromised.

Is there anything reasonable I can do about this in the UK? I’m sure banks are legally obligated to implement proper security, and these days even people without any formal security education know that dates of birth don’t exactly qualify as "proper security".

I hope this falls within the scope of the site under the category of "policies".

Find a bank with secure online banking, withdraw all your money and move it.

Make sure the teller knows why. Send a registered letter to the bank president telling him why it's a bad idea and why you've told all your friends and acquaintances why this is a bad institution to deal with online.

It's known as voting with your money. They don't secure it and only appreciate its removal from their system. Enough people do it, and they either sink or change.


Can an old operating system webserver be made secure? I have an old laptop with far too little RAM to run Linux (including specialty distributions). It can however run Windows 98 just fine, and I'm looking into turning it into a tiny retro webserver.

Is it possible to keep an old operating system webserver from being hacked? All I'm looking for is a simple port 80 static website with no over-the-web administration abilities.

I have no significant experience with security, or exploiting security holes. So I'm not sure where to look. Can a DOS/WIN95/WIN98 box be exploited if all it does is respond to simple HTTP requests?

Probably not.  In order to respond to HTTP requests, the operating system must be able to run a TCP/IP stack, process packets, and complete a TCP handshake, all requiring the system to utilize or spawn threads in memory, call libraries, etc.  Therefore, the system would still be susceptible to protocol attacks it may not be patched for (TCP sequence prediction is one that comes to mind for a web server that might run on Win98).

You could compile and run a modern server like nginx or Apache (probably would have to heavily modify it, as it won't run on Win98 out of the box), but older operating systems being on a network are inherently prone to network probing and network attacks.  Even if TCP 80 were port forwarded through a firewall, the web server process would still be running inside of a system lacking modern protections like DEP, ASLR, etc.


Does there exist any exploit to read someone's old emails, but not recent emails? The only one I can think of would be if someone exports a backup of their inbox and doesn't encrypt it for some reason. Other than that, is there any case where someone could read your emails from days ago, but not within the past hour?

For context, the reason I ask is that some people think that email tokens should expire. That's completely useless because the attacker can just email a new token, unless he can only read older emails.

Even though I am not aware of an explicit exploit, I would draw a different conclusion. Anything that is security related should expire, because you can not know what will be possible in the future and because a token is a form of credential.

Here are some more reasons I would take into consideration, other than the (personal) backup.

Most important, reusing an old token would be complete non-detectable for the legitimate user. If the attacker must send a new token, at least the user has a chance to get a new mail notification etc. (I am aware of at least one real incident where a user has informed the IT department because of suspicious notifications on their phone for mails they could not find in the inbox - the attacker delete the mail right after they copied the data needed).
Mail is usually stored and forwarded a lot between servers. Thus besides the personal backup you need to consider that the the mail was at some time stored on any of the involved mail servers, maybe even backuped.
Your mail has passed most likely through several spam filters along the way and this be process by systems you might not be aware of.
Someone might have recorded a LAN/WIFI transmission where your mail was not encrypted (plain SMTP).
Once used, the link can show up in the browser history, even synced to other devices as well.

So while it seems to be hard for an attacker to target a specific user through old emails, there are still several attack vectors for abuse of the token for any user of your system.

In the end, you will have to check it against your threat model.


Is webRTC safe against man in the middle attacks? We are implementing an open source software package (copay, a multisig bitcoin wallet), that uses peerJS, which uses webRTC to allow peer-to-peer communication between browsers.

peerJS (and webRTC) use a signaling server to help the peers establish the p2p channel. My question is: Do  we need to trust that signaling server? Could that server compromise the p2p channel by doing a man-in-the-middle attack?

thanks a lot.
Our project home is: https://github.com/bitpay/copay

The answer is dependent on what "signalling server" you refer to.

WebRTC is MITM-secure against untrusted relayservers, STUN and TURN servers. Those servers only help the clients to set up a p2p connection at all.

However, the channel through which SDP is done needs to be trusted.

Unlike the relayserver, SDP carries no weight, and consists only of some strings sent by the clients for the initialisation of a connection. Those are accessible to javascript, and can be sent any way (HTTP, websockets, email) between the clients.

Therefore you should use a trusted channel for doing the SDP.

The SDP exchange carries a a=fingerprint: named hash, that authenticates the payload-bearing p2p DTLS connection to the other client. RFD 5763 contains a good description of that connection between DTLS and SDP.

You could reduce the content that needs to be trusted to this hash, but unless it serves no further purpose you are better off doing the whole SDP over a trusted channel, as you have less complexity.


What is httpvh:// and is it the result of something malicious? I was working on a client's old website and I noticed that some of their YouTube links were broken and looked like this:

httpvh://www.youtube.com/watch?v=jNQXAC9IVRw

At first I assumed it was some kind of typo, but then I realized that:

They probably didn't manually type the URL
It was like this on multiple pages
The links were probably correct at some point or else they would have noticed it
A Google search shows that quite a few websites, particularly old ones, have this exact same issue.

It almost seems like some kind of weird find and replace issue, but what kind of legitimate pattern would even cause that?

I can't find anything about this, and I'm not sure what kind of harm could come from it (aside from the links being broken). If it was caused by something malicious and the goal was to switch it to a phishing URL, then surely a valid link would have been more effective.

Not a full answer but I found this which seems to suggest it's something do with YouTube "Lyte", to determine the appropriate way to optimize the videos.

WordPress YouTube Lyte

It seems there are a couple other variations to the prefix: httpa and httpv (without the "h" at the end).


What network topology should be used in a SOHO environment with a publicly available web server? My home office setup currently has a wireless router running DD-WRT NXT connected to a cable modem. Connected to this router are a number of workstations which I do not have to deal with that I assume are all infected with viruses, malware and root kits, one workstation that I do my best to keep secure, and a NAS that I also do my best to keep secure.

Right now I believe the major threats are from the crap on other people's workstations and someone on the outside attacking the router. I am not worried about malicious users attacking from within the intranet.

I would like to add a web server to the network, but do not know how to best layout the network to minimize the additional risks. While the plan right now is to only host static webpages, I am betting it will be running wordpress in the future if I demonstrate that I can keep a web server running. While it would be nice to host the files for the web server on the NAS, I am willing to host them directly on the server if this improves security.

I was thinking about was simply adding the web server to the network and forwarding the appropriate ports from the router. Does putting the web server on a separate subnet provide any additional security? What about adding a second router between the web server and the main network (i.e., the cable modem is attached to router A which is connect to the web server and router B which is connected to the NAS and workstations).

There's two aspects you should consider:

The web server will be accessible from internet. That's a pretty big attack surface compared to all the other internal hosts.
Your internal network might be as dangerous as the internet, the web server should treat it as hostile as well.

You can address both aspects with a simple setup like this:

                   .--.
               _ -(    )- _
          .--,(            ),--.
      _.-(                       )-._
     (           INTERNET            )
      '-._(                     )_.-'
        |  '__,(            ),__'
        |       - ._(__)_. -
                     \           \
        |             \
                       \           \
        |               \
        |           _____\____       \
  Only port 80     [_.Router.°]
        |           /        \         \
        |          /          \        No incoming traffic
                  /            \         \
        |        /              \
        |       /                \         \
        v      /                  \         v
     .Public network----.         .Private network.
     |  ________        |         |  ____   __    |
     | |==|=====|       |         | |    | |==|   |
     | |  |     |       |         | |____| |  |   |
     | |  |     |       |         | /::::/ |__|   |
     | |  |     |       |         |               |
     | |  |     |       |<- - - - |               |
     | |  |====°|       |         '---------------'
     | |__|_____|       |  Pt 80 only
     '------------------'

The dotted lines represent logical connections and the full lines are physical connections.

You just setup a separate subnet for the webserver and only allow access to it on port 80 (and perhaps 443).

You should be aware that this makes your router a single point of failure. In a SOHO environment this is usually the case anyway, but it doesn't necessarily have to.

Once this gets beyond the "just to see how it goes" phase you may want to consider hosting it on AWS or other cloud provider. You get the same level of control, much better redundancy, amazing scalability and great security for pennies.


Nil events in IPS reports today The IPS reports have one or two events minimum every day so far. But today there were no events, both in DC1 and DC2 reports. I am wondering if this possible? How come on a particular day nobody attaked us? Has anyone experienced similar situation?

Script kiddies need holidays too.
Seriously, how about the answer "coincidence"? If there are usually one or two per day, it´s not that hard to believe that some days have 0. Just random background noise in the internet.

Or maybe there was a single person repeatedly trying to get into your net. In this case, things happen to people. Computer broke; hospital, drinking the whole day because girlfriend left...

Or maybe someone got into your net and thought it would be a good idea to delete the log.
Maybe. If the missing attack is the only problem, I wouldn´t panic. If it lets you sleep better, check some more things, and if everything is ok, forget it.


What was the first version of Android to use OpenSSL (and what version was it)? What was used prior? Android 1.6 source is the earliest I can find that references openssl
(i.e., has OPENSSL_VERSION[_TEXT] defined

The script I ran to get these versions was:

$ git clone https://android.googlesource.com/platform/external/openssl && cd openssl
$ for ANDROID_TAG in $(git ls-remote --tags| colrm 1 48| grep -v "\^{}"); do git checkout "$ANDROID_TAG"; OPENSSL_V="$(cat openssl.version)"; [[ -z $OPENSSL_V ]] && OPENSSL_V="$(grep OPENSSL_VERSION_TEXT include/openssl/opensslv.h)"; echo "[$OPENSSL_V] - [$ANDROID_TAG]" >> openssl.versions; done

However, if you check the tags in that Git repo, there appears to be nothing earlier than 1.6. The Where and how can I find and download Android 1.5 soure code? question on SO has broken links to 1.5 source, and though I was able to find the Java sources, but not the entire platform there I'm unable to look at the version.

So, my questions: What was the first version of Android to use OpenSSL? Was it used since 1.1? If so, what version? If not, what else did they use?

To the best of my knowledge, OpenSSL libs were part of "external" from day one. At least, I remember it in the not-yet-opensource 0.9 tree circa 2008. I am sorry to confess, I don't remember which version of OpenSSL was included there. All I know, it was not upgraded for a long time.


Is it insecure to publish the private IP addresses of my devices? I'm interested in both IPv4 and IPv6, but more-so IPv6 because of how unfeasible it is to find valid addresses by just guessing-and-checking.

Edit: My concern is that more trust may be given to IPv6, because "knowing" a valid IPv6 address has a greater implicit trustability than "knowing" a valid IPv4 address. I could totally see router manufacturers not adding in checks to reject ULA recipients from the WAN, or software developers leaking more information to IPv6 connections as a result of that.

If you are behind a NAT, which you assume in your question, it's not a problem to publish your private IP. Only devices in your private network can use your private IP to connect to your device.

If someone tries to connect to your private IP from outside your private network, he will reach someone else (or not even that), because there is no relation between your private and public IP.


How secure are SSL client certificate authentications? As far as I understand it's possible to issue SSL certificates, which could be used by clients for authentication. So in theory only users with valid certificates would be able to access a certain web service.

So is safe to assume, that if SSL client certificate authentication is used,  possibly vulnerable, high impact web applications could be exposed to the internet without risk of access by unauthorized persons?

How does this compare to using VPN?

If you use a VPN you still need to authenticate the user to establish the VPN. A client certificate is a very good authentication factor but should be used in conjunction with a password as there are several examples of malware that steals certificates in addition to other ways they can be compromised. Client certificates tend to have a support overhead associated so not practical if you have a small support organisation and/or a lot of users.

There are also many other ways a Web server can be compromised such as through vulnerabilities,  SQL Injection etc. (Though VPN or certs reduce the liklihood somewhat due to reduced public attack surface). You could also consider something like Google Authenticator.


How to create a secure BBCode? Right now, people can use XSS in my URL BBCode, and I don't know how to fix it. I had attempted to fix it a while ago, but someone some how bypassed it!

function filterScript($content) {
    $pattern = array('/href="javascript:[^"]+"/', '/style=":[^"]+"/');
    $default = array('#', 'color: #337ab7; text-decoration: none');

    return preg_replace($pattern, $default, $content);
}

function bbcode($input) {
    $search = array('/\[a url="(.+?)"\](.*?)\[\/a\]/is');

    $replace = array('$2');

    $bbcoded = preg_replace($search, $replace, $input);
    return filterScript($bbcoded);
}

Yes, I do use strip_tags, mysql_real_escape_string, and striplashes.

The specific problem with your code is that you don't actually escape anything and allow user-defined HTML code at multiple places.

This is the code you create:

$2

The values $1 and $2 are user-controlled and both need to be filtered (in different ways).

For $1 you need to make sure that it's not possible for an attacker to escape from the attribute by supplying double quotes ("). One way to achieve this is using htmlspecialchars(). Another problem (which you tried to address) is that links can start with pseudo-protocols such as javascript:. Therefore you should also whitelist a few plausible URI schemes. A restrictive but safe method would be to limit the input to URLs starting with http[s]://.
For $2 you need to disallow any HTML tags. Again, a quick-and-dirty solution would be applying htmlspecialchars(). But note that this can cause problems if you plan to support nested BB tags.

The general problem is that regular expressions are not the right way to process nested markup, especially not for security purposes. It's very easy to mess this up. Try to rely on the tools of your framework or use libraries such as HTMLPurifier. You should also look at some basic guides on preventing XSS.


User associated email address viewable in it's personal settings Some applications tend to hide completely the user associated email address or just showing a part of it (e.g. f***o@foo.com) in the user's personal settings. Other applications don't mind showing the full email address.
What are the security implications of knowing the email address of a possible compromised account? Why some applications hide it, especially in username and password based authentication?

One compromised account should be enough leverage to compromise others. The user knows their own email addressed; they just need a reminder of which one they used in the account.
Knowing the email address means that the attacker can use info from the compromised account to phish the victim with something specific.


Facebook 'Where You're Logged In' IP does not match actual IP In Facebook, go to "Settings" > "Security and login" > "Where You're Logged In", and hover the mouse over the characters which describe your location. You should see your IP.

But when I do it, its not matching my actual IP (now, because apparently it always matched before).

I'm not using a VPN or a proxy, and I'm not accessing Facebook from any other devices. What could be happening?

There are quite a few apps that interface with FB. In addition to flat out showing the wrong location for an IP, I suspect FB gets confused and maybe shows your location as the most frequently logged in location rather than most recent or currently active login. I have a calendar app that syncs my FB events to my google calendar on the hour. Logging out of FB, clearing my web cache, and logging back in doesn't fix the location issue.

After "ending all activity" on the FB Security and Login settings, which forced my calendar app and all the others (like Bumble) to disconnect, then logging back in, my location corrected. It also corrected to my actual location, rather than just my ISP's central location.

This is hardly a fix or an answer to the problem, but it's a way to get your location corrected if you're willing to give up the utility of FB interfacing apps.


How to store clients SFTP credentials in a web application I'm developing a web application for backups service. What's the best way to store SFTP/FTP credentials in the database? I guess they should be encrypted, then decrypted at runtime?

The ideal way to handle scenarios where you need a user's authorization would be to use something like Oauth, but given the fact that OAuth doesn't apply for SFTP, yes, you would want to store them in an encrypted format, and decrypted them at runtime. Encryption is incredibly hard to do correctly.  Many experts who have done it for years still make mistakes.  While I can't spell out specifically how your application should work, I can give some guidelines.

Make sure you're following proper cryptographic protocols. This will be the hardest part.  You will need to do some studying for this.
Make sure to use a well-known library such as NaCl or BouncyCastle.  They are nice, high-level libraries which make it harder to make mistakes.
Choose the proper algorithm.  You will want to choose a symmetric block cipher like AES-256.  Asymmetric encryption or stream ciphers are not meant for the task which you are trying to accomplish.
Store your encryption keys in a separate datastore from your encrypted data.  If your database containing your ciphertexts is breached by a sql injection attack, you don't want the decryption key to be included along with that.
Make sure you're accounting for people having duplicate passwords.  Encryption is deterministic, meaning, if you use the same encryption key and the same plaintext, you will get the same output.  This can be fixed in a couple of different ways: either using a unique encryption key for each client (probably not practical), making sure you use a unique IV (and choosing a mode of operation which supports IVs), or adding a unique value to the front of the plain text (again, making sure to choose the correct mode of operation.

This is not meant to be a be-all end-all list of how to implement the encryption securely, but it can at least get you pointed in the right direction.


shred - different device size When I need to properly wipe a harddrive, I tend to use shred on the whole device, i.e. pointing shred to the /dev/sdX without regard to particular partitions; however I noticed that the device size listed by shred command in the progress lines is always approx. 7 % smaller than the device size listed by fdisk (on a 500 GB disk, shred would be showing 466 GB). Thus I wanted to ask, if shred really wipes the whole drive properly using the method above, or if there still might be some areas of the disk, that remain untouched (or perhaps if it just incorrectly shows the size, calculates it differently...)

You are seeing a consequence of the ongoing war between binary and decimal systems.

Namely, 210 = 1024, which is close to 1000. Hence a widespread habit of saying "kilobyte" (as in "1000 byte") for a quantity of 1024 bytes. When we go to megabytes and gigabytes, the deviation increases: 220 = 1048576, and 230 = 1073741824. Therefore, if tool A displays a size in "decimal gigabytes", it will show a number that is 7.37% higher than tool B that sticks to the traditional "binary gigabytes". This is what you observe here: fdisk uses "true gigabytes" (1000000000 bytes each) while shred reports the same size with "binary gigabytes" (1073741824 bytes each).

Some people have tried to solve the ambiguity by talking of kibibytes (and mebibytes, gibibytes...) for quantities related to the "1024" scale. This would solve the issue if the names were not so ridiculous.

In older times, the "binary" versions were prevalent, but in the late 1990s, hard disk vendors figured out that they could put stickers with bigger numbers on their disks if they switched to the "correct" (decimal) units (the kilo/mega/giga prefixes are part of an international standard that extends way beyond computer matters). RAM vendors resisted, and still use the binary scale (so when you have a "1 GB RAM chip" you actually get 1073741824 bytes of RAM). On the other hand, the telecom industry has used decimal for decades (100 Mbit/s ethernet works at 100 MHz, not 104.9 MHz).


Can computers built in minecraft be used to hijack hosts? As people build more powerful computers in minecraft which can then run programs, is there a way to use those computers to run programs that hijack the host in some way?
Possible contest example would be to use a computer built in minecraft to create a network connection from that computer to a specified target.
There's a lot between inside the game and the target, but in principle is a computer inside a gameworld not much different than a virtual machine and its relationship to its host?
Will this become exploitable and worth considering?

That just sounds like a Minecraft exploit with extra steps...
If that ever becomes possible, then the issue is not the "computer" that was built inside, but the vulnerability in Minecraft to allow it. And at that point, you just trigger the vulnerability. No need to go through the work to build a computer...


Can a form submission be encrypted even though address bar shows HTTP? I was going to apply for a Student ID card through ISIC, but noticed that the form where they ask for payment (such as credit card number) details is not available through HTTPS.

The URL to their purchase form is http://www.myisic.com/get-a-new-card/

I asked ISIC about this and they replied with that the form submission is encrypted.

Is it possible to encrypt a form submission reliably when the form is accessed through the HTTP protocol?

How can a user in this kind of case confirm that the form submission is encrypted, since the browser (in my case Firefox) does not indicate encryption by highlighting the URL in green?

To expand on Thebluefish's answer, the form submission process appears to use HTTPS (an encrypted protocol) for the credit card element to https://connect.firstdataglobalgateway.com/IPGConnect/gateway/processing when I am looking at the page.  But this does not mean this setup is safe to use.

The overall setup is very vulnerable and needs to be fixed.  I would not submit any credit card details through this service and would recommend that you do not use it.  If you absolutely need to use it, you should get a prepaid credit card with just the amount necessary for this service and then use that credit card to minimize the damage if it is stolen.  Or if your credit card offers one time use credit card numbers, you could possibly use that (though again, would be at some risk of the one time use credit card being captured and used for a different purchase).

The problem with the page is that everything but the form submission is being sent over unencrypted HTTP, that any network attacker can trivially alter.  E.g., an attacker could buy a domain and then change the domain where the HTTPS form is sent to one they control (that may even look similar).

They could keep the form sending the data to the correct domain via HTTPS, but insert malicious javascript anywhere on the page or in one of the libraries to bind an action to additionally send the form data to some attacker controlled URL.

Again, we could look at the page as it renders right now for us and determine it doesn't do any malicious actions.  But any router/ISP/computer between you and the server www.myisic.com could change the current content of the unencrypted http page to something malicious allowing your credit card details to be stolen.