Reverse proxy sharing one certificate for multiple servers using Subject Alternative Name The following is a scenario for an attack where one website can impersonate another. I am told (including by this answer) that it's impossible, but I would like to understand exactly what prevents it.

Alice uses websites that fetch a trusted JS resource from Bob's server, using HTTPS to prevent MITM attacks. Bob's resource is popular, and he starts to use a CDN to distribute it. Now Alice's browser is making an HTTPS connection to a server belonging to the CDN.

The CDN uses Subject Alternative Names to share a certificate between multiple customers whose sites share an IP address on the CDN. Eve happens to own a site  which is on the same certificate as Bob's (1). Eve knows Alice's favourite coffee shop, and can intercept signals on the wifi there.

Since Eve doesn't have the certificate's private key, she can't read Alice's HTTPS traffic. Instead, she waits for a request for the resource on Bob's site (2), and replaces it with a request to her own site, via the same CDN IP address that proxies both sites. The CDN server decrypts the request, fetches a malicious resource from Eve's site, and encrypts that using the shared certificate. Alice's browser sees a valid response from the CDN IP that it sent the request to, and seemingly has no reason not to accept it. Note that Eve doesn't need to modify the response by MITMing - the CDN server sends back the malicious content from a server behind it.

Or is able to hack into one. One of them is bound to be insecure.
Is the URL encrypted in an HTTPS request? If so, assume Eve replaces all requests going to the relevant IP address and bets on detection being unlikely.

I'm not especially familiar with SSL, so I'm willing to believe that something in that doesn't hold, but I'm not sure what, exactly.

In such a case when multiple websites are served from the same server on the same port, that server differentiates between them by comparing the Host: header in the HTTP request.

Once TLS negotiation has occurred, it is not possible to read anything inside that request. You further cannot swap between two simultaneous SSL connections because a simple Diffie-Hellman key exchange produces a different key for each negotiation.

This is the crux of the issue: the Host: header is within the SSL encrypted transmission. Therefore, it is not possible to tamper with that header and not possible to redirect that request even to a different VirtualHost on the same machine.

Without the Private Key, there's not a lot you can do to break SSL.

EDIT: Yes. What you're suggesting would require some sort of tampering with the request. SSL basically consists of a TCP packet with an entirely garbled content, and what you want to do in this case is alter the garbled content to illicit a different response from the server. That isn't possible without breaking SSL. The only alteration you could make is to the TCP header to change the destination IP or port, but in your case that won't accomplish anything as you still intend to target the same service on that same server.

Clarification On SSL Negotation

The SSL negotiation uses a different key each time. Basically, the client generates a random number and encrypts that using the Public Key. This can only be decrypted with the Private Key. At this point, only the Client (who generated the key) and the server (who was able to decrypt that with its own private key) know this random number.

There is no way for an attacker to get that number. You could, theoretically, repeat that same encrypted secret to the server to open up a connection using that same key, however you still would not know the secret nor would you be able to alter any packets encrypted with it.

This would, however, allow you to use a replay attack (and repeat a request like "delete next item" again), so my guess is that there are other features within SSL to mitigate this risk.


non-periodic event detection I'm searching for keylogger detection. As far as I see, almost all of keyloggers created by tools are sending data to a host periodically, but the ones made by coders may send data non-periodically. Because it is easy to detect periodic events by listening traffic of a host, some professional hackers(code writers) does such a trick: create a random hour1 and min1 and after hour1:min1 send the first keystrokes data(or whatever it is sending to hacker). After sending first set of data, randomly create hour2 and min2 and after hour2:min2 send the next data and so on.

With this tecnic they are getting data non-periodically, but regularly. Is there any way/trick to find out that non-periodic but regular data upload?

Note: I'm not interested in Command and Control for now. I'm only interested in non-periodically data uploading keylogger detection? Ideas related to non-periodic and regular event detection would be appreciated.

Note2: Most of keyloggers are sending data over gmail or another mail server and some of them are using ftp server.

Note3: The detection is not going to be host based but network based detection.

Thanks,

Detecting a keylogger based on its periodicity seems like a strange way of doing it and using a random timer to thwart that detection seems strange as well.  If I was writing a keylogger, it seems more natural to implement something like once the logfile reaches a certain size (say 50 kB), start a new one and transfer the old file, versus sending on a fixed tmier.  There are plenty of data transfers that should occur at periodic intervals, so the mere fact that a transfer is periodic doesn't indicate much (e.g., backups to a local NAS, checking for updates, requests to fetch mail, etc.)

Really, the best way to detect is that unrequested network connections are being established by processes you are not using (e.g., in linux look at lsof -i -n or netstat -p -n -t) or haven't authorized.  You can also use a tool like nethogs which will actively collect statistics on how much network activity each process uses.


How to report getting an offer to put malware in my code I received an email with the following offer.

  Alina Schatalina  wrote: Would you consider adding our script inside your extension and get monthly payments for it? Our script will inject hidden and safe ads inside browser. These ads can't be noticed by user or Chrome Store. For current number of user we will pay you 300 USD each month, and you can still keep extension...

I can't find Google's email address for reporting this to Google.  Technically, it's not phishing, or Spam. And if I did that, presumably it would just load into the filters.  I think Google might like to investigate this person a bit more.

As a developer of extensions, under your developer console, you should be able to create a ticket in which an internal team might be able to further assist you or escalate this issue. I spoke with one of my coworkers about your question and that was his suggestion. Props goes to Brently for this suggestion. I hope this helps.


Kerberos Attacks Questions It's amazing how many "Attacks on Kerberos" articles exist out there and almost none really explains the small details.

My guess is that usually they assume it's basic knowledge and sometimes, they just don't know enough.

Anyway, here are the questions:

How is PtT (Pass the Ticket) possible? You can easily take someone's ticket but to use it you need to create an Authenticator, which means you need to get one of the keys that the client possess (it depends on which step you are in) and even forge the IP address embedded in the ticket stolen.
It does not sound reasonable to me that given access to client's computer memory, you would extract only Kerberos tickets and no session keys or clear text/hashed passwords.
If only Kerberos is used, where am I going to find any NTLM hash to commit OPtH (Over-Pass the Hash)?
The encryption of RC4_HMAC_MD4 is not used by default in nowadays windows operation systems, so how would I use NTLM hash in OPtH? Is downgrade the answer?
I read in some article, that kerberoast's brute-force phase is done by trying different NTLM hashes. It seemed weird, so I assumed that it is done by trying clear text passwords which will be used to generate NTLM hashes which will be used in their turn as keys in order to try decrypt the ticket's encryption. But that's not suppose to be the case, RC4_HMAC_MD4 is not used by default. AES does, and it has PBKDF2 as a hash algorithm (which suppose to be BF resistant).
How is Silver Ticket is done when the victim sever does check the PAC against the DC?
Golden Ticket attack builds on the TGS to cooperate with any given TGT? Which means that it will sign on the PAC even if its forged?

Thank you all.

I am no expert, this answer is based on my current knowledge of these attacks from practice environments.

  How is PtT (Pass the Ticket) possible? You can easily take someone's
  ticket but to use it you need to create an Authenticator, which means
  you need to get one of the keys that the client possess (it depends on
  which step you are in) and even forge the IP address embedded in the
  ticket stolen.

This type of attack you can perform when you gain the NTLM hash or the clear text password of a service account. You basically get a TGS from the Domain Controller, decrypt it using the service's NTLM hash (if you have the password you hash it), modify the group you belong to (modify the PAC) included in that TGS so you gain more privileges, then re-encrypt the ticket again and send it to the service. This ticket is also called a Silver ticket.

  It does not sound reasonable to me that given access to client's
  computer memory, you would extract only Kerberos tickets and no
  session keys or clear text/hashed passwords

Assuming you gained system privileges on that computer, you would want to get NTLM hashes or passwords to use in lateral movement to other accounts in the Active Directory environment you are attacking. I do not think you can do anything with tickets alone (but I am not sure on this one).

If you can't get hashes/passwords, then a possible thing to do is get a TGS for a service (or all the available services), download it to disk, then try to decrypt it to get the service's cleartext password from it (aka Kerberoasting).

  If only Kerberos is used, where am I going to find any NTLM hash to
  commit OPtH (Over-Pass the Hash)?

When either Kerberos authentication or NTLM is used, when a user is currently logged into a machine in the Active Directory environment you will find their NTLM hash cached in that machine.

  The encryption of RC4_HMAC_MD4 is not used by default in nowadays
  windows operation systems, so how would I use NTLM hash in OPtH? Is
  downgrade the answer?

I am not sure where the RC4_HMAC_MD4 is used (I think it used for encryption not authentication), but in overpass the hash you use the NTLM hash. If you are referring to the /rc4:<hash> option in mimikatz, then that takes the NTLM hash (I don't know why it is called rc4 though).

  I read in some article, that kerberoast's brute-force phase is done by
  trying different NTLM hashes. It seemed weird, so I assumed that it is
  done by trying clear text passwords which will be used to generate
  NTLM hashes which will be used in their turn as keys in order to try
  decrypt the ticket's encryption. But that's not suppose to be the
  case, RC4_HMAC_MD4 is not used by default. AES does, and it has PBKDF2
  as a hash algorithm (which suppose to be BF resistant).

Yes, in Kerberoasting you first hash a candidate to NTLM and then attempt to decrypt the ticket using the hash.

You can attempt to downgrade to RC4 when requesting the ticket to be able to find the cleartext password faster, but with AES it only becomes slower to decrypt hence find the clear text password,

Good article

  How is Silver Ticket is done when the victim sever does check the PAC
  against the DC?

From what I read here it should still be possible to perform silver ticket attack. Mainly it is because the PAC is not always checked against the DC.

There are ways to stop lateral movement using silver tickets, the one I know is configure administrator and service accounts to be "Sensitive and cannot be delegated".

  Golden Ticket attack builds on the TGS to cooperate with any given
  TGT? Which means that it will sign on the PAC even if its forged?

A Golden Ticket attack is forging a TGT, this is possible after obtaining the key to encrypt the TGTs which is only known to Key Distribution Centers (KDC) in the domain, the key is the password hash of a domain user account called krbtgt. To get this user's password, you need to compromise a domain controller to get that hash.

So when you are able to obtain a Golden Ticket, you basically compromised the whole AD domain.


Login system based on SOAP database I have recently been challenged with coming up with a Login framework which holds user data in a separate database which I connect via a SOAP connection. Now, I have done something along these lines before using only MySQL.

Now to come up with the login system, I store the user info returned in $_SESSION variables; They return the password in plaintext (along with some other information) - not sure why - however, I do not store that password in plaintext; rather I encrypt the password with an unique key for each user.

To check if the user is currently connected I use their sessions using 2 different parameters hashed together and compare to the logged_in__string which is done at log in; this is the basic setup:

$_SESSION['logged_in__string'] = hash ( 'sha512', 'USER_PASSWORD' . $_SERVER['HTTP_USER_AGENT'] );

After I create that, I encrypt the password using an unique key for each user; Then create a new function, check() which will decrypt the password, and create the hashed value compare it to the $_SESSION['logged_in__string'] and if equal then user is logged in.

My interest is in the $_SESSION variables. What are some potential risks in the approach I have taken, and if there are any, what are some good methods to secure these sessions for the user.

Hash your passwords
First of all, it sounds like the database stores password in plaintext. That is very, very, very bad. See this question for how to do it right.
The problem with your system
Now, to your actual question. The aim of your system is to stop session hijacking. However, it does nothing of the sort. If I steal one of your users session cookie and send it in a request to your server, how would you know it was stolen? All your system does is decrypt the password the real user provided at logg in and check that it is correct, which it always will be. Your system basically boils down to checking that password = password with some "magic crypto dust sprinkled on top" (to quote Androl Genhald).
To see this, write down your system in simplified pseudo code and then go through how the server would behave in case of an attack with pen and paper. I find that is a useful technique for problems like this.
A bit besides the point, but: Only using one round of SHA-256 is not enough for hashing passwords. And storing the encrypted data and the key at the same place is not a good idea.
The solution
Keep it simple:
$_SESSION['logged_in'] = true

Then, to protect against session hijacking, you can do the following:

Use good HTTPS.
Make sure your session IDs have sufficient entropy.
Mark the session cookie as secure and HTTP-only.
Watch out for XSS.

Your system also makes sure that the user agent stays constant during a session. This is only limited protection since the user agent can be easily spoofed, but it might help against an unsofisticated attacker. If you want to keep that check, simply store the original user agent in the session and then at every request check that the user agent header is the same as the one you have stored.


What is 'tabnabbing'? Wikipedia is not very explicit on this,

  The exploit employs scripts to rewrite a page of average interest with an impersonation of a well-known website, when left unattended for some time.

What is 'tabnabbing', how does one do it?

Tabnabbing is a phishing technique where a malicious web site changes its looks while the tab is inactive in order to trick the user into entering credentials.

This page is simultaneously a description and a demo. When you visit it, it shows a description of what tabnabbing is. When you then click another tab, it changes the tabs favicon and title to look like Gmail. Later, when the user wants to read her mail she goes to this tab thinking it is Gmail and enters her credentials.

Edit:

In this animation, you see that while I am reading SE, the tab that at first looked harmless changes in the background to look like Gmail. This way the page tries to trick me into submitting my credentials.


What tools to use when researching possibly illegal topics? I am a web developer who has an assignment to make a web shop for something that is in a bit of a legal grey area for my country but not in the country where the client resides. I was wondering what kind of precautions I should make when researching the topic.

Is a VPN enough or should I also setup a proxy? Do I need to use Tor browser or is that a bit much?

Tor browser is designed exactly for this purpose.

Unlike a VPN, which alone is really only useful for providing confidentiality and integrity between you and your ISP (e.g. when using hotel WiFi), Tor is designed explicitly with anonymity in mind. It is easy to use and free, and provides an extremely good level of anonymity, which is perfect for research of illegal or questionable material. Using it is most certainly not overkill. It is a good idea.

VPNs have a nasty history of recording browsing history even when they say they don't, and revealing the logs to law enforcement when they request it. Tor, which connects to a website over three random relays, is designed such that no individual relay is able to simultaneously know both who you are and what website you are visiting. This is what provides such a good level of anonymity.


Does Outlook store plain-text passwords? A long time ago when Microsoft changed my e-Mail from Hotmail to Outlook the password-interface said that I should only put in the first 16 chars of my password. But my password was longer before. So how could they find out the first 16 chars of my password? Was the password always truncated to 16 chars and then hashed and saved or has anyone another possible explanation for this?

See image below.

Well, we will probably never be completely sure as we don't have the code. But we can discuss some possibilities. But first,
Why the change, actually?
What could be a reason for this change anyway? A possibility is that intelligence agencies had something to do with this, like is assumed to have happened with an older version of A5/1, Comp128v2, where the first ten bits of a 'random' key were always set to 0. Like this they can, if they get the hash from MS, just brute-force faster.
In case you don't like complot theories, another option is of course that MS doesn't want you to forget your password.
But let's look at the possibilities.
Passwords stored in plaintext
It is possible that MS stored plaintext passwords, but it would be a huge failure and I suppose (and truly hope) this is not the case.
Normally passwords are hashed and salted in an irreversible way so that even MS can't get to know your password from the value in the database. So how did they do this?
Two versions of a hash function stored parallel
What would be a possibility is that they already planned for longer time to have a maximum length on the password. Then, they could wait for you to login and, parallel to checking if you're actually typing in the correct password and logging you in, cutting off your input and salting and hashing that and store it somewhere else. At the moment they changed to the new system, they just copied the new hashes.
The passwords were always 16-chars truncated
As pointed out by Ajedi32 in the comments, it's also a possibility the passwords were always truncated after 16 characters already. (The reason for this, again, could be interference by intelligence.) The only difference is that MS now doesn't allow you to enter more, because they've become too lazy to truncate it themselves.
This doesn't seem likely to me, because if this were true, then why would they now tell the users to not enter more than 16 characters? Yes, it could be that things like this (i.e. UI texts are changed without an actual change of the function) just happen in a huge organization. However, as Ajedi32 explains:

Maybe they finally realized that not telling users about such an important security limitation was a bad idea, and decided to start explicitly enforcing the 16-character limit? Or perhaps they're preparing to lift the limitation in the future, and they need to start preparing users for that now? (Because lifting the limitation would mean that "1234567890123456" would no longer be the same password as "1234567890123456789")

The actual answer
As it turns out, Ajedi32 was right and passwords were always truncated, as pointed out in this MS article (credits go to PwdRsch, see the comments). The other possibilities remain here for theory's sake.


Is it allowed to store billing address for merchants SAQ A merchants? (PCI DSS) I know there are many limitations for data storing and processing by PCI DSS. Some of them are explained here. https://www.pcisecuritystandards.org/pdfs/pci_fs_data_storage.pdf
But I can't find any info about storing customers' billing addresses. Is this means that PCI allows it for any merchants / service providers?

The PCI DSS concerns itself with the following pieces of data:

Except insofar as it might include Customer Name, billing address is not PCI protected data, and there are no PCI requirements around storage, encryption, or lack thereof.  Instead, that data is PII, and should be protected in line with whatever PII standards apply to your locality.


Key Extraction via electrical signal processing Looking for a link to what I believe was recent research that was similar to "RSA Key Extraction via Low-Bandwidth Acoustic Cryptanalysis" - but instead of being based on acoustic emanations, the research used electrical signal processing. Physical access to the system was required.

Get Your Hands Off My Laptop:
Physical Side-Channel Key-Extraction Attacks On PCs


Windows .NET equivalent to Linux /dev/random Is there a pseudo device-based random data stream/file that can be used in Windows .NET programming in the same way as /dev/random can be read and used as a source of random values on Linux based systems?

I’m not asking whether .NET can provide a pseudo-random number generator type random call such as CryptGenRandom() which appears to use a random seed to create a sequence of PRNG numbers but whether there is a functional equivalent as /dev/random which stores various system events and UI interaction to create a pool of random values that are considered to be crypto secure.

Because /dev/random appears to be similar to any other file on the underlying system, any Linux based programming language can access this truly random stream of data, but C# and other .NET programs don’t (normally) run on Linux systems, and mine certainly don’t.

All online searches and my reading always leads me to information about PRNG calls, which is not the same thing at all.

If there’s any answer to this on here already then I just need more practice on searching for answers I guess!

There is no built-in file-like interface to a source of randomness or entropy, if that is what you mean.

Unix-style operating systems such as Linux try to fit everything in a file, but Windows doesn't adhere to that approach and uses a function call instead.

This page has a random device driver to create a file like /dev/random on Windows. I don't know how well that works, and it uses RtlRandom and not CryptGenRandom.


How can I protect my computer from my potentially malicious colleagues? So, I work in this small company (10 people) where we do stuff in programming, for various platforms. I started recently working there (2 months) right after I graduated. My work is not exactly programming related, but I have enough knowledge to do some intermediate level programming like writing scripts in bash (I use Linux and Mac), writing simple programs and compile them and so on, but my comprehension of network and security topics is limited.

Some of my workmates, on the opposite, are more experienced programmers, computer science graduated, with deeper knowledge in network systems, web applications and programming. The work environment is very casual and friendly, we occasionaly meet after work to have a drink.

In the workplace, we all share the same LAN network, we recurrently use programs for remote desktop control and file transfer. We also host applications accessible via webservices. All our computers are login-protected and theoretically no one knows each other passwords.

Besides that, personally I use my computer for non-work related subjects: I access my personal email, chat with friends, access homebanking and social networks, edit personal documents which I save in the computer's hard drive.

Recently, I noticed that some of my colleagues sporadically arrive earlier at work (only one at a time) for no particular reason... As we work in small rooms, their excuse is that they can concentrate better earlier in the morning with less noise. Furthermore, I also noticed that some of them once in a blue moon bring their personal laptop to do some work related stuff. (I am not sure of the relevance of these behaviour to the question itself, I am just giving you the facts.)

This is very hard to put, but is there anyway that my colleagues can access my computer information and my personal files? Or is there some method they can use to discover my personal passwords?

I am speculating, of course, unfortunately I hope this doesn't happen, but I have no way of discovering it, and surely the right to question it.

As the above questions may seem too general, I will also leave this one for you:

Is there any way to find out if some one logged into my computer, by accessing some logs or any other info? I will take all your inputs, remember I use Linux and Mac.

Yes.  Your colleagues, if they really wanted, could probably access your computer, your personal files, your passwords, your banking account, etc.  That's just the way of it.

There are any number of ways they could do this, if they wanted to be dishonest and malicious.  One simple way would be to install a keylogger (or other spyware) on your machine at some point when no one else is around.  Another way would be to boot up your computer (possibly with a Linux LiveCD, to bypass any password protections) and look at all files stored on your computer, including passwords saved by your browser, etc.  Password protections on your accounts will basically keep honest people honest, but won't stop dishonest co-workers.

In general, it is hard to protect yourself against a knowledgeable attacker when the attacker has (1) physical access to your machine, and (2) authorized access to your local network.  You cannot prevent it.  And, you cannot reasonably detect it; there is no way you'd reasonably be able to reliably detect tampering by looking in the log files.  (I mean, it might be possible, but it's way too hard and complicated, and life is much too short.)

Generally, this is primarily a social problem, not a technical problem.  There are any number of ways that your co-workers or roommates could mess with you.  Fortunately, the overwhelming majority of people are generally honest (or at least, like to think of themselves as honest), especially if you avoid giving them an overwhelming motivation to screw with you.  So I would not spend too much time worrying about the technical issues.  Just avoid putting anything too sensitive on your work machine, and get on with your life.

In other words, here is my recommendation: Don't use your work machine for highly sensitive personal stuff like online banking, porn, or highly sensitive things you wouldn't want your employer to know (e.g., side consulting jobs, controversial activities in your free time, etc.).  Apart from the security risks, you are giving your employer authorized access to all of that information.  Do you really want your employer to have access?  And do you want all that information stored in the company's backups?  It's probably not a great idea.  And, don't piss off your co-workers so badly that they'd be tempted to engage in nasty kinds of revenge (always good advice, regardless of computer security issues).

Personally, I wouldn't worry too much about the computer security risks.  On the other hand, if this has you worried and you want to protect yourself against some kinds of mischief, here are a few modest steps you could consider taking:

install full-disk encryption, and use a hard-to-guess passphrase -- this will make it harder for someone who has physical access to your machine to get at your personal files.
when you leave your machine unattended, log out of the full-disk encryption, and re-type in your password when you come back
make sure the user account you usually use does not have administrator privileges
turn on automatic updates and make sure your browser is fully updated
back up your machine regularly
if you use Firefox, install the HTTPS Everywhere extension (unfortunately it isn't available for other browsers).

These are far, far, far from perfect, and if a co-worker wanted to mess with you, they probably still could.  But if it makes you feel more comfortable, go for it.


PCI Penetration Testing - Does the whole infrastructure need to be retested on significant change? The PCI SCC states the following in their penetration testing guidance:

  Per PCI DSS Requirements 11.3.1 and 11.3.2, penetration testing must
  be performed at least annually and after any significant change—for
  example, infrastructure or application upgrade or modification—or new
  system component installations. What is deemed “significant” is highly
  dependent an entity’s riskassessment process and on the configuration
  of a given environment. Because of this variability, a significant
  change is not prescribed by PCI DSS. If the change could impact the
  security of the network or allow access to cardholder data, it may be
  considered significant by the entity. Penetration testing of
  significant changes is performed to ensure that controls assumed to be
  in place are still working effectively after the upgrade or
  modification

Therefore it is up to individual organisations to define what constitutes a significant change in their documentation. However, as the penetration test should include security assessments on any in-scope applications present, an organisation may have specified that new features in these applications constitute a significant change.

If that is the case, is it allowable under PCI DSS to only "pen test" the changed applications, or does PCI dictate that the whole infrastructure be retested too, even though these individual servers may not have changed? Yes, in any ecosystem there's the law of unintended consequences, however if it can reasonably be implied that the changes won't affect anything else does testing have to be fully repeated?

Of course if it is allowable, this should be documented as such that this is the line that the organisation is taking. Also, as there is an annual penetration test of everything in-scope, this would cover any new vulnerabilities that may affect the rest of the network.

Short version:

PCI documents leave room to support either stance
Your QSA's approval or disapproval trumps anything you think the documents say (as always!)
In practice, I have seen QSAs accept limited-scope pentests when "significant changes" were limited in scope to the environment

Long version:

On the face of it, the wording of the DSS seems absolute; that a complete pentest is required annually and upon significant change:

  11.3 Implement a methodology for penetration testing that includes the following:

  ...

  Includes coverage for the entire CDE perimeter and critical systems
  Includes testing from both inside and outside the network

  ...

  11.3.1 Perform external penetration testing at least annually and after any significant infrastructure or application upgrade or
  modification...

  ...

  11.3.2 Perform internal penetration testing at least annually and after any significant infrastructure or application upgrade or
  modification...

However, when "significant change" is talked about, the 2015 Penetration Testing Guidelines are clear that this is an area where judgement is necessary:

  What is deemed “significant” is highly dependent an entity’s
  risk assessment process and on the configuration of a given
  environment. Because of this variability, a significant change is not
  prescribed by PCI DSS.

If you go back to the 2008 Penetration Testing Guidelines, the equivalent section seems even more receptive to the argument that not all pentest requirements are equal:

  Significance within a highly segmented network where cardholder data
  is clearly isolated from other data and functions is very different
  than significance in a flat network where every person and device can
  potentially access cardholder data. As a security best practice, all
  upgrades and modifications should be penetration-tested to ensure that
  controls assumed to be in place are still working effectively after
  the upgrade or modification.

I think that last sentence can be interpreted to mean that controls not assumed to be impacted by a "significant change" do not need to be retested along with that change.

One of the case studies in the 2015 Penetration Testing Guidelines also supports the idea that the scope of the assessment may vary based upon the judgement of what the subject (and their QSA) consider in scope for the penetration test:

  The web applications for Brand A and Brand B will be completely in
  scope. The web application for Brand C is presumed to be an exact
  copy, exclusive of product information and look and feel. The tester
  will sample the web application for Brand C to verify that the
  applications are the same as Brand B. If it is determined that there
  are material differences between Brand B and Brand C web applications,
  Brand C will be brought fully into scope.

And when it comes to retesting vulnerabilities that were identified in the penetration test, the 2015 Guidelines make it clear that some latitude in test surface is expected:

  The scope of a retest should consider whether any changes occurring as
  a result of remediation identified from the test are classified as
  significant. All changes should be retested; however, whether a
  complete system retest is necessary will be determined by the risk
  assessment of those changes.

So, while nothing explicitly says "You can reasonably limit 'significant change' penetration tests", it is in line with statements that recognize the variability of environments and risk profiles.  As with many things in the PCI DSS, if you can convince your QSA to agree that it is reasonable, then it is accepted.


SNORT rule for detecting/preventing unauthorized VPN or encrypted traffic Here's my not so theoretical scenario: A day-one Trojan horse attack where the attacker sets up a secure connection back to himself using a well known trusted port, such as 80 21 443. Or for instance, if a malicious user takes advantage of an open source tool such as openvpn to secure and route a connection out through a trusted port from within the company, effectively making all security mitigations useless.
Is there any way that snort could detect an initializing secure connection whether it be SSL/TLS or IPSEC? I realize that once the connection is established it becomes very difficult to find, that's my problem.
My main question: Is there any way to detect the exchange of public keys and log who's doing it?
Thanks in advanced!

In the case of TLS the answer is yes. (IPSEC?) The screenshot below shows a TLS exchange being caught by Wireshark. I don't know if Snort can do this directly.

DISCUSSION
I'll assume that you're within the same security boundary as the server. If you weren't, then simply tunnelling one protocol (eg. TLSxx on TCP) within another (eg. OpenVPN on UDP) will be enough to mask any connection establishment, such that you will be reliant on statistical analysis to try and determine what the specific network activity is.
Generally speaking, however, it really depends on the exploit.
If the attacker compromises a public-facing host, and manages to open a privileged port on this host, then you could capture this activity either on the host, or on the host's network, preferably both!
But what if the adversary modified (or worse: installed!) some upstream edge router to redirect packets to a different internal host, and then, instead of this new host listening for expected protocols (eg. HTTPS), the conditional host was now listening for some other protocol (eg. SSH)? I might configure HAProxy with a layer-4 reverse proxy that chooses between TLS, or SSH on a different internal host only when the client IP is specifically w.x.y.z or port 0FF0, etc.
Here's an example of configuring HAProxy to respond differently, depending on the protocol (HTTPS vs SSH) of the client Lim '16
Here's another interesting example showing discretionary back-ends depending on the contents of the TLS-SNI hostname Gornstein '17
HAProxy documenation on acl directives
(Yes, this example shows picking the SSH backend depending on the first 7 bytes, which your monitoring would also pick up on, but the protocol could just as easily be hand-rolled to use- or hardened with- a pre-shared key, eg. WireGuard or ZeroTier. In these cases the protocol is designed to mask the exchange of keys; IMHO the direction newer privacy-oriented protocols are trending toward.)
Now you might only see data flowing over the socket (encrypted, of course!) and never actually register any protocol. Any monitoring performed on host X will not even see the packets associated with the malicious activity. Monitoring on the network will see activity from host Y, but it might be mistaken for some other protocol.


Questions about "Triple Handshakes Considered Harmful Breaking and Fixing Authentication over TLS" Recently I'm reading the paper "Triple Handshakes Considered Harmful Breaking and Fixing Authentication over TLS", and I have several questions unclear.

First question: In TLS 1.2 standard, we can see: "Every connection is associated with one session", then does it mean each connection in TLS can only have one session? If so, As a new session, why renegotiation can in the same connection with the original handshake? In the standard, session resumption is used to quickly start new connections, however, can the resumed session be in the same connection with the original session and if so what is the purpose by doing this?

Second question: In the attack, why the resumed session should in another new connection rather than the same connection with the original session?
In the triple-handshake attack, the authors say: "attacks exploit a lack of cross-connection binding when TLS sessions are resumed on new connections." , and as RFC5746 says, the renegotiation would  only check the finished message in the enclosing handshake, thus, if both the resumed session  and the following renegotiation are in the same connection with the original handshake, the attack may still exist since the peers both agree on the finished messages in the  resumed session.  Is it right?

Meta: SE policy is generally against multiple questions in one post. But here your second question is a duplicate of Triple handshake attack against TLS which I already answered, leaving one open question.

The wording in the glossary of rfc 5246 (and its predecessors) may be a little lazy, because you are expected to pay attention to the whole document. The actual point is that a (TCP) connection is associated with one TLS session at a time. The time sequence is:

To start TLS/SSL, you make (or sometimes already have) a TCP connection and either do a full handshake to create a new session or do an abbreviated handshake to resume an existing session (if there is one available). After that initial negotiation, all the data transmitted and received is encrypted (unless eNULL) and authenticated using keys derived from the master_secret for that session (plus current nonces), and should be treated by both sides as having the security (and other) parameters of that session: master_secret, algorithms, server authentication usually, client authentication if used, and TLS-level compression if used, which was never very popular and after CRIME is often prohibited completely.
Any later time during the same connection, if both endpoints agree, you can do another handshake called renegotiation on the same connection. This renegotiation again can be a full handshake that creates a new session or an abbreviated handshake that resumes an existing session. In the resumption case it may resume the same session that was in use before the renegotiation, or it may be a different saved session. Once the renegotiation is done, subsequent data uses the keys and parameters of the session selected by the renegotiation, usually though not necessarily different from the session from the initial handshake.
At a still later time you could do a second renegotiation, again with the same features. After that, data uses the keys and parameters of the session selected by the second renegotiation, probably different from the session(s) from the first renegotiation and the initial handshake.
Et cetera, et cetera, et cetera.

After terminating one connection, you can make another connection that again can either create a new session or resume an existing one, if it is available; often endpoints drop a session after a time limit like 5 minutes or 1 hour, or if they run out of space, or have an error. And again, and again. You can also make several connections concurrently, each of which can either create a new session or resume an existing one. And after terminating them, you can make more, ditto.

Nowadays renegotiation is usually done when one party, usually the server, wants to change the security parameters, such as to do client authentication which was not done on the initial handshake (or prior renegotiation). In order to change security parameters, the renegotiation must be a full handshake.

But the protocol allows the renegotiation to be an abbreviated handshake that resumes a session. The only obvious valid reason for this is if you have encrypted enough data under one working key set that you want to generate new working keys, traditionally called rekey[ing]. With CBC mode it's best practice not to exceed the "birthday bound" of sqrt(2^blocksize) blocks under one key, and for 3DES (and DES in the years before it was obsoleted) this is 2^35 octets or 512GiB. With modern networks under sustained load you might reach this volume, and want to rekey, in about an hour or maybe less, and even under lesser load this could easily occur in days or weeks.


What’s wrong with in-browser cryptography in 2017? There are many articles in the internet criticising JavaScript cryptography in the browser:

"What’s wrong with in-browser cryptography?" by Tony Arcieri
"Final post on Javascript crypto" on rdist
"Javascript Cryptography Considered Harmful" on NCC  Group

They raise some fair points, but I'll like to analyse them from a 2017 perspective and know your opinions. To do so, I'll define a possible architecture for a encrypted notes site so you can raise possible problems and solutions about the security aspect:

Of course, we will be using SSL.
The first time a user logins in our notes app, we send them our public key. This key will be used to verify the authenticity of our crypto.js script. The public key will be stored in the user's browser.
A checker.js script is downloaded and stored as well. This script will never change and it will be in charge of checking the integrity of crypto.js and (2).
In (2) and (3) we establish a Trust On First Use (TOFU) relationship between the user and our site.
Both the public key and checker.js are cached using a service worker or similar. We will be using SRI as well to try to maximise integrity.
Even though we are using SSL, a MITM attack could happen while downloading (2) and (3), so we could offer a way to check that the public key and checker.js are not compromised. For example by comparing hashes of the local copy of (2) and (3) with the real ones in our site or a third party site.
This solution is not perfect and this is probably the weak link, but I believe that a similar attack could be performed on desktop apps.
On first login, we also send to the user its private key.
This private key will be used to encrypt and sign the notes.
This private key will be encrypted.
The key required to decrypt (6) is sent via email to the user.
In this way we establish a two-channel authentication.
Using Web Crypto we decrypt (6) with (7).
In this way (6) is never stored in the browser decrypted and it is not accessible by JavaScript thanks to the Web Crypto API.
Now we can start with the functionality of our web app: create encrypted notes. To do so, the user writes a note and click the save button.
The server sends crypto.js signed with the server's private key (see 2).
The signature is verified using the public key downloaded in (2) with (3) and if correct, the note is encrypted.
If checker.js was modified, SRI should stop this process.
The note is sent back to the server and stored.
Depending on the functionality required, the server should delete the user's private key and keep only the public one or not.

What do you think about this setup?

I am not happy about (5), but this is something that can happen with native software.
It is not the first time we see installers compromised.
Also a MITM while downloading the installer can happen.
And native code signing is not perfect.

Do you think that web crypto is still strictly worse than native crypto?

Any suggestions that could improve browser cryptography?

The main issue with cryptography in web pages is that, because the code you're executing is loaded from a web server, that server has full control over what that code is and can change it every time you refresh the page. Unless you manually inspect the code you're running every time you load a new page on that site (preferably before that code is actually executed), you have no way of knowing what that code will actually do.

The Web Cryptography API can mitigate the risks of this somewhat by securely storing cryptographic keys in a way that scripts running on the page can not access, but all the operations that can be performed with those keys (decrypting, signing, etc) will still be available to those (potentially malicious) scripts.

As long as you do trust the server not to behave maliciously cryptography in the browser can be quite useful, but in many applications where cryptography is used that level of trust in a remote server you do not control is unacceptable.

For your scheme in particular:

  Of course, we will be using SSL

This is good. Without SSL, all later security measures would be pointless because an attacker could simply replace your code with their own and do whatever they want with the user's data.

  The first time a user logins in our notes app, we send them our public key. This key will be used to verify the authenticity of our "crypto.js" script. The public key will be stored in the user's browser.

This seems pointless. TLS already sends the client your server's public key and uses it to verify the authenticity of all scripts you load over that connection. There's no reason to do the same thing all over again in JavaScript.

  A "checker.js" script is downloaded and stored as well. This script will never change and it will be in charge of checking the integrity of "crypto.js" and (2).

This is also pointless, because there's no way to enforce your requirement that "This script will never change". You could send a Cache-Control header with a long max-age, but there's no guarantee the user agent will always respect that value; caching is not intended to be relied upon for security.

  In (2) and (3) we establish a Trust On First Use (TOFU) relationship between the user and our site. Both the public key and "checker.js" are cached using a service worker or similar.

Just to be clear: caching those files with service workers has no impact on the security of the overall system. When the user later comes back to your site the browser will check with the server to see whether the service worker has updated and install the new version if it has. So the server still has full control of the code running in the user's browser. There's no "Trust On First Use (TOFU) relationship" here.

  Even though we are using SSL, a MITM attack could happen while downloading (2) and (3), so we could offer a way to check that the public key and "checker.js" are not compromised.

That's a nice gesture, but as I previously stated even if those files are not currently compromised, the server or a MITM (who somehow managed to compromise your TLS connection) can easily update those files at any time to compromise them without the user noticing, so I don't really see the point of this feature.

  On first login, we also send to the user its private key. This private key will be used to encrypt and sign the notes. This private key will be encrypted.
  The key required to decrypt (6) is sent via email to the user. In this way we establish a two-channel authentication.
  Using Web Crypto ( https://www.w3.org/TR/WebCryptoAPI/ ) we decrypt (6) with (7). In this way (6) is never stored in the browser decrypted and it is not accessible by JavaScript thanks to the Web Crypto API.

Implementing this would require that the server have access to a plaintext version of the user's private key. Depending on exactly what you're using these keys for, that could be problematic if the server is ever compromised. Instead, you should consider using the Web Crypto API to generate a private-public key pair on the user's device, and have the browser send the public portion of that key to the server. That way the server never has access to the user's private key.

  Now we can start with the functionality of our web app: create encrypted notes. To do so, the user writes a note and click the save button. The server sends "crypto.js" signed with the server's private key (see 2).
  The signature is verified using the public key downloaded in (2) with (3) and if correct, the note is encrypted. If "checker.js" was modified, SRI should stop this process.

Unless you're loading checker.js from an untrusted third-party server, Subresource Integrity is unnecessary in this scenario. Anyone who can compromise your server or its connection to the client to modify checker.js can also modify the values of the subresource integrity hashes so that the browser will accept the modified script without complaint. Or they could just modify the page to not load checker.js at all, and use a completely different script of their own making instead. Either way, subresource integrity doesn't help.

  The note is sent back to the server and stored.

That's fine as long as you fix the issue I already mentioned with 6, 7, and 8 so the server doesn't have the keys needed to decrypt the user's files. If you're fine with the server having the keys to access the user's files, there's no need for client-side crypto at all; just let the server handle the encryption.

  Depending on the functionality required, the server should delete the user's private key and keep only the public one or not.

Or, as I suggested, just don't give the server the user's key in the first place. Other than that though, this part is fine security-wise, in that it prevents the server from accessing the user's files while the user is not using the site.

Once the user visits the site though, the user's browser will load code from that server which will have the ability to use the user's keys to decrypt the user's notes. So for the average user, accessing their notes without giving your server the ability to read them is impossible.

There are also some usability issues with this implementation, as it means users will not be able to sign into their account from a new browser and still have access to their notes. A better implementation would be to derive users' crypto keys from their passwords using a key derivation algorithm like PBKDF2 (available via the Web Cryptography API) with a high work factor. This would allow them to access their notes from any browser. (But would still have all the same security downsides mentioned in my comments above.)


Why don't folks seem to use ECC for TLS root certificate signature? I looked around, and all I see is websites using RSA2048 for Root signature, and a few using ECC for encryption.

Are there any reasons folks don't seem to use ECC for TLS root signature?

Are there any drawbacks to using ECC for X.509? - if indeed it's possible?

There's a slide deck on NIST by Rick Andrews, Senior Technical Director and Distinguished Engineer of Symantec, titled Symantec’s View of the
Current State of ECDSA on the Web (published 2015) providing great insight:

  What is holding back the market for ECDSA certs?

  Legal/IP concerns were not allayed by the 2003 NSA-Certicom license
  Distrust in Suite B curve choices after Snowden, especially in Europe
  Lack of client support (Windows XP and non-traditional devices like smart TVs
  and Japanese feature phones)
  RSA isn’t broken; risk of trying new algorithm; general lack of awareness
  Lack of dual-stack support in web servers (except Apache – see
  http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#comment_970)
  Clients supporting ECDHE may not have ECDSA root; difficult for servers to know
  ECDSA root may not be EV-enabled
  Client-side performance penalty (ECDSA slower than RSA for signature
  verification for commonly-used key sizes)
  "Heard there was some technical problem with ECDSA" – (if a cryptographically
  secure random integer is not selected, the private key can be determined)

  Impact of New Curves

  Impact will likely be muted if IP issues are not cleared up
  CAs need support in their HSMs and software toolkits
  CAs will most likely sign keys from new curves using existing P256 or P-384 roots, to avoid delay of deploying roots using new
  curves
  Signing with existing RSA roots or intermediates carries IP risk, but
  mitigates root ubiquity issue
  Even though CAs may not initially create intermediate CA certs
  with new curves, we need to perform Proof of Possession of key.
  Usually done by checking signature on CSR, requiring support of
  new key curve in the CA’s HSMs and software toolkits.
  Browser and web server vendors must support new curves


Can you tell OpenSSH to force a rekey according to a packet number limit? OpenSSH has a parameter in the config files (ssh_config and sshd_config) for both client and server called RekeyLimit.

The default values for it are:

RekeyLimit 1G 1h

Which will force a rekey after 1Gbyte of data has been sent using the current key of after 1h has passed since the last key was generated.

But rfc4344 make some recommendations about rekeying which refer to number of packets:

   Because of possible information leakage through the MAC tag, SSH
   implementations SHOULD rekey at least once every 2**32 outgoing
   packets.  More explicitly, after a key exchange, an SSH
   implementation SHOULD NOT send more than 2**32 packets before
   rekeying again.

Is it possible to tell OpenSSH to force a rekey according to number of packets instead of number of bytes?

Your answer is partially addressed in the SSH man page:

 RekeyLimit
     Specifies the maximum amount of data that may be transmitted
     before the session key is renegotiated, optionally followed a
     maximum amount of time that may pass before the session key is
     renegotiated.  The first argument is specified in bytes and may
     have a suffix of `K', `M', or `G' to indicate Kilobytes,
     Megabytes, or Gigabytes, respectively.  The default is between
     `1G' and `4G', depending on the cipher.  The optional second
     value is specified in seconds and may use any of the units docu-
     mented in the TIME FORMATS section.  The default value for
     RekeyLimit is ``default none'', which means that rekeying is per-
     formed after the cipher's default amount of data has been sent or
     received and no time based rekeying is done.

A default is already set to 1Gig and 4Gigs of data but what does that mean? If you're sending small packets, it would take a long time to rekey, if you're sending large packets, the re-keying would occur more frequently. So let me ask: "What do you think your goal is in setting this to packet amounts would accomplish?"

Rekeying was done so that no one could store/obtain/sniff chunks of data for cryptanalysis attacks. (And or side channel attacks). There is a cost to performing these types of attacks: Storage, time, knowledge of encryption/cryptanalysis. Outside of nation state sponsored programs to attack this, I have yet to see, read, or hear about a non state actor even attempting to pull this off. There are other ways to attack a system.

But to answer your question, there is no definitive method listed to do this (packet based rekeying) so you have an option: Baseline your traffic, divide total data sent, by packets sent, then use that as your rekey number. E.g. 1Gig of traffic / 1000 packets(average amount of packets it took to send 1Gig) = Rekey number.


How can I search for registered domains, but not unregistered domains? There are many many services available to "search for domain names", but every one I have found returns results for unregistered domains; whereas I would like to a wildcard search for registered domains.

The purpose of my quest is to identify typosquatting and fake domains, e.g. if my company is example.com then I would like to be able to find exrample.com, exampl.e.com, example.ru etc.

Is there such a service, without enumerating all possibilities and using DNS resolution directly?

TLDR where can I find a list of all registered domain names?

You can also search through http://www.namedroppers.com/. I had not personally used this before but a quick test showed that it does find adjacent domains fairly well. It looks like the online search is free but you have to pay to download the list.

Disclaimer: I am not affiliated with http://www.namedroppers.com/ nor do I endorse their service.


Client Authentication Certificate Not Expiring, but "parent" cert IS So I have a client-authencation cert installed on client PCs, which doesn't expire for 5 more years.  Unfortunately, the cert on our gateway which is used to validate the client cert, expires this month.
I know.... D'Oh!

Plan A is to place a new cert on our gateway, and issue new client-auth certs to all of the clients.  This is going to be very disruptive.

It seems like it would be simpler to place a new cert on our gateway, and have it continue to validate the client certs until the client certs actually expire in 2019.  This would be my proposed "Plan B".

Is Plan B valid?  i.e. can you have a new cert on the gateway, honoring existing certs, or do you have to re-generate everything "top-down"?  I guess I'm asking if you can replace a link in the trust chain, without breaking the chain.

I'm sorry that this is over-simplified.  I don't really understand all of this, but am struggling to find a loophole here that we can leverage.

These certs are generated internally (our own CA) and are not used for SSL. Only client-auth, attached to SOAP messages, within SSL (SSL isn't expected to change).

Thanks,
Chris

You can "regenerate" the certificate on your gateway, but it will work only if you take care to reuse the same name and key.

This is a certificate chain: the certificate on the gateway is the "CA certificate" and the clients have been issued certificates by that CA. Such a client certificate will be deemed valid (aka "acceptable") if whoever does the verification can build a valid chain. Conditions are listed here (don't go read that, it will destroy your sanity); they mostly boil down to:

The subjectDN of the issuer must match the issuerDN of the issued certificate.
The current date must lie between the notBefore and notAfter date of each certificate.
The signature on the issued certificate must be successfully verified with regards to the public key in the issuer certificate.

The consequence is that if you produce a new CA certificate (for your "gateway") with a longer validity range, and take care to use the exact same name and the exact same public key, then the new certificate will work as a replacement for the old one.

A further complication is that whoever will have to validate the client certificate will need to access the new CA certificate instead of the old one. Possibly, the client may send it along as part of the protocol (this happens in some protocols, e.g. SSL: when the client sends its certificate, it actually sends a complete chain), but this will require client systems to know it. Any certificate may contain a link (URL) to a place from which the issuing CA certificate may be downloaded (it is called Authority Information Access); if that is the case, then you will want to put your new CA certificate at that exact place, replacing the old one.

Summary: your "Plan B" may work, but only if you reuse the same name and key in the new certificate, and it may depend on the exact usage scenario. Your CA software may be troublesome if it insists on generating a new key pair.

Note: some CA avoid this situation by enforcing nesting of validity dates: if a CA's certificate ends on December 13th, 2014, then it will refuse to issue certificates with a notAfter date beyond December 13th, 2014. Microsoft's CA (Active Directory Certificate Services) is of that kind. I take it that your CA software does not apply that rule.


Are there any risks associated with SSH agent forwarding? I just realized that I need SSH agent forwarding in order to push to one Git server that then forwards the commits to Github.com. I never used SSH agent forwarding and don't understand the security implications of enabling this feature. Do I have to trust the remote server in order to allow SSH agent forwarding to it?

Yes, you have to trust the remote server if you allow agent forwarding for this server (especially if you use the same key for more services). Doing so rogue root or evil admin with root access can impersonate you for authentication to other servers during the time you are connected to that server.

The state is still better than accessing the key permanently or stealing it from you, what could happen when you would copy your private key to the server, but this is still an issue, since there is no confirmation on your side, that you really want to do crypto with your key in agent.

Using separate key for github is probably good idea. And having middle-step-clone of your important repository on a server you don't trust is probably something you also don't want.


PEM, CER, CRT, P12 - what is it all about? I hope my question is not too general, but I find the topic of storing asymmetric keys very confusing..

Here's how I understand it:
Using openSSL I can generate my RSA keys pair:

openssl genrsa -out private.pem gives me a PEM file which includes only private key
openssl rsa -in private.pem -outform PEM -pubout -out public.pem gives me a PEM file which contains a public key

So, after executing these 2 commands I have my RS-256 keys pair (is it the correct name? Keys are 2048bits as far as I know, so why RS-256, not RS-2048?).

Can I consider the 2 files that I have (private.PEM + public.PEM) a certificate already?
What is the content of CER, CRT or P12 files? I can't find any real
examples of these files.
How to generate CER, CRT or P12 from my 2 PEM files that I have?
I saw some information that P12 file can be protected by a password - what is the reason to protect this file with a password - that password again has to be stored somewhere, already we store P12 file in a secure place where no one should have access to, right?
I saw some example where 1 PEM file included both Public and Private keys. Isn't there a decided structure of PEM? Can I put there any keys I want?
I saw also PEM file which had "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----". What is that certificate? My 2 PEM files have: "-----BEGIN PUBLIC KEY-----...-----END PUBLIC KEY-----" and the other has: "-----BEGIN RSA PRIVATE KEY-----...-----END RSA PRIVATE KEY-----".

openssl genrsa -out private.pem gives me a PEM file which includes only private key

Not really. In principle RSA can store just a privatekey with no publickey, but the RSAPrivateKey format used by OpenSSL (from PKCS1 aka RFCs 2313 2437 3447 8017) stores both. The formats used for other asymmetric algorithms (DSA, DH, ECC) also have this property, meaning you can always store only the privatekey file and still obtain the publickey whenever needed. GPG does the same thing; the public key information is always contained within the 'secret' key, as they call it for historical reasons. OpenSSH (mostly) uses the OpenSSL formats, so it isn't a useful observation.

  openssl rsa -in private.pem -outform PEM -pubout -out public.pem gives me a PEM file which contains a public key

Which contains only the public key. And is pretty much useless because (1) it can be regenerated from the privatekey file and (2) most applications don't use just the publickey but instead a certificate.

  So, after executing these 2 commands I have my RS-256 keys pair (is it the correct name? Keys are 2048bits as far as I know, so why RS-256, not RS-2048?).

Technically it's a keypair, but as above OpenSSL basically merges the concept of keypair with privatekey, and distinguishes only publickey -- which is the one that needs to be distinguished, because it's public.

Yes, crypto keys are almost always measured in bits. The scheme name RS256 (no hyphen) is used in JSON Web Signature (JWS) and JSON Web Token (JWT) to mean RSA signature (specifically the RSA signature scheme RSASSA-PKCS1-v1_5 defined by PKCS1) with SHA-256 for the hash. This is not related to the size of the RSA key and can be used with any (implemented) size; the example key for RS256 in RFC7517 is 1024-bit -- although RSA-1024 today does not provide an adequate margin of safety, and it has been prohibited by authorites like NIST and CABforum (and thus most web browsers) for several years. RSA signature (and also RSA encryption) is used in many many applications other than JWS/JWT.

  Can I consider the 2 files that I have (private.PEM + public.PEM) a certificate already?

First a clarification: 'certificate' is a general concept used in many contexts. For crypto, the certificates of interest are usually public-key certificates which bind a public-key to an identity (or sometimes a role) with some related attributes, and the most common ones by far are the public-key certificates defined by X.509, a standard created in 1988 by then-CCITT (now-ITU-T) and since enhanced and made more useful, but not fundamentally different, by many standards organizations. The Internet standards for certificates are based on X.509 and called Public Key Infrastructure using X.509, abbreviated PKIX. X.509, like some other computer standards, represents its data using a generic syntax called Abstract Syntax Notation 1, abbreviated ASN.1.

With that said, NO. A public-key/X.509 certificate contains a publickey, but it is not merely a publickey. It contains a good deal of other information that is vital to the way it is used, although the publickey is arguably the most important single piece of information. A certificate is created for a publickey, normally packaged as a Certificate Signing Request aka CSR or just request, by an entity called a Certificate Authority or CA which digitally signs the certificate using the CA's key so that no one else can alter it, and thus any program using it can trust it. In principle anybody can act as a CA, and in particular the OpenSSL commandline program can perform the technical operations a CA does, like issuing certificates. However, in most situations the value and usefulness of a certificate depends on how well and widely the issuing CA is trusted, so the most successful CAs are the ones that have established themselves as trusted, such as Digicert-now-including-Symantec-formerly-Verisign, Comodo, GoDaddy, etc.

As a special case, it is possible to have a 'self-signed' certificate, which is signed using its own key instead of a CA's key. This certificate can't convey trust like one from a real CA, because it is NOT effectively protected against substitution, but it can be created even when you can't contact and/or pay a CA, and it can usually be processed, with manual approval or override, by programs that are designed to normally use or require a certificate.

  What is the content of CER, CRT or P12 files? I can't find any real examples of these files.

CER and CRT are (both) commonly used as extensions for a file containing an X.509 certificate, and may be in either case depending on the filesystem. There are two common encodings used for the file contents: "DER", which is a binary encoding (Distinguished Encoding Rules) defined by ASN.1; and "PEM", which converts the binary DER to base64, broken into conveniently sized lines and with header and trailer lines added, which is more convenient for people, especially for things like cut-and-paste. PEM is so-named because this encoding was originally defined for Privacy Enhanced (e)Mail, a scheme which been superseded by other email and message technologies, but this format remains in use. These encodings look very different, but they contain exactly the same information (unless damaged), and many programs that deal with certificates can read both. PEM files written by OpenSSL often include 'comment' information before the header or after the trailer; programs should ignore this, but sometimes they get confused and you need to remove the extraneous information. On Windows, also be careful NOT to use 'UTF-8' format which usually adds a Byte Order Mark that is not visible on the display but interferes with a program reading the file.

Although PEM is widely used for certificates and many PEM files are certificates, be aware PEM is used for many other things as well. Don't assume a PEM file is a certificate; instead check the header line, which for this case conveniently says -----BEGIN CERTIFICATE----- or sometimes -----BEGIN X509 CERTIFICATE-----. See rfc7468 for much more detail on this.

P12 is commonly used to identify files in the PKCS12 aka PFX format, which is quite different. Although the PKCS12 standard supports a large number of options, it is normally used to contain a privatekey PLUS the corresponding certificate PLUS in most cases one or more 'chain' or 'intermediate' certificate(s) that are needed to form a trust chain to validate the end-entity certificate.
In practice PKCS12 files are always binary, although there's no technical reason they couldn't be PEM-encoded or otherwise made more human-friendly.

  How to generate CER, CRT or P12 from my 2 PEM files that I have?

To get a certificate you need to either use a CA (either an established one or a DIY one you create) or create a selfsigned certificate. There are probably hundreds of variations of each of these depending on what software (and CA if any) you use, but for OpenSSL and most CAs the usual procedure is:

Create a CSR using openssl req -new -key privatekey [... other options] >csr

See the man page for req for details. If you want to use the certificate for SSL/TLS including HTTPS, make the 'Common Name' be the (or a) name by which the server will be accessed, which is normally its Fully Qualified Domain Name (FQDN). If you want to use the certificate for other applications, the necessary identity information depends on the application(s).

For a real CA, submit the CSR to the CA (often on a webform, which PEM makes convenient) along with the proof of identity or other authorization, and possibly payment, they require.

You should receive in return a newly-issued 'end-entity' certificate (containing your publickey and identity) and usually one or two cert(s) containing publickey(s) and identity(ies) for intermediate CAs used to create the trust chain. These may be separate files (either DER or PEM) or a concatenation (PEM only) or a particular case of the PKCS7 standard (SignedData with no data or signatures only certificates) usually called P7B or P7C.

2'. Or, do this yourself. Create a CA key and cert (only once) and then use either openssl ca ... or openssl x509 -req -CA -CAkey ... to read the CSR and issue a cert under your own CA.

This cert will be usable only with systems and programs controlled by you yourself or people who implicitly trust you and are technically able to install your CA cert, which is typically a small group, sometimes an empty one. Also be careful not to give your CA cert and end-entity cert the same name, for example by accepting the defaults in req; if you do that, the resulting certs won't be usable anywhere.

Use the cert, together with the privatekey and chain cert(s), as needed. This may involve combining them into a PKCS12, using openssl pkcs12 -export.

As noted above, you can create a self-signed cert instead of a CA-issued one. Replace steps 1 and 2/2' with the single step: openssl req -new -x509 -key privatekey ... >cert

Note the addition of the -x509 flag, and there are numerous additional options described on the man page. This has all the properties and limitations of a DIY CA, plus more: you (and/or your friends) can't just install the DIY CA cert once, but must install each end-entity cert separately and repeat the process anytime one of your certs must be replaced because it expires or any any relevant information changed.

  I saw some information that P12 file can be protected by a password - what is the reason to protect this file with a password - that password again has to be stored somewhere, already we store P12 file in a secure place where no one should have access to, right?

The password doesn't necessarily have to be stored; programs can prompt for it when necessary (and the openssl program in particular does so). Although now often used for storage, PKCS12/PFX was originally intended for transferring a privatekey, with cert(s), from one system to another, a process that is very often not secure. Even for storage, systems and places you think are secure sometimes turn out not to be, and the defense-in-depth of encrypting the privatekey is worth it. But in some cases yes the password is just a small bit of extra work for no real benefit.

  I saw some example where 1 PEM file included both Public and Private keys. Isn't there a decided structure of PEM? Can I put there any keys I want?

Whether more than one object can be read from, and thus usefully stored in, a single PEM file depends on the program doing the reading. OpenSSL in most (but not all) cases can handle this, so using such files with OpenSSL (and programs that call OpenSSL library) is moderately common; other programs and libraries may be different. As above, storing the publickey as such is almost never useful. Storing e.g. the privatekey and the certificate, or all the certificates in the chain, can be useful. Programs like Apache httpd and nginx support this (but do not require it).

  I saw also PEM file which had "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----". What is that certificate?

See above for certificates in general. If you want to know the details of a particular cert (the name of the key owner, called 'subject'; the public-key; the time period the cert is valid; the issuing CA and its serial number, etc) you can use openssl x509 -text <file or depending on your system usually several other programs are capable of displaying cert details.
On Windows for .cer .crt you can just doubleclick a file (or name it in the 'run' dialog or a start command in CMD) and a dialog will pop up containing a Details tab.


OAuth for Multiparty Authentication/Authorization I work for a web company that's undergoing a massive rewrite in order to separate our Data out into its own RESTful service application - the goal is to be able to sell access to third parties and quickly prototype internal applications without needing direct access to the DB.
We currently have three Applications - The aforementioned Data API, a CMS, and a Front-end.  Users need to be able to log in to the CMS to modify Data through the API, and we'd really like to integrate our Google Web Apps into this - logging in Via Google.  Ideally, this would use the OAuth flow, because it's the most transparent to our users - but I'm unaware of any way to share the OAuth information between applications without possibly compromising their security.
What I've tried
Concretely?  Nothing.  My initial proposal was to generate what is essentially "Nested OAuth" - set my Data Application as an OAuth Provider for all other applications, then use the Google OAuth flow as the unspecified Authentication standard within the Data Layer - it's an entirely Restful API, so it would be pretty much transparent to the user, but it seems to violate the concept of OAuth, and I feel like there should be a better way to do it.  The flow would look like this:

User Requests Login for the CMS
CMS gains an Auth Token from the Data Layer
CMS Redirects the User to Login page hosted at the Data Layer
Data Layer Gains an Auth Token from Google
Data Layer redirects the User to Google Login Page
Google Authenticates the User, then redirects the User back to the Data Layer with an Auth token
Data Layer uses Auth Token to get Access Token for Google Services
Data Layer redirects User back to the CMS with another Auth Token
Auth Layer uses Auth Token to get an access token for Data Services

But it seems, well, clunky.  I'd also like to not have to force the user through mutiple "Allow" pages - one from Google to allow the Data Layer, and One from The Data Layer to allow the CMS (or some later application) to access.  What I really need is to use Google for a SSO or Kerberos situation, and have Google give out tickets for my applications.  If anyone knows a way to leverage that with Google, I'd gladly trash this whole design.

After a lot of research, I've discovered that Google has an Unsecured Access Token verifier - https://developers.google.com/accounts/docs/OAuth2UserAgent#validatetoken which can be used to verify

What application the Token was issued to
Which email address the token was issued on behalf of.

By keeping track of the application's Google Identifier, The data layer can accept an Access Token and verify it to authenticate the user and the application, with a little help from a standard API Signature scheme involving a secret known only to the Data Layer and the accessing application.  This requires no trust, as each application that needs information from the Data Layer can register itself with Google oAuth, and without the secret shared between them, the Data API cannot use the access token on the users behalf.  This does preclude the Data Layer from accessing Google APIs on the user's behalf, but a separate oAuth specifically for the Data API can be implemented to get access to the user's resources.


Encrypting text file with AES 256 instead of password manager I'm starting to have a big list of passwords I need safely stored. I was looking at password managers like LastPass, but these always seem to be targetted by hackers and have been compromised before.

Would I lose anything from storing my passwords in a text document that I encrypt myself using AES 256? Then just decrypt when I want the password?

Considering those compromises you mention, do you think that encrypting files yourself will be easy? How do you know you won't get into those same pitfalls that resulted in compromises of password managers?

AES 256 is believed to be computationally secure. Every computer ever made working simultaneously to brute force the key, working since the beginning of time, would have a probabilistically negligible chance of ever finding the key to an encryption.

However: a secure algorithm doesn't guarantee a secure implementation. Just to give you an example, here are a few questions you should ask yourself:

How are you going to ensure that two identical passwords in your list are not encrypted to identical AES ciphertext? (so that if the adversary knows one password, he'll know where it is reused)
Are you sure your decrypted password list cannot be reclaimed by a process allocating RAM after you have consulted your list?
Are you sure your decrypted password list will not end up is the swapfile?
What communication mechanisms will you use between the user providing the master password, the process decrypting the password list and the target application in need of one password?

Password managers are designed with those (and perhaps many others) concerns in mind. It's almost impossible to get everything right when doing it yourself the first time, especially if you're not a security expert.


Why does javascript not show an alert box? I'm trying to insert javascript:alert(1) inside  tag. There is some kind of filter for javascript, so I tried using javascrip%74:alert(1) and that url is accepted.

However when i click on it it redirects me to https://www.website.com/javascript:alert(1) instead of showing the alert box?

Why is that happening and how can I bypass that?

javascrip%74 is not a valid scheme for any production browser.  It's being evaluated, in URL encoding, as javascrip%2574.

A list of valid protocols used in Chromium-based browsers can be seen in the following file; I've highlighted the line containing the 'javascript' protocol.   https://cs.chromium.org/chromium/src/url/url_constants.cc?dr=C&g=0&l=26

The processing of URLs, again in Chromium-based browsers, can be seen in the origin files: https://cs.chromium.org/chromium/src/url/origin.h?dr=CSs&g=0


Found an application (Whatsapp) initiating UPnP requests, is it something that I should worry about? I have logged in into my router using the web interface. I was checking UPnP forwarding (which is enabled by default), and found out that whatsapp is initiating a UPnP request on port 65072.
 Is there a way that I can understand, why and how whatsapp is using UPnP? Is it something normal ?

WhatsApp uses uPnP for NAT traversal and external IP Address discovery. It only happens when you initialise WhatsApp call.

Some of the NAT traversal techniques are:

NAT-PMP (obsolete but still used by some of the BitTorrent clients)
PCP (successor of NAT-PMP)
STUN/TURN
uPnP (also used by BitTorrent client)

Through uPnP WhatsApp establishes peer-to-peer communication to initiate VoIP. uPnP is also a dynamic port forwarding technique so it is active as long as the P2P communication is running. If you disable uPnP in your router, then WhatsApp switches to STUN.

It used to be only STUN/TURN in older versions and they recently added uPnP support. I think it is because they want to reduce the call set up time. STUN has its own complications like it doesn't work with Symmetric NAT and first client has to discover if it is sitting behind a Symmetric NAT, then only it switches to TURN using ICE which further increases call set up time.

Whereas in uPnP, client only has to talk to the router to initialise the session and keep it active. This greatly reduces the round trips and call set up time.


Is it possible for someone else to add a photo to text messages I am sending? Is it possible for someone else to intercept a text message I am sending and add a photo to that message?  I recently answered a text message I received from a friend and half way through typing out the reply, an old intimate photograph of me inserted itself into the body of the text message.  Can this be done by someone else i.e. an ex who may have someone put spyware on my phone and whilst monitoring my text messages has decided to add this photo? Is there anything out there that is capable of this?

That would require the connection or receiving app to be compromised, the former an unlikely premise for a modern app using AES, like Google Hangouts or Telegram and I don't believe that rootless apps can manipulate other app content.

In short, yes, it is possible, but if you use a modern, secure app (and don't let your ex use your phone), it can only be from a selfrooted spyware app.

EDIT (questions from comments, until i can comment):
@Steve SMS does not support photos. MMS is a viable attack vector, as it is not often encrypted. As such, migration to an AES encrypted message app is recommended.

@Neil App verification can be completed through secure hash and comparison with a known good copy.


Secure method to store PHP object in MySQL database? How do I securely save PHP objects in a MySQL Database? If you use the serialize and unserialize functions, you may end up with Object Injections. Is there a predefined standard on how to handle this?

Note that SQL injection =/= object injection! So PDO is a different story here!

(Not) Trusting your database

You should be able to somewhat trust the data in your database, but as defense in depth it is definitely better to not trust it.

There may for example be a limited SQL injection, which allows inserting data into the database, but nothing else (maybe because your database rights are managed correctly).

But now, an attacker gained object injection, and who knows what that may lead to.

Data Integrity

You could use an HMAC to verify the integrity of your data. That way, you can be sure that what went into the database is the same thing that comes out of it (as long as an attacker doesn't have access to the key, which for example may be stored in the sourcecode).

Save Unserialize

PHP7 allows for an additional options parameter, in which you can specify what classes unserialize is allowed to create.

This already limits the power of object injection. An attacker can still overwrite fields in the object itself - which they can do anyways if we assume database write access - , which may not be harmful, but they cannot create arbitrary objects.

Input Validation

You could also perform some validation on the data before sending it to unserialize, such as collecting all O:X strings and checking if X is an allowed object.

But I would definitely recommend the save unserialize solution from above.

Mitigation: Not having exploitable classes and functions

It is a good idea to check data and authentication on a per-function level. For example, you shouldn't just assume that field x can be trusted because it isn't (currently) user-controlled, and thus eg safe to pass to passthru.

Not storing objects

If you do not have a good reason for doing so, you shouldn't store objects in the database.


Mifare Plus X vulnerabilities I have just purchased a Mifare Plus X (MF1PLUSx0) for a security project. I know that there are exploits against Mifare Classic cards (using tools such as Mfoc and Mfcuk), but are there similar exploits to crack the Mifare Plus X card?

The Mifare Plus product line was specifically designed as a solution to the well known Mifare Classic vulnerabilities. As far as I know there are currently no published exploits against this new generation of cards.


If I sell my printer, can the last printed pages be recovered? And how can I wipe it? I have a Brother 5470-DW Printer. I want to sell it but wanted to make sure all the last prints can't be recovered.

If I sold my printer could the last pages printed be recovered? How can I wipe all the last printed pages? Wipe the memory? How would I do that? Does it have a HDD that I need to remove?

I also have a Brother 5370-DW. Would the answer be the same for this older model?

EDIT NEW INFORMATION

I was talking to someone that said it might be model specific, and to check if there's anything cached in flash chips at all... does anyone know anything about this? They said to open the printer and have a look.... how do I do this? Does anyone know if this is necessary and given all the info/answers/manuals, that there is nothing cached in the flash chips?

In other words, print 100+ pages and then just power off the printer for 24 hrs and that should leave all past prints unrecoverable is that about rt?

From what I read here and after a quick look in the User's Guide this does not seem to be the case.

Print jobs are stored in the local memory (RAM) of the printer, but this is not the same as a hard drive (see also forest's comment). This is true for the majority of modern printers. If the printer is turned off for a moment, there should be no more data inside the memory (aka no more old print jobs). That moment can be crucial, research has shown, that data persists in RAM for some minutes even after a device is powered down.

Speaking to your specific case: unless you are a government official or another target that prints top secret/highly valuable documents every 5 minutes on his printer, this is probably not a risk for you.

The printer (5470-DW) also seems to have ROM2. How do I know? Becaue you can format it.1 According to the manual macros and fonts are saved there, but who knows what else ends up there. If you decide to format the ROM, you might have to reinstall some firmware if you/somebody want/s to use the printer again. I don't think it's necessary, but if you have the itch (and the time) to do it, do it.

Concerning the the HL-5370DW: print jobs are also saved in the printer's RAM, not too sure about the ROM2.

I also looked for known vulnerabilities, there seem to be none.

1 see page 78 in the english User's guide

2 this is probably an EEPROM unit


Is *all* obscurity subject to debate? I'm a beginner and reading about attitudes towards "security by obscurity." I understand that there are varying degrees of vehemence in the opposition to the use of obscurity, but I am trying to clarify for myself how absolute this is.

I understand that relying exclusively on obscurity is pretty unanimously frowned upon. I'm only discussing types of obscurity which could be added to in-depth defense strategies.

For example, things like configuring hosts to not respond to ICMP echo requests (in cases where that makes sense) or sanitizing banner info in order to obscure the topology or software of my network seem like no-cost practices that make it one step harder for a non-determined attacker to target my network.

Is there some line of delineation at which everyone agrees that obscurity is a good idea, or is there something I am missing in which even these types of obscurity would be discouraged? Is there perhaps a different term or category for these types of obscurity?

The fundamental thing to understand is Kerckhoff's principle; the enemy knows the system. This means that you have to work on the basis that obscurity has failed and the attacker knows everything about how your system is meant to work. So, as you've concluded, there must be no reliance on obscurity.

However, you're under no obligation to help the enemy know your system. So sure, the low cost methods you mention are worth doing. You're not relying on them, but they don't hurt and might help.


Security risks of using ffmpeg as part of web service I'm working on a web service that uses ffmpeg on the backend for processing user uploaded media files. I'm giving the users some options to customize how their videos are processed, which is essentially parameterizing the ffmpeg command.

I'm planning to run ffmpeg in a dockerized environment, possibly with a new docker container per execution. Regardless, this environment could be used to execute arbitrary code and might have have access to some of my secrets.

Beyond command-line injection, are there any other security concerns to consider here?

Edit:

An update on my situation. I am running ffmpeg inside a docker container with networking disabled and passing the input and output files via a shared directory.

The command below does the following:

Puts the input file into a shared directory with the container
Runs FFMPEG inside the container with whatever options are passed
Puts the output file into the host shared directory, where the host will then copy it to it's final storage location

Command:

docker run -v <TEMP_DIR_ON_HOST>:/temp/ --network none \
    jrottenberg/ffmpeg -stats \
    -i /temp/<INPUT_FILE> \
    <FFMPEG_OPTIONS> \
    /temp/<OUTPUT_FILE>

A few notes:

TEMP_DIR_ON_HOST is a single use directory for one conversion
FFMPEG_OPTIONS are scrubbed, but could potentially contain injection
I'm not locked into the jrottenberg/ffmpeg image, I might make a copy or at least lock down to a particular version.

I think that disabling networking and limiting outside file access greatly reduces the risk even if malicious commands are injected somehow. Are there any major risks beyond wasted resources?

Yes there are security risks, especially if you allow arbitrary formats. FFmpeg supports a huge variety of formats, both popular and obscure, for video, audio, and images. Any vulnerability in decoders for any of the numerous formats could be exploited to gain arbitrary code execution. This becomes even more likely given the fact that FFmpeg is written in C, which is not memory safe, and is optimized for speed instead of security. You must assume any untrusted input passed to FFmpeg can be used to gain full arbitrary code execution in the context of the running process and build your threat model around that.
There are a few things you can do to mitigate potential risks in addition to hardening Docker:

Seccomp sandboxing - Enable seccomp in Docker to limit the syscalls that can be made. A syscall, or system call, is the interface used by userspace to communicate with the kernel. Certain syscalls are complex and can be insecure, opening up bugs in the kernel to exploitation.

Formats/codecs - Disable unused decoders to reduce the attack surface area of the decoder. Many formats, or formats with obscure features, have low-quality decoders that are not regularly checked for bugs. While the Opus decoder is likely of acceptable quality, what about G.726?

Resource limits - Restrict resources that any given FFmpeg process can use. Resources can not only be used to DoS the system, but can be necessary to exploit other vulnerabilities to elevate privileges, for example certain kinds of integer overflows that require large memory allocations.

Mandatory Access Controls - Use a MAC like AppArmor or SELinux to restrict accesses and protect sensitive objects, even in the case of a Docker breakout. You can also use a MAC to limit network connections, since there is no reason FFmpeg should upload or download data.

Compiler hardening - Use hardening when building FFmpeg, or download a hardened version. Compiler hardening like PIE, SSP, and FORTIFY_SOURCE can make vulnerabilities harder to exploit. PIE is especially important, as it allows the operating system to make full use of ASLR.


Do VB Macro viruses (ie macros in Microsoft office documents) affect modern Linux systems? In the area I live and work, viruses in outdated and pirated windows systems are absolutely rampant. (Moreso even than in the "normal" world). It's utter madness to plug in a USB drive anywhere. Almost 100% infection instant USB rate anywhere public.

Unforunately, I have to work with a lot of files with MS Office documents transferred by USB from students, which are generally equally as virus ridden. I know for a fact several of the Excel files I've gotten have contained VB macro viruses.

I have some concern about opening these even on a Linux machine, but it's unavoidable.

Is there any reason for concern that VB macro type viruses could infect a Linux machine using OpenOffice?

Microsoft Office macros and OpenOffice macros are not compatible, you would need to rewrite a Microsoft Office macro for it to run in OpenOffice.

Also, macros in OpenOffice 3 are disabled by default.


What is the most valuable file you can get using a directory traversal hole I am doing a penetration test and I found a directory traversal hole in the web application which enables me to download any readable file in the server. However, I could only download files that is readable by www-data(apache2) user (e.g. the file with permission of rw-r--r--). This limits the usage of this hole since I can get /etc/passwd while I cannot download /etc/shadow. So My question is that what else valuable file can be downloaded under this restriction?

There are many things you can do with that. Check the web application source code for settings configurations like databases, then check for a way to connect with the db.

Keep looking at the source code and you might find more vulnerabilities (rce,sqli) or misconfigurations that can lead you to database dump, or some old backups, passwords disclosures, etc.