Dragos

Mai sunt WS-Fed (in principiu am vazut O365 sa-l foloseasca, desi mai nou cam toata lumea foloseste Graph API care are OIDC la baza), Kerberos ticket (pentru sisteme legate prin Active Directory) si derivate de la cele de baza, precum JPaseto.

Up, se cauta si in Constanta, pe langa Brasov.

SAML necesita mult prea multe verificari si tine foarte mult de SP sa nu greseasca sau sa activeze vreun flag (sau sa uite sa-l dezactiveze) in SDK-ul de SAML care sa deschida o portita, gen verificarea semnaturii doar daca exista, cum prezinta in video. Recomand cu toata increderea implementarea OpenID Connect. Din 100-200 de linii de cod se poate face schimbul de authorization code (daca e authorization code flow/pkce flow), decodarea JWT-ului, verificarea semnaturii si a timestamp-urilor si preluarea username-ului si a rolurilor, din token sau de pe endpoint-ul /introspect.

E în titlu locația. Am adăugat-o acum și în postare.

Salutări, Firma unde lucrez caută oameni în Brașov pe partea de Technical Support Engineer, Tier 2. E ideal (dar nu obligatoriu) dacă aveți cunoștințe în următoarele domenii: Active Directory, LDAP, GPO, DHCP, DNS Single Sign-On, SAML, OpenID, WS-Fed experiență cu aplicații cloud precum Salesforce, Workday, Box, G Suite, etc. Se oferă: o lună de training pentru învățarea produsului și metodelor de troubleshooting asigurare medicală privată contract pe perioadă nedeterminată Dacă sunteți interesați sau aveți întrebări, lăsați-mi un PM.

CVE OneLogin - python-saml - CVE-2017-11427 OneLogin - ruby-saml - CVE-2017-11428 Clever - saml2-js - CVE-2017-11429 OmniAuth-SAML - CVE-2017-11430 Shibboleth - CVE-2018-0489 Duo Network Gateway - CVE-2018-7340 The Security Assertion Markup Language, SAML, is a popular standard used in single sign-on systems. Greg Seador has written a great pedagogical guide on SAML that I highly recommend if you aren't familiar with it. For the purpose of introducing this vulnerability, the most important concept to grasp is what a SAML Response means to a Service Provider (SP), and how it is processed. Response processing has a lot of subtleties, but a simplified version often looks like: The user authenticates to an Identity Provider (IdP) such as Duo or GSuite which generates a signed SAML Response. The user’s browser then forwards this response along to an SP such as Slack or Github. The SP validates the SAML Responses signature. If the signature is valid, a string identifier within the SAML Response (e.g. the NameID) will identify which user to authenticate. A really simplified SAML Response could look something like: <SAMLResponse> <Issuer>https://idp.com/</Issuer> <Assertion ID="_id1234"> <Subject> <NameID>user@user.com</NameID> </Subject> </Assertion> <Signature> <SignedInfo> <CanonicalizationMethod Algorithm="xml-c14n11"/> <Reference URI="#_id1234"/> </SignedInfo> <SignatureValue> some base64 data that represents the signature of the assertion </SignatureValue> </Signature> </SAMLResponse> This example omits a lot of information, but that omitted information is not too important for this vulnerability. The two essential elements from the above XML blob are the Assertion and the Signature element. The Assertion element is ultimately saying "Hey, I, the Identity Provider, authenticated the user user@user.com." A signature is generated for that Assertion element and stored as part of the Signature element. The Signature element, if done correctly, should prevent modification of the NameID. Since the SP likely uses the NameID to determine what user should be authenticated, the signature prevents an attacker from changing their own assertion with the NameID "attacker@user.com" to "user@user.com." If an attacker can modify the NameID without invalidating the signature, that would be bad (hint, hint)! XML Canononononicalizizization: Easier Spelt Than Done The next relevant aspect of XML signatures is XML canonicalization. XML canonicalization allows two logically equivalent XML documents to have the same byte representation. For example: <A X="1" Y="2">some text<!-- and a comment --></A> and < A Y="2" X="1" >some text</ A > These two documents have different byte representations, but convey the same information (i.e. they are logically equivalent). Canonicalization is applied to XML elements prior to signing. This prevents practically meaningless differences in the XML document from leading to different digital signatures. This is an important point so I'll emphasize it here: multiple different-but-similar XML documents can have the same exact signature. This is fine, for the most part, as what differences matter are specified by the canonicalization algorithm. As you might have noticed in the toy SAML Response above, the CanonicalizationMethod specifies which canonicalization method to apply prior to signing the document. There are a couple of algorithms outlined in the XML Signature specification, but the most common algorithm in practice seems to be http://www.w3.org/2001/10/xml-exc-c14n# (which I'll just shorten to exc-c14n). There is a variant of exc-c14n that has the identifier http://www.w3.org/2001/10/xml-exc-c14n#WithComments. This variation of exc-c14n does not omit comments, so the two XML documents above would not have the same canonical representation. This distinction between the two algorithms will be important later. XML APIs: One Tree; Many Ways One of the causes of this vulnerability is a subtle and arguably unexpected behavior of XML libraries like Python’s lxml or Ruby’s REXML. Consider the following XML element, NameID: <NameID>kludwig</NameID> And if you wanted to extract the user identifier from that element, in Python, you may do the following: from defusedxml.lxml import fromstring payload = "<NameID>kludwig</NameID>" data = fromstring(payload) return data.text # should return 'kludwig' Makes sense, right? The .text method extracts the text of the NameID element. Now, what happens if I switch things up a bit, and add a comment to this element: from defusedxml.lxml import fromstring doc = "<NameID>klud<!-- a comment? -->wig</NameID>" data = fromstring(payload) return data.text # should return ‘kludwig’? If you would expect the exact same result regardless of the comment addition, I think you are in the same boat as me and many others. However, the .text API in lxml returns klud! Why is that? Well, I think what lxml is doing here is technically correct, albeit a bit unintuitive. If you think of the XML document as a tree, the XML document looks like: element: NameID |_ text: klud |_ comment: a comment? |_ text: wig and lxml is just not reading text after the first text node ends. Compare that with the uncommented node which would be represented by: element: NameID |_ text: kludwig Stopping at the first text node in this case makes perfect sense! Another XML parsing library that exhibits similar behavior is Ruby's REXML. The documentation for their get_text method hints at why these XML APIs exhibit this behavior: [get_text] returns the first child Text node, if any, or nil otherwise. This method returns the actual Text node, rather than the String content. Stopping text extraction after the first child, while unintuitive, might be fine if all XML APIs behaved this way. Unfortunately, this is not the case, and some XML libraries have nearly identical APIs but handle text extraction differently: import xml.etree.ElementTree as et doc = "<NameID>klud<!-- a comment? -->wig</NameID>" data = et.fromstring(payload) return data.text # returns 'kludwig' I have also seen a few implementations that don’t leverage an XML API, but do text extraction manually by just extracting the inner text of a node’s first child. This is just another path to the same exact substring text extraction behavior. The vulnerability So now we have the three ingredients that enable this vulnerability: SAML Responses contain strings that identify the authenticating user. XML canonicalization (in most cases) will remove comments as part of signature validation, so adding comments to a SAML Response will not invalidate the signature. XML text extraction may only return a substring of the text within an XML element when comments are present. So, as an attacker with access to the account user@user.com.evil.com, I can modify my own SAML assertions to change the NameID to user@user.com when processed by the SP. Now with a simple seven-character addition to the previous toy SAML Response, we have our payload: <SAMLResponse> <Issuer>https://idp.com/</Issuer> <Assertion ID="_id1234"> <Subject> <NameID>user@user.com<!---->.evil.com</NameID> </Subject> </Assertion> <Signature> <SignedInfo> <CanonicalizationMethod Algorithm="xml-c14n11"/> <Reference URI="#_id1234"/> </SignedInfo> <SignatureValue> some base64 data that represents the signature of the assertion </SignatureValue> </Signature> </SAMLResponse> How Does This Affect Services That Rely on SAML? Now for the fun part: it varies greatly! The presence of this behavior is not great, but not always exploitable. SAML IdPs and SPs are generally very configurable, so there is lots of room for increasing or decreasing impact. For example, SAML SPs that use email addresses and validate their domain against a whitelist are much less likely to be exploitable than SPs that allow arbitrary strings as user identifiers. On the IdP side, openly allowing users to register accounts is one way to increase the impact of this issue. A manual user provisioning process may add a barrier to entry that makes exploitation a bit more infeasible. Sursa: https://duo.com/blog/duo-finds-saml-vulnerabilities-affecting-multiple-implementations

ModSecurity ajută la blocări de SQLi, XSS, etc. pe baza unor reguli presetate. Pe hosting shared, nu ai cum să modifici din păcate aceste reguli ca să îţi faci excepţii, poţi doar să activezi/dezactivezi WAF-ul.

Şterge <p>-ul acela şi încearcă din nou. S-ar putea să te blocheze modsecurity. Dacă ai nevoie să trimiţi în $_POST['descriere'] cod HTML, dezactivează modsecurity din cPanel sau ce panou ai şi mai încearcă o dată.

https://rg3.github.io/youtube-dl/

Dupa cum ziceau rsn mai sus, programarea in sine nu o sa dispara, pentru ca cineva trebuie sa dezvolte CMS-urile. Iti recomand sa inveti sa folosesti CMS-urile populare, gen Wordpress sau Joomla, sa intelegi cum functioneaza, ce teme sa folosesti si cand, cand trebuie sa folosesti plugin-uri si cand trebuie sa le dezvolti tu. Fiecare client are necesitatile sale si de multe ori am ajuns sa dezvolt un plugin de la zero decat sa instalez 5 si sa-i fac instructaj cand sa foloseasca unul si cand sa foloseasca altul. In unele cazuri, precum site-uri simple de prezentare, am preferat sa folosesc un CMS deja existent pe care am adaugat o tema si cateva plugin-uri. Atata timp cat arata bine, pe vizitator nu-l intereseaza daca e Wordpress sau de la zero. Cand vorbim de o infrastructura mai mare, gen ERP, am preferat sa-l dezvolt de la zero pentru a acoperi cat mai bine necesitatile clientului. Asadar, aplicatiile de creat site-uri, ca vorbim de Dreamweaver sau de un CMS, usureaza munca unui web developer sau web designer, nicidecum nu o inlocuieste.

Asta cu arestatul preventiv pentru atacuri cibernetice sa zicem ca e asa si asa, dar faptul ca nu mai au voie procurorii sa se foloseasca de datele pe care le-au extras din calculatorul tau si pentru care nu au mandat, mi se pare super aiurea. Este pe de o parte o protejare a vietii private, dar pe de cealalta parte doar complica metodele existente. Pur si simplu mai dau baietii veseli inca 2-3 telefoane sa mai scoata un mandat si gata, proba se poate folosi. Astia dau legi care se anuleaza unele pe altele, legi pe care doar ei le inteleg si legi ce iarta mai ceva ca Dumnezeu.

La prima prima versiune de hack pentru ConQUIZtador, un user de pe forum a decriptat swf-ul şi a demonstrat că în momentul când se trimiteau întrebările, se trimitea şi răspunsul într-o variabilă pe care scriptul o lua şi afişa (link). Când a apărut ConQUIZtador Killer, staff-ul ConQUIZtador a reparat deja bug-ul să se trimită răspunsul o dată cu întrebarea, el trimiţându-se la final pentru a verifica răspunsurile userilor. Slick a făcut o aplicaţie care timp de câteva zile a stat şi a învăţat întrebările şi răspunsurile de la sute, poate mii, de jocuri, astfel încât să aibă cât de cât o bază de date stabilă, dar nu avea cum să fie completă, mai ales că era locală. Din ceea ce pot vedea în video-ul amicului tău, modul de funcţionare e oarecum identic cu CQ Killer, are o bază de date în care caută întrebarea pentru răspuns şi, dacă nu ştie întrebarea, atunci o salvează undeva centralizat.

Port forwarding nu poți face fără acces la router pentru că trebuie să îi setezi calea către calculator. O variantă ar fi să folosești un server sau serviciu care intermediază conexiunea. La ce ai nevoie mai exact?

RoTLD a anunţat în august trecerea la taxa anuală şi vor expira anul viitor toate domeniile mai vechi de 5 ani pe principiul data înregistrării + 5 ani (toate detaliile aici). În cazul tău, domeniul expiră în decembrie 2020. Nu vreau să-ţi stric bişniţul, doar vreau să explic ca să nu fie confuzii sau discuţii mai târziu.