How do you make sure a pdf is deleted after being viewed in the browser?

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

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

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

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

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

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

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

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

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


Overwrite return adress with a format string vulnerability without gdb

I found my answer here: https://stackoverflow.com/questions/17775186/buffer-overflow-works-in-gdb-but-not-without-it

My problem was my shellcode is load in a environment variable.

So for bypass this problem, I used a return libc attack!


Protocol for secure communication over HTTP

You ask for tunneling a protocol (like HTTPS) through plain HTTP. And yes, there is at least httptunnel which does this. From the descrition:

  HTTPTunnel is a tunneling software that can tunnel network connections through restrictive HTTP proxies over pure HTTP "GET" and "POST" requests.

But note that if you work in an environment where use of HTTPS is restricted for security or productivity reasons, using such a tool to bypass the block is usually a violation of the policy. And usage of the tool can be detected because it shows abnormal traffic patterns.


Why is it unsafe to send a user their password via SSL encrypted communication rather than always sending a reset link?

Three huge problems with this:

The server must be able to send the password, meaning the server knows the password, meaning the server admin/owner can read it too. This should never be possible (see many many topics about hashes, salts, and multiple-round derivation functions). While an admin with all server access already can impersonate users etc. as wanted, many users use their password for multiple things. The admin shouldn't be able to access these.
If the server is hacked, the same is valid for the attacker: They should not be able to read passwords, because they shouldn't be able to reuse them in other places.
And no, SSL is not "completely secure". Especially, TLS exists because SSL is pretty insecure (but TLS isn't perfect either).


Monitoring the HTTP(S) calls being made from android App

Some apps are configured with hard coded CA certificates or internal certificate stores. This means you can't make them trust your certificate by adding a CA in the shared certificate stores. This is quite common security measure e.g. in the financial industry.


Android: Are locally-stored encryption keys readable by attacker who gained root access?

Yes, if an attacker has root on the machine they will be able to read all secrets stored on the device.  root can attach a debugger to any process and observe memory or hook function calls.

A mobile app should not attempt to hide secrets from the user, and server-side functionality should not trust mobile clients.  These are common mobile vulnerabilities.    Some apps attempt to detect root'ed devices,  but this can always be bypassed.


What good does the Kerberos Authentication Server

In fact they are the same, and that is called the Key Distribution Center (KDC).

The kerberos has three heads (like a cerberus):

The KDC that consists in the auth and the ticket granting system.
The Service.
The user of the service.

The issue here is that what is really happening is:

Alice authenticates herself against only one machine.
Alice gets a ticket for an specific service (here is one of the tricks, she is authenticated but he hasn't access to all services, just the ones she asks the tickets for so she may be able to access the printer servers without compromising the "production servers" which she is also an admin). You are establishing boundaries.
The ticket grants you access to the servers.

So, in fact, the servers "doesn't allow anybody" to get into, they just allow valid tickets. Think of it like going to the movies:

You buy your tickets at home online (this would be like the auth phase, where you present your credentials, name, card number...):
You go to the ticket machine and "auth" yourself with your credit card or an id number (the #1 step token), so it gives you a ticket.
The guy at the front check your ticket and allow you to go into if it is the right session and the right place.
You watch the movie.

As you can see "1" and "2" are very different operations and you will never have to show the guy at the front your credit card to let you go into the movie =)

Hope this helps a bit =) (Also, I have checked my notes and I have this link for you. )


What should I do if I'm receiving Tiktok verification code even I don't use and have deleted the application in my android device?

When you delete the app, then the account with your password still remains (in case you later decide to reinstall the app).
It appears someone was trying to log into your Tik Tok account, couldn't, and then used the "forgot password" function. This doesn't necessarily mean malicious intent. It is possible that someone somewhere in the world registered an account with a very similar account ID, mistyped it, and now erroneously tries to log into yours believing it to be theirs.
If the messages are not too distracting, you can just ignore them as spam. If they do annoy you, then you should delete not just the app but the account (which according to this guide requires to reinstall TikTok temporarily). 30 days later your account will be permanently deleted, together with any PII, including your phone number (hopefully - it's a Chinese company and they aren't bound to the same data protection legislations as US or European companies)


How can i find what hashing algorithm was used?

The algorithm here is:

function makehash(pw, mult) { // Password and... multiplier?
    pass = pw.toUpperCase(); // Case insensitivity
    var hash = 0;
    for (i = 0; i < Math.min(pass.length, 8); i++) { // 8 char passwords max...
        c = pass.charCodeAt(i) - 63; // A = 2, B = 3, etc.
        hash *= mult;
        hash += c;
    }

    return hash;
}

I cleaned the code up a bit and added some comments. Whoever wrote this is utterly incompetent in the fields coding, security and mathematics. Anyway, it is no "official" algorithm like MD5 or AES, but homebrew and incredibly fault-intolerant. It accepts only letters, is case-insensitive, and ignores all characters after the first 8.

I would highly recommend upgrading everyone's password hash. See also:
How to securely hash passwords?

By the way, here is the rest of the code with some formatting:

var params=new Array(4);
var alpha="ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHI";

function check(form) {
    which = form.memlist.selectedIndex;
    choice = form.memlist.options[which].value + "|";
    if (choice == "x|") {
        alert("Please Select Your Name From The List");
        return;
    }

    p = 0;
    for (i = 0; i < 3; i++) {
        a = choice.indexOf("|", p);
        params[i] = choice.substring(a, p);
        p = a + 1;
    }
    h1 = makehash(form.pass.value, 3);
    h2 = makehash(form.pass.value, 10) + " ";
    if (h1 != params[1]) {
        alert("Incorrect Password!");
        return;
    }

    var page = "";
    for (var i = 0; i < 8; i++) {
        letter = params[2].substring(i, i + 1)
        ul = letter.toUpperCase();
        a = alpha.indexOf(ul, 0);
        a -= h2.substring(i, i + 1) * 1; // multiplying by one? Seriously?
        if (a<0)
            a+=26;
        page += alpha.substring(a, a + 1);
    };
    top.location=page.toLowerCase() + ".html";
}

I would add comments, but I'm not sure if it's worth it to find any reason in this mess.


Does it have sense to fuzz a ASCII file format with mutators that mess with Unicode or String Case?

Definitely include it. Assuming you're trying to fuzz the html file parser itself, it will definitely be worthwile to include unicode mutators to see if the parser handles it properly.


Security implications of reusing unused One-Time Password

RFC 4226 was defined way before google formed the idiom of "two step verification". Two step verification does not necessarily has to do anything with HOTP or TOTP. Of course you can use HOTP to create "non-guessable" codes, but it is not necessary.

Your service could simply remember which code was sent to the user.

In any case you should:

create a code for each login attempt and
the code (even with HOTP) should only be valid for a certain time.

The implementation in privacyidea does it this way. It can send codes via text message or email to the user. These codes are calculated based on HOTP. But the codes are only valid for a certain amount of time.
And the code is only valid for this very login session.

The question is, if the code residing in the smartphone or the email account is probably though to be more vulnerable. A dedicated attacker probably would not care if the code is on the mobile phone for 30 seconds or for 30 hours. But ask yourself. I would feel uncomfortable carrying around my smartphone, knowing that there is a code in it, that still can be used to login to any of my accounts. Sometimes the smartphone is not locked, or a malware could be installed just in this time - after receiving the code and before using the code. There are additional attack vectors. So you should invalidate the code after a few minutes.


Is this in a corporate setting?

If so, make a key without a passphrase, print the key on paper, stuff it in an envelope, and hand it to your HR or financial department. They're probably used to keeping stuff around for long times, and should have proper procedures for maintaining secrecy.

As it's on paper, it's a format we know the archival properties of; good paper easily keeps information legible for ten years. When you need the key, OCR it. If you print it in hexadecimal OCR will be highly accurate. You could even include QR code, which is even quicker to decode. Worst case? Punch it in by hand - this would probably take you an hour or two, but doable.

What you are doing is essentially trading a large, difficult-to-keep secret for a small, easy-to-keep secret.


The answer is no and yes too.

Why no: It's a HTTPS traffic and firewalls these days have application identification or deep packet inspection (whatever you call it). That will identify the application you are using, but not the actual traffic.

Why yes: If the IT has implemented "SSL decryption" on their firewalls they can actually see the data inside it very clearly. That's the control they have and you won't even know your traffic is being decrypted. You can confirm this by checking the certificate you are getting once you access any site (man-in-the-middle).


This is most likely an obsolete "bridge" now leading to the wrong place.

There are two valid trust chains for this cert. There is a root cert for GeoTrust Global CA, valid from 2002, which is in current Windows/IE and Firefox stores (and Java); and also a "cross-signed" cert for that CA under Equifax Global CA as follows:

Data:
    Version: 3 (0x2)
    Serial Number: 1227750 (0x12bbe6)
Signature Algorithm: sha1WithRSAEncryption
    Issuer: C=US, O=Equifax, OU=Equifax Secure Certificate Authority
    Validity
        Not Before: May 21 04:00:00 2002 GMT
        Not After : Aug 21 04:00:00 2018 GMT
    Subject: C=US, O=GeoTrust Inc., CN=GeoTrust Global CA
    Subject Public Key Info: <snipped: same as root>
   X509v3 extensions:
        X509v3 Authority Key Identifier:
            keyid:48:E6:68:F9:2B:D2:B2:95:D7:47:D8:23:20:10:4F:33:98:90:9F:D4
        X509v3 Subject Key Identifier:
            C0:7A:98:68:8D:89:FB:AB:05:64:0C:11:7D:AA:7D:65:B8:CA:CC:4E
        X509v3 Basic Constraints: critical
            CA:TRUE
        X509v3 Key Usage: critical
            Certificate Sign, CRL Sign
        X509v3 CRL Distribution Points:
            Full Name:
              URI:http://crl.geotrust.com/crls/secureca.crl
        X509v3 Certificate Policies:
            Policy: X509v3 Any Policy
              CPS: https://www.geotrust.com/resources/repository
<snip signature>

This is apparently a "bridge" cert, often used when a renamed (here) or new CA root is created and wants to temporarily leverage the existing trust of an older CA root; the Equifax root is valid from 1998 so in say 1999 and 2000 there were lots of clients that would know the Equifax root and not the GeoTrust root. 12 years later it should be obsolete.

Running 'openssl s_client' confirms www.google.com.ua is providing in the SSL handshake its own cert, the Google Internet Authority G2 intermediate cert, and the bridge cert. IE, FF, and Java are all smart enough to ignore the bridge and use the GeoTrust root which they have internally stored. OpenSSL, which curl uses, is not, or at least not yet; thus you must tell curl to give OpenSSL the Equifax root. (The OpenSSL 1.0.2 release, currently in beta, is announced to have enhancements in the area of cert chain validation, which I haven't looked at in detail yet.)

EDIT 3/13: I can't comment on my answer(!) so adding here. As I said,
there are TWO certs for GeoTrust Global CA: one root, and one "bridge".

IE/Windows and FF DO have the GeoTrust root; you already saw it in Certification Path in IE or FF with the webpage open, or you can look directly in the truststores with InternetOptions/Content/Certificates/TrustedRoots and Tools/Options/Advanced/Certificates/Authorities. Both also have the Equifax root, but don't use it here. Both IE and FF display the certification path used even though it differs from what the server sent; that may be "wrong" in one way of looking but "right" in another.

A root cert is always self-signed; that's necessary to be a root (not always for an anchor, but leave that aside). The GeoTrust root cert is a root. The GeoTrust bridge cert is not a root, it links to the Equifax root cert which is a root. And, again, the Equifax root is the one curl + openssl needs.

EDIT 9/01: https://knowledge.geotrust.com/support/knowledge-base/index?page=content&id=AR1426&actp=search&viewlocale=en_US&searchid=1283360269668 confirms this is a bridge cert back to Equifax.

UPDATE 2017/03/28: first, OpenSSL 1.0.2 did add -trusted_first which uses the GeoTrust root if present and ignores the bridge cert. Second, this is now more important because the Equifax root has been removed from the Mozilla/NSS truststore, and thus the curl-project CAfile used by many clients, see https://serverfault.com/a/841071/216633 .


MD5 type encryption seems a bit pointless given how quickly it can be decrypted,

Don't get your terminology mixed up. MD5 is a hash algorithm, not an encryption algorithm. There is a world of a difference between the two.

To answer your question, I don't see an issue with storing the seed unencrypted together with the username and password in a database. A TOTP seed is easy enough to reset if you ever get compromised. You need the seed in cleartext for the algorithm to work anyway.


What is setuid based script root spoofing?

This is a theoretical attack that could allow a user to elevate their privileges to root.

Say we have a setuid-root script.sh like this:

#!/bin/bash
echo Hello World!

When the script is executed, the OS reads the first line, the uses that program to run the script. The command it will execute is: /bin/bash script.sh

A twist on setuid scripts is that a user can create a link to the script, say myscript.sh
and now the command would be /bin/bash myscript.sh This is starting to be a bit worrying because perhaps the user could call their link -c ls - and run a command as root that they're not supposed to.

However, bash and Linux have a number of other defences that make this impractical. For example, the command on Linux would be /bin/bash "./-c ls" which is not exploitable. It's possible that other shells and OS are vulnerable.

All of this only applies if you have a setuid-root shell script. This is not recommended anyway - for these reasons and more. In fact, on Linux you can't have setuid shell scripts at all.

If you're interested in this area in general, Nebula is worth a look.


You can try Wizcraft's block list, and format it accordingly. At the time of my post, this blocklist was last updated on Thursday, 24-Dec-2015 11:01:52 MST. Keep in mind, Taiwan is not part of Mainland China, but that Hong Kong now belongs to, and is controlled by Beijing.

If you only use your server in America exclusively, you could use all of those rules to block attackers. If not, edit out the ones you don't want, and keep the ones you do.

Also keep in mind, this will not stop attackers from connecting to a VPN in a country of their choice, and once again attempting to login as root. This is merely a band-aid.

EDIT - BadSkillz and Jenny D have recommended fail2ban. This will probably be a better solution overall, but it probably wouldn't hurt to use both methods.


Moving Infected Files to Trash versus Quarantining them

A quarantine is a place for you to review files that caused alerts. It's not about security, but convenience.


Blind SQL injection and "normal" SQL injection are both SQL injections, i.e. the attacker is able to modify the SQL statement sent to the database. The only difference is that with blind SQL injection the attacker does not see any obvious result (i.e. data returned by the database) but can only deduct from timing, error messages or similar what happened in the database. See OWASP for more information.

Because the cause of both blind SQL injection and "normal" SQL injection is the same the prevention is too, i.e. make sure that the attacker cannot modify the SQL in a malicious way. The preferred way to do this is parameter binding and not escaping (i.e. mysql_real_escape_string). For more information how to do it right see Bobby Tables: A guide to preventing SQL injection which both describes the problems and has also solutions in various languages like for PHP.


Using given RSA private key without the associated public key

Now as I understand this a game, certain liberties might have been take.  I could be wrong is it possible that the game did the following:

Installed the public key in authorized_keys
The private key isn't encrypted, not requiring a password
Restricted access by IP, so only local clients could connect.

Pretty contrived (it is a game after all), and no one would really do this... but it would fit the scenario.


Firefox redirecting to other webpages and Adobe Flash Player plugin update button redirects to other webpage (not the adobe offical page)

Have you tried updating flash via adobe flash update application(not firefox) Link: https://get.adobe.com/flashplayer/otherversions/ as for the redirect issues try creating a new user profile sounds like u got some malware https://addons.mozilla.org/en-us/firefox/addon/profileswitcher/

If making a new user profile does not work i suggest installing anti-malware bytes if your running windows and running a scan.

Hope this solves your issue.


Flooding the CAM table to force the switch to fall back to hub behavior (broadcasting all packets to all ports) is an "attack" only if you consider the normal switch behavior (sending the packet only on the "right" link) to be a security feature -- which it is not. Switches are an optimization, not a protection. Unfortunately, the idea that "switches protect against snooping" is widespread (but wrong).

Besides flooding, other kinds of "attacks" include sending packets with a framed MAC address, so that packets meant for a given host are misrouted. Such "attacks" will work on all switches, because they just exercise the job that the switch is meant to perform (some switches can be configured to maintain a static list of MAC-to-port translations and at least raise a warning flag in that case, but this is an orthogonal issue -- some switches incorporate all kinds of firewalling and filtering and may have an IP address themselves, and can generally be thought as a merge between a switch and an host).


Why aren't the TLD registries the TLS CAs?

simply because CA's predate TLD Registrars. The whole Idea of Certificates have there origins in the DAP times (Directory Access Protocol), When the Idea was more along the lines of Central Directories giving Authority to specific users from certificates. (I am paraphrasing here)

For historical reference. the first DNS (BIND) is from 1984. Many years after.


It really depends on developer of the ransomware. Ransomware itself is just malware requesting payment to get removed from your computer. To influence the victim to pay techiques such as preventing or making an particular task more difficult.

The unlock code will be just an cryptography public/private key. So, the victim will only have the public key and owner will have the private key which will be provided on payment of the victim to release the malware from the machine. You don't need to run a website for the private key as whatever prompt the user for payment will just expose the public key. So, the owner can will have private key to go with that public key.

Wiki - Public-key cryptography

Wiki - Ransomware


tunnelling HTTP request through DMZ from a secured area

A normal proxy (aka forward proxy) is an infrastructure service. I mean it's a service "somewhere underneath" your customer/business service. Just like internal DNS or monitoring or iLO/iDRAC.

How much separation is needed from the hostile world? Much vulnerability appears at the point where your systems listen. Manage that first, think about other reasons later.

Allowing a normal proxy to listen to requests from DMZ adds risk. Since the financial cost doesn't change much, I'd say place it deeper.

Deeper could mean in web application server segment, but it would be best to place it in separate infrastructural segment (depending on cost).

Having resolved the listener part, now the connector part. It follows you can "tunnel at the router level", which is probably better known as "route that traffic".


Allowing WhatsApp data through specific bundle

Your network provider will see to which servers on which ports your device will connect.  Your WhatsApp client will connect to well-known servers. So your provider will probably put the traffic you make over some WhatsApp servers into another category than any other traffic.

This can be done by passively looking at your traffic. They probably have some netflow data which provides those information.

The only thing you'll reveal to your provider is that you sent n Bits of data to WhatsApp. But the provider knows this anyway.

However there is some chance that the provider could try to execute a man-in-the-middle attack. This means it places itself between you and the WhatsApp server (or any other server). However WhatsApp encryption was explicitly designed with that attack in mind. The whitepaper discusses how sessions are set up and there is no way to successfully mount a man-in-the-middle attack. Also it is not possible for your provider to see to whom you are connecting.

So in general your provider will not see more data than it sees now.


How to create a secure embeddable HTML form?

There's no really good way to do this. The problem is less clickjacking - though that is a risk - and more that the user has no way to know whether the frame is genuine, or a phishing site. Anybody who wants to can put up an iframe that looks like yours, and just steals the user's credentials for your site if anybody thinks that this might be a real instance of your login page and enters them. To avoid that risk, you shouldn't ever lead your users to expect it's safe to enter their credentials on any third-party site!
The only way to get around that is to use a pop-up, a new window (tab, on modern browsers), or a top-level navigation (in all cases, to a login page on your domain). You'll notice that PayPal does this when signing in; they're not the only one.


Windows Server more vulnerable for password extraction during shutdown?

In most scenarios, no.

In the normal working fine scenario, the processes that could cause sensitive data leaks are ended before the general system processes, so there is no danger here.

In the case one such sensitive process is stuck, the OS does not end task the others before action is taken for the stuck one (in this case the well known screen with wait or end task appears).

In the case of operating system getting stuck, there can be indeed a problem depending how complete that halt is, but this should not happen on W2008, unless there's some bad hardware involved or really bad software installed (in which case the system is already compromised).


What exactly does certificate tranparency do?

Certificate Transparency solves a different problem from CRLs and OCSP.

OCSP and CRLs handle the problem of certificate revocation. The CA is offering resolution for mistakes and bad actions on the part of the CA's users. That is, the CA is assumed to be infinitely trustworthy, but a certificate may need to be revoked because of poor key management or some sort of mistake surrounding the certificate issuance. The infinitely-trusted CA then publishes a list of revoked certificates (the CRL) and uses OCSP to ensure that the clients get the message.

Certificate Transparency on the other hand addresses the fact that CAs are not, in fact, infinitely trustworthy. Misbehaving CAs have previously been able to exploit the fact that certificate signing is not a public event. A certificate may be properly signed but never seen by the public. If a malicious CA signs a certificate for use against a single victim, that victim may be the only client to ever see the certificate, making the malfeasance extremely difficult to detect.

Certificate Transparency moves certificate signing into the public view. Cooperating CAs immediately publish the details of every certificate they sign to one of several public logs maintained outside of the CA's control. If the client requires transparency from the CA in question, then the CA's certificates are not considered valid by the browser unless they were published to the public log. CT is relatively new, though, so enforcement is mostly nonexistent.


How can a debit card provide different answers when the same challenge is sent to it multiple times?

Most probably there is a counter involved (or even better, if either the card or the reader is equipped with an internal clock and battery, a timestamp).

The secret key involved here may be either a symmetric or an asymmetric one, I do not think this would change anything here (there is no requirement for the bank to not know this secret).

However, as you were wondering, using this secret key to directly encode the challenge would allow an attacker to either generate a pile of answers by advance, or note the answer of the challenge you got and try to replay it to get another payment asking the same challenge accepted.

The goal here is to ensure that, even with the same challenge, the correct answer must always be different. For this, you will add either a counter (the cheap solution) or a timestamp (the most reliable one as it allows the answer to expire) to the challenge before applying the secret key to generate the answer.

On the server side:

If a counter is used, it ensures that the answer you provides bears a counter strictly larger than the previous answer you provided, either for the same or a previous payment. If it happens that your answer seems valid but bears a smaller counter, this most likely mean that this answer has been replayed and that something fishy is currently going-on with your card (a few events like this and you may receive a notification from your bank, depending on their level of service).
If a timestamp is used, the server simply has to check that the answer has been generated after the challenge has been sent to ensure that there is no replay attempt.


The general consensus seemed to be that if you were to hook your computer (say a Windows desktop machine) directly to the internet with no router or firewall, that it would very quickly get compromised.

Modern Windows systems have a built-in firewall which severely restrict access, at least if the computer is declared as being in a public (and thus insecure) network. So it is actually not that bad as what you've read.
On the other hand most attacks today against users of desktop machines are not directly attacking the machine from the outside. Instead the user "invites" the attacker when reading mails or surfing the web, i.e. it explicitly downloads potentially malicious code to the computer in the form of mail attachments, alleged browser plugins, alleged software updates or similar. Basic firewalls like pfsense are not designed to protect such attacks at the application level, i.e. they provide none or only rudimentary protection.

Are firewalls based on linux secure?

Just using Linux does not make a firewall magically secure - but it also does not make it magically insecure. And FreeBSD is not Linux anyway (but also not implicitly secure or insecure).

... what makes it any more secure than a desktop machine plugged directly into a firewall? The firewall is loaded with software like VPN servers, DHCP servers, cert CA, DNS resolvers, firewall filtering, logging, admin interfaces (the web gui), and so on, so it's not like it is running a particularly lean configuration.

True. And especially if these services are facing the internet or are indirectly accessible from the internet (like with CSRF attacks) they can be a problem. Critical bugs in VPN stacks and WebGUI's of Firewalls actually happen.

In fact, I wonder if running a firewall like this simply increases the amount of attack vectors compared to something much simpler like the NAT on a basic router.

Just to protect a desktop computer, a firewall like pfsense if likely overkill on one side and not sufficient on the other. In such a scenario it will not add much value compared to some simple router, as long as this router is actually secure. And like you said it can actually increase the attack surface.
It is different though with more complex networks and/or with more need (and expertise) to monitor and control what happens. For example one might want to separate IoT devices from the rest of the network, have a network wide VPN, have a server accessible from outside but separated from the inside, have more visibility in the traffic etc.


Security headers in application vs. Tomcat default 40x error

What's on the error page? For Apache Tomcat, it typically contains the requested URL, type of the error message, a human readable description of the error and Tomcat version information.

The error page itself isn't really vulnerable to cross-origin resource sharing (CORS) attacks, and it's not running anything from the actual application.
The X-Content-Type-Options: nosniff prevents the browser from handling non-executable MIME types as executable MIME types. Doesn't really cause harm if a browser tries to execute the error page.


I have the ability to run arbitrary Python code on the 'apache' user. What damage can I do?

You could write some Python code to upload an SSH server binary and then run it, this will give you full SSH access under the privileges of the Apache user.

From there you can easily read the Python app's config files and connect to the database using the credentials from there, which will allow you to grab confidential data (no exploits needed here as the app has access to the database already).

Also, as @Aroth pointed out in the comments, you can also compromise other apps running under the same user account.

Finally you can take a look at what version the running kernel/libraries are and eventually use an exploit to gain root privileges.


After some clarification in the comment I guess I can see where we're heading. You need data integrity protection. Digitally sign the json data using a hash algorithm (md5, sha-1, etc) and put the sign inside the json file. Next you need some sort of mechanism identyfing whether the data was forged or not.


What to do if bug bounty program is unresponsive?

As many experts would agree, it is time you follow the (not so desireable) second-part of resposible disclosure: Give the security team a timeframe of 1-3 months, after wich you will disclose the vulnerability.
Responsible disclosure isn't only about communicating with the developer team to fix their security issues; It is about evaluating on your own just how much of an impact the vulnerability has, and how much time is reasonable to fix it. It would be unfair to the users to keep a critical vulnerability un-fixed and un-reported, given how much of an impact it would have if actively exploited. Sadly, sometimes the only way of making a company react, is by publishing your findings.
This was not legal advice; This was not advice; I am not responsible for the actions of those who read this.


Can sites which check your password as you type pose a security risk?

Modern cryptosystems are generally not susceptible to known-plaintext attacks.  In terms of encryption algorithms, there are basically 3 algorithms commonly in use in TLS:

AES
RC4
DES (in 3DES)

All 3 of these are believed to be resistant to known-plaintext attacks, and have been well studied for such attacks.

The one thing I would wonder about are side-channel attacks.  There's (potentially) several bits of information being leaked about your password, but the ones I can think of all require an attacker who is able to observe your traffic (of course, so would the known-plaintext attack you asked about).

If TLS compression is enabled (which it really shouldn't be, given the CRIME attack) and an attacker is able to correctly guess all of the other data sent in your request (which is not hard if there are no unique cookies) then it's possible they might be able to figure out your password by sending substrings and seeing which ones compress to the same length as your password.
Timing attacks.  Depending on how quickly the JavaScript sends requests to the server after you type keystrokes and your typing patterns, an attacker may be able to discern (or at least narrow down) what characters you're typing based on the intervals between packets (which indicates the intervals between keystrokes).  This attack was demonstrated against SSH by Song et. al. in 2001, so it's not exactly novel, just novel for HTTPS.  (HTTPS is generally not real-time, but what you're describing makes it approximately real-time.)
The length of the password. The attacker could measure the number of packages sent to the server and their sizes, and make a good guess about the length from the number of typed characters. Knowing the length of a password reduces the base by 1. So instead of having to guess 11^5 passwords, the attacker only has to guess 10^5 passwords for numeric passwords.

Overall, this isn't what I would worry about.  It's far more likely this website is vulnerable to XSS, SQL injection, session management vulnerabilities, etc., than it is that an attacker will use this back-and-forth technique to compromise your account.


Why Oauth2 specification considers native desktop application clients less secure than web server application clients?

If the explanation is that a desktop often runs games and other kinds of unsafe applications, then this is what I call a non serious explanation, because the client would just have to set up a secure desktop.

This may be true in theory, but security is a practical endeavour. Servers are generally better secured than desktops. In practice, expecting users to install a "secure desktop" in order to run a specific application is doomed to fail.

For the same reason, assuming that something is less secure because it's further away and you have less control is faulty. Do you apply this reasoning when deciding where to keep your highly valuable items? I bet you don't. I bet you trust bank vaults more than your cupboard at home, even when it means a loss of direct control.


Is there any risk in posting "local info" to the Internet?

When performing pen-tests, it's amazing how much information can be gathered by finding the StackExchange accounts of employees. Server naming patterns for example can be quite helpful, makes finding targets easier.

Test environments rarely are secured properly - or at least to the same level as production systems. If you can get into a test system, it's disturbingly common to be able to use that to then make it into production systems.

Any information leaked can help an attacker - even minor things can help an attacker gain a better understanding of the target environment.


Is it possible to restrict USB keys to only certified ones, and block that key's access on other computers

Almost, but not really.

Each USB device has a "Vendor ID" and a "Product ID", which the OS uses to determine which type of device it is. These IDs are officially registered and guaranteed unique. And you can set policies in Windows to restrict which device IDs are allowed to connect. Problem solved.

Except no. It's up to the device to correctly report its IDs. And it's possible (and in fact common) for malicious devices to impersonate legitimate devices in order to bypass this feature. There's even a pass-through USB device you can use to change the ID seen by Windows for any USB device specifically to thwart this feature.


Is it possible to verify the requesting user for a REST transaction secured by JWT at a later date?

You already have signed JWT token, if your HTTPd stores access log (and it have also cookies in that logs), yes you can find the identity later.

Be sure following items;

You will need the secret key of JWT (which that cookie have).
What is the algorithm of that signed JWT cookie
When you open that cookie, are you be able to identify the exact user or are you just able to see a GUID which will be stored at database and will be removed later ? For example some developers creates a session table and stores opened sessions on that table, jwt have that session identifier and as the last step with sign-out removes the row from table, if this is the condition JWT will not solve your problem. You need to be able to see a user identifier at your JWT data.

You can open JWT token and see what are you store on it, you can use this https://jwt.io/ website for it.

Notes of For access logging;

Access log only stores URL, HTTP Status Code, Method, Cookie, User-Agent and datas like that and does not store POST data this why if your endpoint understands the action over POST parameter. Access log will not identify action.
Nginx & Apache HTTP daemons have enabled access log configuration, IIS does not have enabled access log configuration at default, you need to configure it.
If you will use this data at SIEM, JWT token will be a problem, store your own log file for SIEM (if you are gonna use)


What protection measures are required in Android in-app billing for non-consumable products?

You are right, I do not see any problem in this scheme either. If Google starts lying to your server about fictive purchases I doubt a signature would help, as at that point you'd need to completely switch payment providers.


In message signing, is the digest encrypted with a generated symmetric key or with the sender's private key?

In message signing, there is no encryption. Otherwise we would call it encryption.

A signature algorithm is, nominally, the combination of three sub-algorithms:

Key pair generation: that algorithm produces a brand new public/private key pair, using some strong random source, and using as parameter a "security level" to achieve (i.e. the size of the key that is to be generated).
Signature generation: inputs are the message to be signed m and the private key. The output is the signature value s.
Signature verification: inputs are the message m, the signature s, and the public key. Output is a boolean value: "true" if the signature matches the message and the public key, "false" otherwise.

The signature generation and verification algorithms are supposed to be able to process messages of arbitrary length, possibly gigabytes. And they do. Existing signature algorithms are already very efficient at handling huge inputs. So there is no problem which would require some additional construction, contrary to asymmetric encryption where something else is needed to cope with the severe limitations of these algorithms.

Most texts that talk about hybrid encryption say that we need to do that because asymmetric encryption is slow, but that's wrong. The real reason why hybrid encryption is used is because known asymmetric encryption algorithms cannot simply process messages of arbitrary length, and we have no real idea about how we could alter them in order to do so securely. Basically, the "chaining modes" for block ciphers do not have equivalents for asymmetric encryption that would be obviously safe. However, signature algorithms never had a limitation on input length to begin with, so that is a non-issue.

It so happens, internally, that most signature algorithms are efficient at handling large inputs because their first step is to process the complete message through a cryptographic hash function, and then work only over the hash value. This is a design element of most signature algorithms and should be of no concern to outsiders who just use the algorithm. It does explain, though, why some people discussing about "RSA signatures" suddenly begin to talk about hash functions such as SHA-1: this is because the signature algorithm includes, as one of its building elements, a hash function. Note that some algorithms do not work exactly that way; it would be wrong to claim that all signature algorithms begin by simple hashing.

Ultimately this is a matter of terminology. In the case of asymmetric encryption, e.g. RSA, it is traditional to talk about "the encryption algorithm" as using only a short input; and any extra symmetric encryption layer is considered to be, indeed, some extra, outside layer. However, in the case of digital signatures, the same tradition holds that the initial hashing step is part of what we call the "signature algorithm".

There are some good reasons for this terminology choice; in particular, we want the hash function to be part of what we call the "signature algorithm" because using a signature algorithm like RSA or ECDSA without a hashing step (using a "short input" directly with no hashing) may induce severe weaknesses. However, at its core, it still is a terminology issue.


Can ISP's know the information you share with an https site?

I agree for the most part with @DNUCKLES, except that your ISP can probably determine what you are viewing. HTTPS does not really provide privacy.

For example, in this paper the researchers sniffed Netflix traffic and determined what movie was being watched, just by looking at the size and timing of the traffic. In this paper, researchers could see what you typed in a search box by sniffing HTTPS traffic. This paper identifies which pages you visit on a medical site with 89% accuracy.


Is Intel i3 CPU affected by the Intel ME vulnerability?

Let's go through all of this.

  But they are basically talking about the vulnerabilities of the vPro technology, specifically the AMT bug (sorry I can't link more here, search for CVE-2017-5689), where a lot of people have panicked to disable the AMT system due to the massive bug that has been discovered earlier this year

You likely don't have AMT as this is usually only available on Xeon architecture chips, but there have been reports that it might be exploitable on some desktop architectures too. Disabling it is possible, see this thread on Intel's forums for details. If your system doesn't offer this option in the UEFI/BIOS, you'll either need a custom one (see later in this answer) or you'll need to clean your IME firmware to remove the functionality entirely (also discussed later).

  Anti-Theft Technology, which can basically lock your computer, even via remote access (huge security vulnerability)

Sort of. You need to register your device with a provider (e.g. Intel, McAffee, or your organisation's administrators) in order to make it functional. At this point the provider can then lock the BIOS remotely if you report it stolen.  The thread linked above also explains how to turn this off, but the enable/disable toggle is easily found in most UEFI/BIOS menus.

  Execute Disable Bit, I am not sure what this does, but it sounds kind of invasive

Don't be scared by things you don't understand! Be curious. Execute Disable Bit is a really important security feature - it's the hardware feature that underpins No-Execute (NX), otherwise known as Data Execution Prevention (DEP) on Windows.

  Identity Protection Technology, sounds like a huge privacy invasion

Nope. IPT is designed for use in enterprise environments where you want hardware-supported 2FA or PKI integration. It doesn't do anything unless you configure and enrol it.

  Intel VT-x, which creates a subsystem that does have full privileges, but allegedly doesn't have access to the main system

I don't know where you've read this, but it's nonsense. VT-x is hardware virtualisation support. It includes special instructions which help speed up the process of virtualising a secondary operating system (a VM) on your host system. Software such as Hyper-V, VMWare, and VirtualBox use these extensions for performance and security improvements.

Disabling IME is probably a good idea in general if you value the openness of your hardware stack. Unfortunately you can't fully disable it at the moment. There are, however, efforts to help you heavily reduce the amount of code running under ME. The me_cleaner tool allows you to strip most sections of the firmware from the management engine without triggering a signature validation failure or 30 minute shutdown timer. A new trick released fairly recently (actually only a few days before writing this) allows you to disable ME very early and strip out even more code, using an undocumented feature called HAP. The me_cleaner developers are in the process of implementing support for this. Note that both of these tricks generally require hardware modification (reprogramming the 8-pin EEPROM IC which contains the firmware) and are entirely unsupported - you may brick your hardware, although you can always restore the original firmware using an EEPROM programmer.

You can also look into coreboot and libreboot if you want to replace your UEFI/BIOS with an open source option. Unfortunately these projects are generally limited to a small number of old laptops and motherboards.


how to capture and decrypt packets sent over TLS

Capture

--> Open Fiddler
--> Tools
--> Fiddler Options
Set the option boxes as shown in the image below:

Source: How do I use Fiddler to capture HTTP/HTTPS sessions for debugging?

Decrypt

If you haven't already, enable the Decrypt HTTPS traffic option, shown in the image above. You can read how to decrypt TLS traffic with Fiddler in the How come I can see full HTTPS requests via Fiddler? thread, which links to a set of instructions.


Storing the password database on offline server

No, it would not add anything other than security by obscurity which is not a great thing, it'll give you delusions of strong security.

Depending on what level of access the person gets to the network facing server, it's still trivial to get to the database. not to mention, what is probably the majority of the time, breaches happen by SQL injection which would still cause issues here as the network-facing server would just act as a proxy for the specially crafted user submitted data and the return from the server. if the attacker was to gain, for instance, shell access to the network-facing computer, they could just manually connect to the database server on the local network and wreak havoc.


Is flash less secure now that it is End of Life?

End of Life means that Adobe will no longer provide any updates to it. That means if anyone (had already) found a vulnerability today, Adobe would not patch it - regardless of how critical it would be.
How much of a problem is this in practice?
How lucrative of a target Flash is becoming depends on how many people still cling to it - despite being told with brightly flashing red warning labels that they shouldn't. After all, even to this day, there are people running on Windows XP. Flash is, from a security point of view, in a relatively good position (compared to Windows XP), as there has been plenty of time for developers to switch to alternative options, such as HTML 5. Furthermore, Flash is rarely used for enterprise applications, and as such companies have very little incentive to keep Flash alive - which in turn makes it a less lucrative target for attackers.
What are the actual real life risks of using Flash?
That depends on the vulnerabilities being found. The more time passes, the more severe the vulnerabilities will become. Since the end of life period has barely begun and news articles of "the big Flash vulnerability" haven't flooded in yet, I would cautiously rate it as "probably not extremely dangerous yet". However, regularly using Flash even after end of life is just asking for trouble - as such, every security expert will recommend you not to use it.
What about third party Flash players?
Flash content is provided through a number of file formats, which are more or less publicly documented. Even while Adobe's Flash player was still actively maintained, other third-party projects like Gnash were being developed, which sought to offer an open-source alternative to Adobe's proprietary software. In theory, it is possible to develop a feature-complete and secure flash player, but I doubt that this will ever happen.
The reason for this is the fact that Flash has lost all relevance. Nobody develops content for Flash anymore, outside from niche groups. As such, "keeping Flash alive" should be seen more as an archival project, similar to emulators for old video game consoles. After all, this too is history worth preserving.
Are third-party Flash players safe to use?
I don't know. Nobody can really know until these players have been audited to a satisfactory degree. If all you care about is occasionally playing your favourite old Flash games, then it will probably be fine to download the files and run them locally. If you aim to keep that one business application running that was developed in 1998 using Flash...then I would advise against that.


Someone I don't know is sending me test mail. Is this a scam?

Usually these are from email aggregators that are testing which emails send a soft/hard bounce response from the service provider. If the user doesn't exist, the service sends back a bounce email to let the sender know. Example: 'User something@somewhere.com doesn't exist.' For businesses this is usually for those annoying business marketing lists.

In general, it can be hard to predict the pattern of text they may use, but you can have your admin setup a bounce response for any email that has just 'test' or 'test email' for the body. It won't be perfect, but it will defeat the few that attempt this with a predictable pattern. Otherwise, just ignore it. If you have an email, you will have spam at some point.


Although "sniffing" can be just about anything to anyone, I usually consider the term to represent low-level information discovery -- usually at layer 2 to layer 4.  Your question, if I can interpret a little bit, appears to want to perform discovery at higher levels.  Such sniffing is absolutely possible, but requires more work to piece together the low level protocols to build a cohesive data stream.

The class of protection you are seeking is called "Data Loss Prevention" or DLP.  Such systems can be placed within the network or placed as agents on each individual machine.  They will continuously scan data at rest and data in motion at high levels of abstraction.

(The fact that you have a VPN is not entirely relevant to the rest of your question, I don't believe (unless you do not control the VPN server). A VPN protects the information across an untrusted network.  Perhaps this network is the public Internet, and perhaps it is a segment of an internal corporate network which processes sensitive information that needs to be separate and protected from other corporate networks.  At the end of the day, the VPN traffic/data will be decrypted by the VPN server to perform actual, useful work.  It is within that scope that you can embrace an in-network DLP solution -- or, you could deploy DLP agents on the individual machines -- or both.)


What are security issues which are specific to cloud computing?

There's an infinite amount of security issues with the cloud. To see a nasty laundry list, check out ENISA's documents.


Kali.download website blocked by Kaspersky because of Trojan, is it safe?

Kali has many tools that are legitimately malicious tools. So, it is not surprising that Anti-Virus would detect and block those tools.

Mimikatz (the thing you listed as being blocked) is a tool on Kali and is a very powerful malicious tool.

We cannot say whether that particular download location is safe. It seems to be a domain run by Cloudflare, but it is not TLS protected, which is strange. There is a TLS version of the URL, though (certificate from Cloudflare).

We also cannot say if turning off your Anti-Virus is a safe. But what it is detecting is expected and normal for what you are downloading.


Why can we trust a website with our data?

You can't trust that any data anywhere won't end up as tomorrow's news.

If you have data that absolutely can't be made public, don't store it on a computer.

For anything else, there's always a risk.

FWIW, I trust Google to "not get hacked"; however I assume that they're selling every byte of data that they can make a profit on. This is the price for free access to a level of technology that most of society couldn't afford if they had to pay for it.


Source code scanning - PCI Requirement - Service Provider

Scanning versus Manual Code Reviews

Custom built, in-house software is in-scope for PCI compliance if it deals with PAN data.  The PCI DSS, Requirement 6.6 expresses two options for in-house developers of software that handles PAN data: You can either do code reviews, or implement a web application firewall (WAF).  Of course, it specifies the nature of the options for code reviews or WAF and the minimum standards for compliance when using either option.

So, one can elect to utilize either the code review route, or do the web application firewall route in order to achieve compliance.

Code Reviews

The PCI DSS states that four options are available for compliant code reviews:

  Manual review of application source code
  Proper use of automated application source code analyzer (scanning) tools
  Manual web application security vulnerability assessment
  Proper use of automated web application security vulnerability assessment
  (scanning) tools

Therefore, a 'manual' review process (that you describe) is sufficient so long as that it covers the requirements mentioned further in the PCI DSS Section 6.6., notably that it is done by someone qualified and incorporated into the SDLC.

Of course, one may elect to use an automated tool as well; so long as that tool also works to satisfy the requirements.  Many organizations will choose to use a mixture of both automated and manual reviews, which will provide more real-world security than simply being good enough for compliance.

OWASP Top 10

The mention of OWASP Top 10 is geared towards the second option, Application Level Firewalls.  The PCI DSS states that as one of the requirements for a web application firewall to be considered compliant, it must:

  React appropriately (defined by active policy or rules) to threats against relevant
  vulnerabilities as identified, at a minimum, in the OWASP Top Ten and/or PCI
  DSS Requirement 6.5.

If you are doing the "Option 1" code review route, then you need not concern yourself with the WAF material to maintain compliance.

However, many organizations will choose to use both "Option 1" code reviews and implement a web application firewall, which will increase the organization's security considerably -- so the options are not mutually exclusive.  It's just that selection of one option is good enough, for now, to achieve compliance.

Compliant Doesn't Always Mean Secure

It is up to you to determine whether or not "compliant" is enough to be "secure" and what the risks of a breach are in your software, and as such, how much resources should be invested into securing it properly.


It is safe to store photos and documents on skydrive / google cloud services?

The most sensible approach is to assume you cant rely on their privacy - it isn't their responsibility, although there are some services whose selling point is securing this data.

If you take that stance, as long as you encrypt all data before it goes to the cloud you can be safe (decide on what level of encryption you need in order to be safe)

This approach gives you a very practical backup, just make sure you protect your encryption keys.


The TPM is used to seal the LUKS secret and nothing else. Once decrypted by the TPM (i.e. the proper environment has been loaded) the secret is stored in RAM hence it can be captured by coldboot attacks.

You can look at any documentation about Bitlocker with or without a PIN depending on your setup and the same will apply to tpm-luks, e.g. wikipedia.

The PIN will have an impact on whether the attack can be done: locally vs having to remove the memory dimm and, when the system was already turned off for a long time.

There's a few projects that store the secret elsewhere (e.g. TRESOR uses the CPU) and this is what you should be looking for if you really intend protecting yourself from those.


How does VTP authentication prevent unauthorized access (Can the password be cracked given captured packets)

For general understanding, VTP allows central management of VLAN domains, ID and other attributes. It governs how other switches learn and understand VLANs. Any updates related to VTP management are sent by the VTP server.

The risk lies when the MD5 hash is known either by compromising the switch and running commands such as show command, show vtp password or by looking at the vlan.dat file an attacker can force a digest change for the entire domain thus a new VTP server can be set up (a rogue) which will then allow  unauthorized access to previously blocked/disabled VLANs, allowing addition of new unauthorized switches in the network.

As with version 3.0 of VTP the two options: hidden and secret provide mitigation to the recovery process of a message digest. More info can be found here.

UPDATE based upon the excerpt taken from the article. MD5 hash is calculated and is only equal when the domains names are the same along with taking other VTP configurations into consideration. In the above link, the author has provided evidence of this via tests.


If the PRNG is cryptographically strong, then, by definition, its output cannot be distinguished from random bytes. That's the thought experiment by which a PRNG is supposed to be tested: two black boxes are given to the attacker, one implementing the PRNG, the other producing really random bytes (that one contains a gnome who throws dice real quick). The attacker goals is to find which box contains the PRNG, with a better success rate than pure luck (i.e. 50%).

PRNG which are NOT cryptographically strong, such as Mersenne Twister, can be recognized as such by an attacker targeting them specifically. But not necessarily by a generic statistical analysis tool.

To take an analogy, there are PRNG which are strong against armies of cryptographers who know the complete source code of the PRNG, and have access to a thousand big computers. There also are PRNG which can be declared non-random by a woodchuck wielding an abacus. And there are PRNG which are in between: generic simple tools won't catch them, but it does not mean that they can't be caught, only that it takes some more effort.

(Mathematically, it is not known whether cryptographically strong PRNG can really exist -- this is all the difference between an algorithm that cannot be broken, and an algorithm that we do not know how to break. A corollary is that we do not know whether there can exist an implementable analysis tool which would reliably recognize all non-strong PRNG. Right now, we have PRNG which are cryptographically weak, but statistically very good, so that analysis tools such as Burp's sequencer will find nothing non-random in them.)


You seem to specify a form that specifies an input named pass.

However, the HTML you linked to specifies an input named Password.

Secondly, it is may be good to try a less strict failure condition :F=Invalid instead of :F=Invalid input!, as sometimes encoding issues can cause a match to be missed.

In short, try:
hydra -l '' -P /root/Downloads/a url.com http-post-form "/admin.php:pass=^PASS^:F=Invalid input!" -t16

Also, it is not clear from your question if you have too many "greens", or all "greens"?

In short, try:

hydra -l '' -P /root/Downloads/a url.com http-post-form "/admin.php:Password=^PASS^:F=Invalid" -t16

Alternatively, start logging the requests and responses to see what is going on.


Say, you're user "bob". You log in with your password on 2014-07-30H12:00:00 and the server, using your scheme, sets your cookie token to:

enc("bob", K)+enc("2014-07-30H12:00:00", K)

However, bob is malicious. While his boss Alice is away from her desk, he checks her browser cookies and finds out her token:

enc("alice", K)+enc("2014-07-30H13:00:00", K)

Bob doesn't need to know the secret key K on the server, since the value of enc("alice", K) never changes, so all he needs to do in order to spoof being user "alice" at any time in the future is to change his own cookie to replace the output of enc("bob", K) with the output of enc("alice", K).

The scheme with the hmac suggested above is not vulnerable to this attack. The server's returned token is something like this:

bob$2014-07-30H12:00:00$b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c

Bob can try to change "bob" to "alice", but when the server performs the validation calculation, the calculated sha256 hash won't match, and it will be obvious that either the username or timestamp have been tampered with. Bob cannot possibly calculate the hash, since he doesn't know the secret key used by the server.

The validation operation of split() and hmac() are extremely fast and take microseconds to perform. They will probably be faster than decrypting the tokens. Obviously, you'd be sending the token over a safe channel, such as over https using a secure cookie, so there is little need to additionally encrypt the username and timestamp in addition to the hmac.

Edited to add:

Even if you use the following instead:

enc("bob"+"$"+"2014-07-30H12:00:00", K)

this is still not good enough. Getting encryption just right is extremely difficult and the chances are there will be weaknesses in your implementation (all tokens issued to "alice" will start the same way unless you do the right thing with randomness and initialization). Since the attacker will know both the plaintext and cryptotext, there is a number of attacks they can try to figure out what the value of K is, unless you use the right algorithm with correct initialization parameters.

Furthermore, all good crypto always incorporates hmac for integrity checking anyway, so by attempting to simplify the process you'll end up either weakening it, or making it more complicated and computationally intensive.

Just stick to the username+timestamp+hmac(sha256, username+timestamp, K) recommendation and transfer it to the client over a secure channel. It's a scheme that known to work well.


Definition
Rule based access means that your privileges are computed based on rules. The rules are logical formulas based on 1) user attributes like: job position, clearance level, job title, job description, geographical location and so on and/or 2) physical things like ip address you log on from, weekday, whether you're on vacation or not, ...
Example
You're a power user of software product ABC. The product uses rule based access. You have some strong privileges that allow you to do XYZ on objects which are assigned to the same geographical region that you work in. These privileges are only effective if:

your client IP is in some IP range (which excludes doing stuff from at home through VPN)
It is monday - friday between 8am and 6pm.

So the rule to be granted a certain privilege would be in this example

ip == 10.10.1.0/24 and workday <= friday and workday >= monday and timeofday <= 6pm and timeofday >= 8pm

and such a rule could also check things like job position, which is relatively straightforward if it is an alphanumeric code from the HR system which immediately identifies you as poweruser for that particular product.


Is there a way to report IP addresses scanning for Exploits?

The proper method is to contact the provider's abuse email which is almost never answered. You will waste an enormous amount of time trying to report addresses. Further, most machines scanning for exploits, are often compromised machines in their own respects. You can try going to an upstream provider, but I can assure you, said providers are often overwhelmed with so many requests, it will go unnoticed.


Does this CSS code expose if a message is read, and how long they have been reading it?

The email includes references to an externally-hosted images, like http://example.com/[tracking_id].png, where the tracking company controls the server hosting the image. The company records how and when each unique image URL is loaded by a mail client.

As you've noted, print operations can be logged by a tracking image in the @media print CSS directive. This assumes that the tracking image will not be loaded until the user actually prints the email.

Length of viewing time could theoretically be tracked by a slowly-loading image. The server would keep the HTTP response permanently unfinished, and it is only terminated when the user navigates away from the email. The server can log how long it took for the client to terminate the connection. However, I haven't observed this slow-load behavior in HTTP. It might be possible to do something similar with TCP sockets, which might be kept open even after the HTTP request completes (since the image is served with Connection: keep-alive), but my initial research suggests that the TCP connections may be kept alive after navigating away from a page that requested that keep-alive resource.

Excluding this possibility, it appears that the code you've included doesn't track time spent looking the email. Possibly time-tracking is a premium feature not enabled for this tracker.

The only other (mildly ridiculous) possibility I could consider is that the /F resource is somehow loaded when a navigation action is performed (i.e., the navigation action causes a manipulation to the document structure that causes the CSS rule to apply). If this (quite out-there) theory is the case, time-tracking will only work on Web-based mail, though.

Finally, they don't have ability to detect deletions. That article simply assumes that a user who has spent less that 2 seconds looking at an email has deleted it.


Good analogy needed: Sec issues due to different coders implementing the same features in different ways for the same app

Here's an idea for an analogy that I think is fairly accurate while generally understandable:

A bank requires two forms of ID to get a loan: a driver's license and a birth certificate.  Bank employees Alice and Bob are lazy in different ways: Alice always stamps "driver's license verified" without checking, while Bob always stamps "birth certificate verified" without checking.

Individually this is bad but not too bad -- anyone applying with forged documents would get caught by the one check the employee still does perform.  But one day Alice is running late, stamps "driver's license verified" on a form, and leaves it for Bob to finish up.  Bob sees the form, assumes Alice actually verified the license, and stamps "birth certificate verified" without checking like he always does.  The loan is approved, without either form of ID having been checked.


Rails - protection against code injection and XSS

Rails 3 has some pretty good protections switched on by default which will catch a lot of common security issues.

Specifically output encoding will help mitigate XSS attacks, the CSRF tokens are enabled by default on all forms which should help here, and as long as you use it correctly ActiveRecord or other ORMs can help with mitigating SQL injection.

On the input validation front there are obviously some things to watch for.  Rails won't do input validation for you by default, so if data entered into your app is transferred to other web applications, there's still the risk of XSS attacks occurring.

That said, Rails does support validations in the model, and I'd recommend doing white-list validation of input there, if possible.

On the SQL injection front, it's still possible to use raw SQL with ActiveRecord, and if you do that, then the usual problems with SQL injection can occur, so again white-list validation of all input is useful.

Beyond that there's several things still to watch for.  the base Rails installation doesn't provide authorisation/authentication, so that either has to come from a plugin or be written by the developer.

One downside to the RESTful style URLs that a rails app will typically produce is that it's usually easy for an attacker to try to break authorization by modifying the URL.  For example a URL of http://mysite/users/1 which shows the first user, could be easily modified to have a 2 or more.  It's not that it's less secure but it makes it easier for attackers to attempt to bypass authorization controls.

There's a couple of good information sources for Rails security that are well worth reading for more information.

The OWASP rails security guide is here and there's also a book Security on Rails from Pragmatic Programmers  which although it focuses on Rails 2.3 still has a lot of good information to consider (note that Security on Rails is now out of print).


Correct me if I am wrong, but it sounds like you are running an authoritative DNS server for your client's domain, and people will need to be able to query this server from the public Internet. For security, authoritative DNS servers at least have the following settings:

Queries for other domains should be ignored or refused
There should be rate limiting to limit the number of DNS requests per second from a single IP address, to prevent DNS amplification attacks.

A DNS amplification attack is essentially when an attacker leverages your DNS servers bandwidth to launch a denial-of-service attack on another target. DNS is normally a UDP protocol, meaning it is easy to spoof the source IP address. If an attacker wants to use your DNS server for an amplification attack, they would simply make tons of queries to your server while spoofing the IP address of their target. Your server would end up sending all of the DNS replies to the target, causing a denial-of-service. Limiting the rate at which a single IP address can send queries will mitigate most of these risks.

If I mis-read your post and you are NOT intending to run a DNS server accessible to the public Internet, then you should configure the server to only respond to queries from the specific IP addresses that need to query it.

Finally, you should keep whatever DNS server software you're running up to date. The most popular DNS server software, BIND, has historically had some major security bugs. Running an old version of BIND could open up some serious vulnerabilities on your server.


How does digital signature algorithms work in a private / public key environment?

In an asymmetric algorithm you have two keys. Lets call them A and B. Whatever you encrypt with A, you have to decrypt with B. Whatever you encrypt with B, you have to decrypt with A. (This is true for not all, but most asymmetric algorithms. Also, in practical implementations it is a bit more complicated, see techrafs comment.)

One of these keys are chosen to be private, and kept secret. The other is chosen to be public, and can be distributed.

When a message is signed, the digest is encrypted with the private key. Therefore it must be decrypted with the public key. The fact that it was encrypted with the private key proves the identity of the person who signs it - since only she should have the private key. The fact that it can be decrypted with the public key makes the signature useful, since anyone can verify it.

Note that our system where the MD5 hash of the private key is the public key would not work. How would you decrypt a message encrypted with the private key if you only have the MD5 hash of the private key? If you want to understand how it is actually done, have a look at RSA.


How much traffic can a firewall node handle? Any real examples?

Having done tests for multiple clients where they claim "scans won't knock this over, you'll be alright", then an hour later we're having a meeting discussing how they're going to handle a serious downtime incident, I can safely say a few things:

The marketing figures describing performance are at best a peak performance case, produced in a lab situation where the test case has been fully optimised for maximum performance stats with no regard for actual usability or functionality. At worst they're a complete fabrication or misrepresentation of the data. You should ignore any such performance statistics.
Standard flood tests (e.g. ICMP flood, SYN flood) are rudimentary tools at best. Resistance to ICMP flooding is rarely a useful measure of anything since people learned their lessons in the 90s. SYN flooding will tell you whether the system is capable of de-prioritising waiting half-open connections behind clients who have actually sent a final ACK to complete the connection, along with implementing a basic anti-flooding system like TCP SYN cookies. These are rudimentary things that you can expect from any networking product.
Bandwidth flood tests can be useful in working out network saturation issues, but they only really tell you what the network pipe's continuous bandwidth limit is. By flooding a network link with large packets (usually UDP datagrams) you can saturate the pipe and make it hard for new legitimate packets to come through. That said, that usually tells you more about the network itself than the device under test (the firewall or IDS).
IPS/IDS/Firewall systems have ludicrously fast throughput rate for traffic, but the real bottlenecks occur on the management side. For example, if you log every time a packet is seen from an IP address which does not have an ARP entry (I have seen this done) then sending lots of packets from a spoofed IP (or just without ARP'ing first) will very quickly fill the log buffer in memory and saturate the disk IO on the drive which stores the logs, usually knocking the whole system over. The device may be capable of passing legitimate traffic forward at a ridiculously high rate, but a single edge case like this can flatten it in minutes.
You can perform all the DoS / DDoS test suites you like, verify your results in production, open it up to real world traffic and see great results, then find that it falls flat on its face as soon as a pentester (or some skript kiddie) runs Nessus or sqlmap through it, because so many alerts are being thrown that the alerting system can't keep up.
If you test a device in a test environment, then move it to production, don't be surprised when your device no longer performs as expected. Tests have to be done in the real-world setup with the exact same config and same topology. Something subtly different can completely throw off your results.

If you want to properly test the realistic capabilities one of these devices, you need to install it in your production environment and run a full battery of tests through it, in your final production configuration. The results will be different for each model or version of the firewall/IDS/IPS, different config options, and different networking topologies and backend systems being reached through the device. Whatever answer you gain for, say, a pfSense firewall, will be entirely different than, say, a Checkpoint firewall.


Should users be able to update their avatar using URL instead of uploading a file?

Assuming the user is submitting a URL that is then stored on the server and put into the image link:

Its generally good practice for web sites to not give up personal info about their users (including IP addresses) which, if you put a URL to a server you control with an avatar that will only be used by that one site, an attacker could use to build a list of all the users' IP addresses and probably even cross reference it with when they are posting or show up as "online" to narrow down who is which IP.  While it is still possible to gather this (i.e. by posting a link to the same, that entices users to click on it) having it done automatically is bad form.  Users can't avoid giving away their IP to any other user when visiting the page.  I would strongly advise against this as a "feature".


Exploitation: EIP refuse to jump to the stack although it's executable

Based on the payload that you posted, It seems that you want EIP to jump to 0xffffd4d4. Set a breakpoint at that address (0xffffd4d4) before running the program. This way you will know if program execution ever reached 0xffffd4d4.

Maybe there is a problem in the Shellcode and your program might be segfaulting halfway through the shellcode. I had a lot of similar problems when I had started out.

PS. In your question you mentioned 0xd4d4ffff. Please check. Because if you want to jump to 0xd4d4ffff you need to replace EIP with \xff\xff\xd4\xd4 and not \xd4\xd4\xff\xff.


How can I demonstrate SSL/TLS to 10 year olds?

A lesson or activity on the topic 'HTTP vs HTTPS" for 10 years old is not a lesson about cryptography. It's about privacy and staying "safe" on the web.

The EFF has a good educational material about HTTPS and Tor that you can use as inspiration (Tor is out of scope, but the part about HTTPS is relevant). The point is to explain the threats and how using HTTPS mitigates them.

As a demo, you can set up a wifi network and a laptop with Firesheep or another tool that visually displays HTTP interceptions:

You can ask the kids to use their smartphones to browse websites in HTTP and compare with websites in HTTPS.

If you want to go into the details, you can tell that TLS guaranties the confidentiality, authenticity and integrity of the data coming from and to the websites. Explain those 3 words.

If you start talking about encryption keys or maths, you are going to far. But you may try to convince the teachers to do a second talk about the history of cryptography and cryptanalysis (it's usually a good way to introduce the topic).


No, but it will overwrite your hidden volume.

The hidden OS doesn't signal to the "primary" OS that there is any hidden volume. Instead it just looks like blank, free space available for the taking. A FAT filesystem won't use space at the end of the drive until it needs to, but if it gets to that, it will.

So you still have plausible deniability, but your encrypted volume is now completely overwritten.

Aw well.


Please keep in mind the Holy Trinity of Information Security: C(onfidentiality), I(ntegrity), and A(vailability). So when we talk about configuration hardening you need to consider the technology you're working with, the information being protected, how the information is used within the organization, and the threats. Based on those answers, and possibly others, you can begin to determine which of the tenants are most important and what to focus on.

At the filesystem level you're typically most interested in Integrity and Availability. The Confidentiality of the information should probably be handled at a different layer, but how you lay our your filesystems and how you use them should make sure that the information is both trustworthy and is always available when it's needed.

One thing to keep in mind when laying out your partitions are failure modes. Typically that question is of the form: "What happens when partition x fills up?"

What happens if your partition storing the OS is full? Strange things sometimes happen when / fills up. Sometimes the system hangs. Sometimes no new login sessions can occur. Sometimes the system refuses to boot.

Of all the failure modes this one is the hardest to strictly characterize as its symptoms are the most likely to change based on OS, kernel version, configuration, etc. Some filesystems, particularly the ext line, reserve a certain amount of space when the filesystem is created. This reseved space can only be used by the root user and is intended to allow the systems administrator to still operate and clean out space.

What happens if your partition storing logs is full? You lose auditing/reporting data and is sometimes used by attackers to hide their activity. In some cases your system will not authenticate new users if it can't record their login event.

What happens on an RPM based system when /var is full? The package manager will not install or update packages and, depending on your configuration, may fail silently.

Filling up a partition is easy, especially when a user is capable of writing to it. For fun, run this command and see how quickly you can make a pretty big file: cat /dev/zero > zerofile.

It goes beyond filling up partitions as well, when you place locations on different mount points you can also customize their mount options.

What happens when /dev/ is not mounted with noexec? Since /dev is typically assumed to be maintained by the OS and only contain devices it was frequently (and sometimes still is) used to hide malicious programs. Leaving off noexec allows you do launch binaries stored there.

For all these reasons, and more, many hardening guides will discuss partitioning as one of the first steps to be performed. In fact, if you are building a new server how to partition the disk is very nearly exactly the first thing you have to decide on, and often the most difficult to later change. There exists a group called the Center for Internet Security that produces gobs of easy to read configuration guides. You can likely find a guide for your specific Operating System and see any specifics they may say.

If we look at RedHat Enterprise Linux 6, the recommended partitioning scheme is this:

# Mount point           Mount options
/tmp                    nodev,nosuid,noexec
/var
/var/tmp                bind (/tmp)
/var/log
/var/log/audit
/home                   nodev
/dev/shm                nodev,nosuid,noexec

The principle behind all of these changes are to prevent them from impacting each other and/or to limit what can be done on a specific partition. Take the options for /tmp for example. What that says is that no device nodes can be created there, no programs can be executed from there, and the set-uid bit can't be set on anything. By its very nature, /tmp is almost always world writable and is often a special type of filesystem that only exists in memory. This means that an attacker could use it as an easy staging point to drop and execute malicious code, then crashing (or simply rebooting) the system will wipe clean all the evidence. Since the functionality of /tmp doesn't require any of that functionality, we can easily disable the features and prevent that situation.

The log storage places, /var/log and /var/log/audit are carved off to help buffer them from resource exhaustion. Additionally, auditd can perform some special things (typically in higher security environments) when its log storage begins to fill up. By placing it on its partition this resource detection performs better.

To be more verbose, and quote mount(8), this is exactly what the above used options are:

  noexec Do  not  allow  direct execution of any binaries on the mounted file system.  (Until recently it was possible to run binaries anyway using a command like /lib/ld*.so
             /mnt/binary. This trick fails since Linux 2.4.25 / 2.6.0.)

  nodev  Do not interpret character or block special devices on the file system.

  nosuid Do not allow set-user-identifier or set-group-identifier bits to take effect. (This seems safe, but is in fact rather unsafe if you have suidperl(1) installed.)

From a security perspective these are very good options to know since they'll allow you to put protections on the filesystem itself. In a highly secure environment you may even add the noexec option to /home. It'll make it harder for your standard user to write shell scripts for processing data, say analyzing log files, but it will also prevent them from executing a binary that will elevate privileges.

Also, keep in mind that the root user's default home directory is /root. This means it will be in the / filesystem, not in /home.

Exactly how much you give to each partition can vary greatly depending on the systems workload. A typical server that I've managed will rarely require person interaction and as such the /home partition doesn't need to be very big at all. The same applies to /var since it tends to store rather ephemeral data that gets created and deleted frequently. However, a web server typically uses /var/www as its playground, meaning that either that needs to be on a separate partition as well or /var/ needs to be made big.

In the past I have recommended the following as baselines.

# Mount Point       Min Size (MB)    Max Size (MB)
/                   4000             8000
/home               1000             4000
/tmp                1000             2000
/var                2000             4000
swap                1000             2000
/var/log/audit       250

These need to be reviewed and adjusted according to the system's purpose, and how your environment operates. I would also recommend using LVM and against allocating the entire disk. This will allow you to easily grow, or add, partitions if such things are required.


It's is perfectly normal for manufactured devices to be "rooted" or placed in a state that allows for escalated privileges.

Phone manufactures years ago used COM ports via Bluetooth to assist with installation. While some either forgot to disable or simply chose not to, this increased the attack surface, and allowed for BlueSnarfing/Bluejacking among other attacks.

The key part is the risk assessment:

What happens if a product leaves the factory with SSH still enabled?
Is it "Mission Critical" or "Life Critical", would someone die due to device tampering?
Is there a way to verify SSH is disabled/removed before shipping the product?
What are costs imposed in verifying that SSH access is removed?
Are you legally/morally/ethically required to check/disable/uninstall SSH access?
Would such a feature be useful in the field to technicians?
If you chose to keep it enabled, how do you ensure reasonable authentication/authorization?

Most building fire equipment is legally regulated, as it's deemed in many countries to be a "necessity to preserve life". Tampering with such devices is against the law, and depending on the legal requirements, you could also be held liable for negligence. You may wish to view any state/provincial/regional laws and federal mandates regarding automated fire equipment.

It is without a doubt an intelligent enough attacker could exploit the SSH access to tamper with the equipment. Depending on what is accessible from the remote SSH session, this could be quite serious.


snprintf (s.usr, 16, "%s", user); copies at most 15 bytes from user to s.usr, and appends a null byte. So printf (s.usr) only has a format string of 15 bytes at most.
Even if line 12 copied more, the subsequent scanf ("%s", s.buf); would overwrite at least byte 16. If you control the program's standard input, you can plant things on the stack, but they won't be part of the format string at line 26 since s.usr is guaranteed to be null-terminated. Of course, if you control the input, you can directly overwrite the stack through it as long as you don't need a null byte.
If you only control user, I'm pretty sure that's enough for an exploit. You could pad your shellcode so as to only have to write the higher bytes of the target address. Then you'd only need a single %c and a single %hn.


What does enabling kernel.unprivileged_userns_clone do?

Enabling unprivileged user namespaces can make severe vulnerabilities in the Linux kernel  much more easily exploitable. If you did not intend to enable it, you should ensure it is disabled. Numerous vulnerabilities that are found regularly are often only exploitable by unprivileged users if unprivileged user namespaces are supported and enabled by the kernel. Unless you truly need it, just disable it.
The reason for this is that much of the kernel that is only intended to be reachable by UID 0 is not audited particularly well, given that the code is typically considered to be trusted. That is, a bug that requires a UID of 0 is rarely considered a serious bug. Unfortunately, unprivileged user namespaces make it possible for unprivileged users to access this very same code and exploit security bugs.
From Brad Spengler in 10 Years of Linux Security, describing exploitation trends:

Attack surface exposed by unprivileged user namespaces isn’t decreasing anytime soon

Even more functionality being exposed:

2abe05234f2e l2tp: Allow management of tunnels and session in user namespace
4a92602aa1cd openvswitch: allow management from inside user namespaces
5617c6cd6f844 nl80211: Allow privileged operations from user namespaces

"Does this newly-allowed code pass existing fuzzing tests?" doesn’t appear to be a consideration for enabling such functionality

A few examples of vulnerabilities only exploitable on systems with unprivileged user namespaces:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-16120

https://brauner.github.io/2019/02/12/privileged-containers.html

https://www.halfdog.net/Security/2016/UserNamespaceOverlayfsXattrSetgidPrivilegeEscalation/

https://www.halfdog.net/Security/2015/UserNamespaceOverlayfsSetuidWriteExec/

https://googleprojectzero.blogspot.com/2017/05/exploiting-linux-kernel-via-packet.html

https://seclists.org/fulldisclosure/2016/Feb/123

https://seclists.org/oss-sec/2016/q4/607

https://www.openwall.com/lists/oss-security/2015/12/31/5

https://www.rapid7.com/db/modules/exploit/linux/local/nested_namespace_idmap_limit_priv_esc/

https://lwn.net/Articles/543539/

https://lwn.net/Articles/543442/

Note that this particular sysctl may get deprecated and possibly removed soon. This is because a little more attention is being spent on finding unprivileged user namespace bugs and the feature is not quite as horribly insecure as it once was. Unfortunately, it is still quite insecure (in part due to the lack of CVE reporting for security bugs in the Linux kernel). If that is the case for your particular distro, you can disable user namespaces directly by setting user.max_user_namespaces = 0.


I login to Stackoverflow (vulnerable) with Google (not vulnerable). Do I need to change my password?

Yes as your password which is supposed to be encrypted with SSL tsl is readable in plain text and if you use the same password for both web applications (you shouldn't be anyway) an attacker has access to both.. However if you use googles openID to log in it goes through googles servers and you would be secure


Send new password by email is bad practice but what to do if user forgot his password?

Check out the question/answers to the StackExchange question What type of Password Reset/Forgot Password (verification) mechanism would you recommend. It analyzes the two major methods: "Secret question" and "Reset email".

If you'd like to review an in-depth analysis of weaknesses to various methods/implementations (written by Ron "iagox86" Bowes):

Hacking Crappy Password Resets Part 1
Hacking Crappy Password Resets Part 2
(Mostly) Good Password resets

Now for an aside regarding password hashing. If you are able to send cleartext passwords, you are doing it wrong from the very start. And by this I mean you are storing cleartext without employing password hashing. Please read about why passwords should be hashed. There is no need to sit around thinking about whether or not it's appropriate to send user's their password: it should not be possible to do so.


Why is it dangerous for attackers to be able to enumerate all subdomains of a given domain?

This isn't about a specific attack. Before an attack, there is usually thorough information gathering about a target. This is where the insecurity exists.

Vulnerable systems on a network are vulnerable whether you have the domain or not. It's a matter of having a list of nodes with often times verbose naming conventions that give away more information then is needed.

It can provide information on network design, location of devices, types of devices, and much more. It doesn't need to be used in a cyber attack either, this type of information could prove valuable in a social engineering attack.

When this type of information used to be widely available, doing a host -l was a standard step in surveying a target. That has since changed and we shouldn't take steps backwards. There is no reason this information should be disclosed to the public internet.


Is CSRF protection required for sensitive GET requests with CORS enabled?

it seems protecting GET resources with CSRF tokens is useless.

It's not useless if you have state-changing GET request (which you shouldn't have, but it does happen).

  Do I need to implement some CSRF token protection for the endpoint?

No, requests which do not change state do not need CSRF protection (they may need proper authorization though).

  Could the user_data be read by a compromised client.com webpage (via persistent XSS)?

Yes, if you allow client.com to read data from server.com via CORS, then a compromised client.com can read that data as well.

  If so, can I use a query param mechanism of CSRF token exchange? The way I understand it, it's the only option, because the client.com cannot read csrf tokens stored in a server.com cookies.

No, CSRF protection wouldn't help. client.com can't read the cookie from server.com, but it can read anything on client.com. And you would need client.com to know the CSRF token to be able to send requests with it to server.com.

  how can I secure my application?

Do not let client.com be compromised. There's no other way to prevent client.com (compromised) from accessing data on server.com while also permitting client.com (not compromised) to access data on server.com because those two can't be distinguished.

  Make sure that the token is not leaked in the server logs, or in the URL.

You can send the token in a custom HTTP header to prevent this. But see above as to why it won't help if client.com is already compromised.


How can the geometry of a JPG 2000 image within a PDF execute code when opening it in Adobe Reader?

The exploit is simply titled based on what portion of the file must be mangled in order to cause a buffer overflow. If you read the SecurityFocus post, you'll see that it says:

  Attackers can exploit this issue to execute arbitrary code in the context of the user running the affected application. Failed exploit attempts will likely cause denial-of-service conditions.

In other words, an attacker would mangle (or replace the original value with an extremely large value) in order to cause a buffer overflow, and then cause a DoS (the advisory does not mention any scope for an attacker to execute code)


How to find external ip address a payload uses to connect back to the attacker?

You can create a wireless hotspot using your laptop, connect your phone on the wireless created by your laptop and then use wireshark to capture traffic from your phone to the internet. Then you will be able to see all the IPs your phone is connecting to.

Here's some useful links:

How to create a hotspot on linux
How to use wireshark